Trap 1 - The speed

The deadliest animal on Earth

A warm summer night, the window open, everyone asleep. Then a thin whine circles your ear. Light on: nothing. Light off: it’s back. By two in the morning you are standing on the bed with a slipper, beaten by a few milligrams of insect.

Sharks get the films and a week of television every summer, yet they kill a handful of people a year. The mosquito is the deadliest animal on Earth: malaria alone, which it carries, kills more than half a million people a year, most of them young children.

The danger we fear is rarely the one that kills us. We watch the water for fins, while something small does the real damage, one bite at a time.

Death by a thousand yeses

Over 25 years I have watched several large programs fail. Serious budgets, talented teams, executive sponsorship. The post-mortems almost always found a shark: too expensive, too slow, poor quality, over-engineered. Those verdicts were rarely wrong. They were often incomplete.

Nobody ever decides to lose focus. It happens one reasonable yes at a time. Can we just add this for the regulator demo? Yes, it’s small. The new sponsor would like a mobile-first version. Yes, we can run both for a while. Can we pilot it in Spain too? Yes, it’s the same product.

Each bite is harmless. Together they carry the disease: work started and never finished, priorities that never stay put, and teams that learn direction is negotiable. Budgets get spread across a dozen half-built products. Teams hedge, wait or build twice. Architects design roads in every direction, because nobody chose one. And when the program finally fails, it fails on cost, speed and quality, exactly where the post-mortem will look.

That is the speed trap: starting more than you can finish, and changing direction faster than you can arrive.

The ten faces of the trap

Ten shapes, in three families: what we start, what we let in, and what it costs. Most unfocused programs show four or five of them.

What we start

• Too many open fronts. Twelve strategic initiatives for an organization that finishes three a year. Each one has a sponsor, a budget line and a kickoff deck; none has the people it needs.
• A roadmap of starts. The roadmap shows when things begin, never when they end. Progress is reported as “launched,” so starting feels like delivering.
• Everything is priority one. When every initiative is critical, none is. Teams quietly set their own priorities, and they rarely match the sponsor’s.

What we let in

• The small reasonable yes. A demo for the regulator, a request from a key client, a quick win for the board. Each addition is too small to refuse, and nobody counts the total.
• The new sponsor’s pivot. A new executive arrives and wants their mark on the program. The direction changes, the reasons don’t.
• Two versions in parallel. Instead of choosing, the program builds both: web-first and mobile-first, the old process and the new one, “for a while.” The while never ends.

What it costs

• Zombie initiatives. Work that nobody stopped and nobody funds properly. It keeps running “just in case,” consuming people, infrastructure and attention.
• The switching tax. People spread across four or five commitments spend more time reloading context than doing the work.
• Full queues, slow flow. Everything is in progress, so everything waits for something else. Lead times stretch, even though everyone is busy.
• Speed mistaken for direction. Velocity charts go up, demos look great, and the program is no closer to its outcome than six months ago.

Counting the bites

The swarm has a name in engineering: work in progress. It is invisible on a roadmap, because a roadmap shows what we started, not what we finished. Two simple laws make it visible.

The queue. Little’s law says the average time a piece of work spends in a system equals the work in progress divided by the throughput. Run twelve initiatives with the capacity to finish three a year, and each one takes four years on average. Run six, and the same people finish each one in two. Nobody works harder. Value simply arrives sooner, because an unfinished initiative delivers nothing.

The switching tax. Gerald Weinberg estimated what happens when one person or team carries several projects at once. Every extra project costs time spent reloading context:

Treat the figures as an order of magnitude. The shape is what matters: past three parallel commitments, most of a team’s week goes to swatting, not building.

One last detail from biology, because it fits too well. Mosquitoes find you by the carbon dioxide you breathe out: the harder you breathe, the more you attract. Organizations work the same way. A busy, well-funded program breathes hard, and draws every new request in the building.

Early signals

You can hear the whine long before the itch:

• More initiatives are open than the organization finishes in a year.
• Nobody can name the one outcome the program exists to move.
• The roadmap shows start dates, not finish dates.
• People work on four or more initiatives at once.
• When two initiatives conflict, nobody can say which one wins.
• Old work keeps running “just in case” after a change of direction.
• A new sponsor arrived, and the priorities changed within a month.
• Delivery metrics look great, while business outcomes haven’t moved.
• Nothing has been stopped in the past year.

Nets, not harpoons

Nobody fights mosquitoes with a harpoon. What works is boring: a net over the bed, a screen on the window, and draining the water before it breeds. Focus works the same way. It isn’t heroic; it’s hygiene: decide what you won’t do, finish before you start, and change direction only on purpose.

1. Name one North Star. The one outcome the program exists to move, stated clearly enough that a team can use it to say no. The roadmap may change many times; the North Star changes rarely, and only on purpose.
2. Write the non-goals. A short, public list of good ideas you won’t pursue this year. It is the most useful page in any strategy, because a decision that rules nothing out isn’t a decision.
3. Cap the work in progress. A fixed number of initiatives in flight; three is plenty. A new one starts only when one finishes or is stopped.
4. Report finishes, not starts. Show what was delivered and what it changed, and make the roadmap’s end dates as visible as its start dates.
5. Tell a pivot from spin. A real pivot is triggered by evidence, decided explicitly by one owner, and closes the old work on purpose. Spin is triggered by opinion, happens gradually, and keeps everything running “just in case.”
6. Change direction at checkpoints. A fixed cadence, say each quarter, protects teams from continuous re-steering in between.
7. Set kill criteria before starting. Decide in advance what result would make you stop. A pivot then executes a prior decision instead of following a mood.
8. Close what you leave. Every change of direction ends with the old work stopped and decommissioned. Track how much delivered work was later abandoned: it is the honest metric of focus.

Strength isn’t stubbornness. Holding a decision against evidence is its own failure. The point is not to never change course; it is to change course rarely, explicitly, and for reasons you could write down.

Why decisions don’t stay decided is a trap of its own: see The decision trap.

What to avoid

• Starting a new initiative without stopping one.
• Measuring progress by what was launched.
• Calling everything priority one.
• Keeping old work alive “just in case” after a pivot.
• Building two versions in parallel instead of choosing.
• Approving a new initiative without naming what it replaces.
• Spreading key people across more than two or three commitments.

The AI twist

Mosquitoes breed in standing water: not lakes, but puddles. An old tire, a forgotten flower pot, a bucket left out after the rain. AI is filling every puddle. When building is cheap, changing direction feels cheap too, so why not try everything? Every quick prototype that reaches production becomes still water that breeds. Code was never the whole cost of a change of direction. Integration, data, operations, users and attention move at the same speed as before. The failure isn’t eliminated; it is displaced. The build looks fast and cheap, and the bill arrives later as a swarm: integration that never stabilizes, operations drowning in variants, users who stop following. Worse, the swarm is harder to see: when everything ships in days, a program that changes direction every month looks productive.

But AI can also be the net. Prototypes that took weeks now take days, so you can test a direction in a throwaway sandbox before committing to it, and stop cheaply when the evidence says no. And AI makes the portfolio visible: it can map what is really in flight, flag zombie initiatives, and compare what was started with what was finished. Used that way, AI doesn’t make you go in circles faster. It lets you explore widely while committing narrowly.

Close the window, hang the net

I don’t want to be unfair to the sharks. Programs do fail on cost, speed, quality and complexity. But those are usually where failure becomes visible, not where it begins.

Speed multiplies direction. With a clear North Star, the AI software factory is the best thing to happen to our profession in a long time. Without one, it lets us go in circles faster, and spreads the cost so thinly that nobody notices until the end.

So the next time a program review goes hunting for its shark, ask a gentler question instead: what had we decided, what had we decided not to do, and did we hold to it?

Then close the window. Hang the net. Drain the puddles. And sleep well.

Have you lived through a program eaten by a thousand small yeses? I would genuinely love to hear your story.

All situations described here are composites, drawn from many programs over 25 years.