_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.

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:

  1. Discovery

  2. Greenfield build of the new CRM

  3. Alignment with existing and documented business processes

  4. Refined mock migration

  5. Testing

  6. Staged live migration

  7. 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.

 

 

Previous
Previous

_006 Data as currency

Next
Next

_004 You *should get what you pay for