Someone asks you to make a salad for a team lunch. You know a tomato is a fruit. Botanically, you're right. So you chop it into the bowl with the strawberries and the melon.
Every instruction was followed. The lunch is still ruined.
The late Miles Kington, the British humourist, gets credit for the line about this. Knowledge is knowing a tomato is a fruit. Wisdom is not putting it in a fruit salad. It's a joke about wisdom. I think it's a better joke about management.
The Tomato Problem
Grace Judson, an executive coach who joined me on my podcast Corey-osity Unleashed, uses the tomato to make a point I keep coming back to. Without context, execution fails. And it fails even when the effort is there.
Read the second half of the sentence again. Even when the effort is there.
Most leaders diagnose a bad outcome as a people problem. Wrong attitude. Lack of care. Not enough ownership. So they add a checklist, a status meeting, a tighter spec.
None of it touches the real failure. The person in the kitchen had the facts. They didn't know what the salad was for, who was eating it, or what "good" looked like. They had instructions. They didn't have context.
Your Backlog Is Full of Tomatoes
In software, this shows up everywhere.
Picture a ticket. "Add a CSV export to the reports page." An engineer picks it up, builds a clean export, writes the tests, ships it on time. Code review passes. Everyone moves on.
Three weeks later you find out the customer who asked for it wanted the data in their finance system. The CSV has the wrong date format, no account codes, and caps out at the first 10,000 rows. The real need was an integration. The ticket described a feature.
The engineer did nothing wrong. They built the thing on the ticket. Nobody told them the "why", the "who", or the "what happens next". So they filled the gaps with sensible guesses. Sensible guesses made without context produce tomatoes in the fruit salad.
Here's my rule of thumb. If your team keeps building the wrong thing well, you don't have a competence problem. You have a context problem. And context problems are yours to fix.
The Numbers Are Going the Wrong Way
You'd hope teams have more clarity now than ever. We have Slack, Notion, Jira, OKR tools and AI summaries of every meeting.
They don't.
Gallup tracks a simple statement: "I know what is expected of me at work." In early 2020, 56% of US employees strongly agreed. By late 2024 it had fallen to 45%. Gallup calls knowing what's expected "the most fundamental aspect" of performance at work, and notes since 2021 fewer than half of employees say they know.
More than half of your people are unsure what you expect from them. And expectations are the easy part. Expectations tell people what to do. Context tells them why, and what to do when the plan breaks.
The Army Figured This Out a Long Time Ago
I served in the US Army, and the military has thought harder about this problem than any business I've worked in. When things go wrong in the field, you don't get to send a Slack message asking for clarification.
The Army calls the answer commander's intent. The Army's own doctrine, ADP 6-0 Mission Command, defines it as a clear and concise expression of the purpose of the operation and the desired end state. Its job is to help subordinates "act to achieve the commander's desired results without further orders, even when the operation does not unfold as planned."
Without further orders. Even when it doesn't go to plan.
The same document goes further. Commanders "cannot provide guidance or direction for all conceivable contingencies." So they describe the purpose, the key tasks, the end state and the constraints, then let people use judgment inside those boundaries. In the doctrine's own words, "Subordinates aware of the commander's intent are far more likely to exercise initiative in unexpected situations."
Swap "commander" for "engineering manager" and "operation" for "sprint". The logic holds.
More Detail Makes It Worse
When execution goes wrong, most leaders reach for more control. Longer specs. More approval gates. Tighter daily check-ins.
Stephen Bungay, a military historian and strategy consultant, wrote a whole book on why this backfires. In The Art of Action, he describes three gaps between plans, actions and outcomes. There's a knowledge gap, an alignment gap and an effects gap. According to the strategy+business review of the book, leaders respond to those gaps with more detailed information, more instruction and more control. And it makes things worse, because it gets in the way of people taking effective action toward the goal.
His fix comes straight from the Prussian army. Don't plan in more detail than your situation allows. Make your intent as clear as possible. Then give people the freedom to decide how to carry it out, inside the bounds of the intent.
I've seen this play out in engineering teams over and over. The tighter the spec, the less the engineer thinks. The less they think, the more the spec has to cover. You end up writing the code in English in the ticket, and your senior engineers become typists.
Netflix Made It a Rule
Netflix put this into its culture memo years ago, and it's still there. The company expects managers to practise "context not control", giving their teams "the context and clarity needed to make good decisions instead of trying to control everything themselves."
You don't need to copy everything Netflix does. Plenty of their culture would not suit your team. This part would.
How to Stop Serving Tomatoes
Here's what I'd do with your next piece of work. None of it takes more than ten minutes.
Write the intent before the task
Before you write a ticket or assign a project, answer three questions in plain words.
- Why does this matter? Who is it for, and what problem does it solve for them?
- What does done look like? Describe the end state, not the steps.
- What are the boundaries? Budget, deadline, things you must not break, decisions you want to keep.
If any of the three has no answer, you're not ready to hand the work over. You're about to hand over a tomato.
Say what changes the plan
Tell people which conditions should make them stop and rethink. "If the export needs more than 10,000 rows, come and find me" is worth more than a page of acceptance criteria. It tells them what you care about.
Ask for the read-back
Pilots and soldiers read instructions back. Engineers should too. Ask, "What do you think this is for?" before work starts. If the answer surprises you, you've saved yourself three weeks.
Share the stuff you think is obvious
Customer conversations. The reason the deadline exists. The thing the CEO said in the board meeting. What feels like background noise to you is the missing context for your team. They weren't in the room.
Treat a wrong outcome as a context bug first
Next time a piece of work comes back wrong, before you question anyone's effort, ask yourself one question. Did they know what the salad was for?
The Real Job
Your team knows a tomato is a fruit. They're smart. They know the facts, the frameworks and the tools.
What they don't know is what's in your head. The customer you spoke to last Tuesday. The deal riding on this feature. The reason "fast" matters more than "perfect" this quarter.
Giving them this knowledge is not a nice extra. It's the job. Instructions get you compliance. Context gets you people who make the right call when you're not in the room.
So look at the last three tickets you wrote. Would a smart stranger know why they exist?
If not, you've got tomatoes in your fruit salad. And it's not your team's fault.