_005 Too Many Cooks
I recently ran a whiteboarding session with a client as part of our usual Red Shift process: distilling the what of an idea into the how, before finally moving onto the when. It’s simple.....
Michael Gilgallon
CEO, Red Shift
Insight
I recently ran a whiteboarding session with a client as part of our usual Red Shift process: distilling the what of an idea into the how, before finally moving onto the when.
It’s simple.
We take the origin of an idea, walk the client through our structure, and require them to define exactly what outcome they expect — and, crucially, the most significant implications that follow from it. That stage alone often exposes paradoxes, contradictions, and gaps.
To me, this is routine.
Yet in many companies we work with, this kind of session is treated as alien — even groundbreaking. Which is strange.
There are 5 reasons that come to mind which might explain why this discipline is so seemingly rare.
1. Culture — people are afraid of friction
To refine an idea into something measurable and buildable, you need friction:
Challenge
Debate
Concede
Resist
“Passionate discussion”
Occasional swearing
Politically minded environments find this threatening.
But from a Product–Engineering perspective, it is absolutely essential.
Mission clarity only emerges when ideas are interrogated — not rubber-stamped.
Without psychological safety and radical intellectual honesty — especially, necessarily, from leadership — you cannot refine vague ideas into actionable requirements. No process or framework can compensate for the absence of this basic filter, this reality check.
2. Scale — clarity decays at every handover
The larger the organisation, the further an idea travels before anyone writes a line of code. In software this often looks like:
CEO → CTO → Product Manager → Project Manager → Delivery Manager → Scrum Master → Lead Engineer → Engineer
At every exchange:
Scope mutates
Clarity erodes
Interpretations multiply
Key personalities frequently mistake “ownership” for “iteration rights,” modifying concepts before passing them down. By the time the engineer receives it, the original intent is often unrecognisable.
(For a deeper dive, see our earlier piece 001 Fidelity of Comprehension.)
3. Small teams are not the only answer
A superficial reading suggests the solution is to keep companies — or teams — small.
Intuitive, but not true.
Large organisations can maintain clarity.
The US tech giant Asurion, for example, excels with the Product–Engineering handshake. What they get right:
Clear boundaries
Clear expectations
Minimal middle management
Compartmentalised teams
Small, tightly collaborative working groups
It’s not size that kills clarity — it’s structure.
4. Sometimes the ask is simply too big
This isn’t ideation vs execution.
It’s complexity vs your organisation’s working memory.
Some requests are too large or too intertwined to execute as a single project.
Example: migrating tens of millions of CRM records.
The logical approach looks like:
Discovery
Greenfield build of the new CRM
Alignment with existing and documented business processes
Refined mock migration
Testing
Staged live migration
Final full migration
Trying to rebuild the CRM, deprecate the old one, and migrate all live data in one heroic push is, if we’re being charitable — illogical…..
Even the best engineers in the world cannot survive irrational planning.
5. Stay single-threaded
Another clarity-killer: brilliant teams being pulled in too many directions.
I’ve lost count of how many brilliant people I’ve seen punished for competence by being loaded with ever more parallel work, often of inconsistent priority, until something inevitably slips.
No matter how capable you are, you will always perform better doing one thing at a time, than two things simultaneously. This is logically irrefutable, much less the neuroscience which substantiates this truism.
If you need your team to deliver three things quickly, having them attempt all three at once guarantees that each will be exponentially slower. The correct approach — the correct approach — is:
Do one thing exceptionally well. Finish it.
Then move to the next.
Yet this self-evident truth is rarely followed. Again, a team may do this once, well, and then be rewarded for their success with greater load. Quality and efficiency give way to volume.
The tell-tale sign is the company roadmap. Ask yourself:
Is it clear?
Is it realistic?
Has everyone seen it?
Does everyone understand it?
Does it override everything else in priority? (Hint: it’s supposed to — that’s kinda the point...)
If the answer to any of those is “no,” you’re probably multi-threaded in all the wrong ways.
The simple rule
If you cannot express your idea clearly in a one-page document that your own team can digest immediately, the probability of that recipe surviving intact as it passes from one cook to another is effectively zero.
When it comes to preserving clarity: Less is more.
