Iteration eats planning for lunch

Anyone trying to get something done inside a company faces an implicit choice: how much to settle before they start. Four years of moving from a large company to a much smaller one showed me in practice what I’d only seen in theory, mostly out of necessity. You plan the destination with care and hold the route to it loosely. Agree where you’re going and what success looks like, put real effort into that, then start and learn the route as you go. In a company that route is two things, the sequence of steps and who does what, and neither is best fixed in advance. Living that turned a phrase I’d once have found glib into one I’m convinced of: when it comes to the route, iteration eats planning for lunch.

Planning the intent is essential, and worth slowing down for. The clearer and more agreed it is, the better every downstream decision becomes, because people make their own calls when they know exactly what they’re aiming at. Planning the process is a different thing, and it’s the part iteration beats. You can’t map the best path to an answer you don’t have yet, and the most interesting work is exactly where you don’t have it at the start.

A detailed plan of the route is a confident bet placed at the moment you know the least. Every week of doing the work teaches you something the plan couldn’t have known, and the advantage goes to whoever folds that learning back in fastest.

Who does what is where the leverage is

Of those two parts, the sequence of steps mostly sorts itself out once people get going. Who does what shapes everything else, and there are two very different ways to handle it.

The first is to assign the work: split the process into pieces and give each to whoever owns that kind of task. The analyst does the first part, hands to modelling for the model run, who hand to finance for the budgeting, and on it goes. It looks orderly and accountable, and it’s how most large processes are built. The cost is that every boundary is a place for the work to stop and wait. Across an insurer, a hospital group, a bank, a logistics operator, a retailer with a real pricing function, the same relay shows up, and those boundaries are where the pace quietly drops.

The second is to make capabilities available. Instead of handing the model run to modelling as a task, the team makes that capability available for the analyst to use herself: their rules, their code, their tool, usable by any colleague. The work stays in one pair of hands, the loop stays tight, and she can run it, read the result, sharpen the question, and run it again without leaving the flow. Everything I’ve seen, in my own businesses and in other industries using data and AI well, says this second move is far more powerful, and that the gap is one of the most underrated things in how organisations are built. It shows up as speed, and as enormous FTE cost.

It’s more powerful for two reasons. The shallow one is iteration: someone who runs the whole loop themselves goes round it ten times to a relay’s once, and notices much sooner when the destination itself needs adjusting. The deeper one is that it changes what knowledge is worth. An expert team’s work locked up as a task is rationed by their availability. Made available as a capability others can draw on, it gets used many times over, by many people, with no bottleneck. Their expertise stops being a queue and becomes leverage.

None of this means letting people reach in and redesign that work. The owning team keeps how it’s built, how the data is governed, what good looks like. Making it available means others use what it produces, not change how it’s made. Owning how something is done and consuming what it produces are two different things, and a team that opens its work up keeps all of its authority while stepping out of the queue in front of its own knowledge.

Amazon already ran this experiment

The clearest proof is one most people in tech already know, and it earns its fame. Around 2002, Jeff Bezos issued the mandate Steve Yegge later described in his much-shared 2011 account: every Amazon team had to make its data and tools available through service interfaces, and from then on teams could only deal with each other through those interfaces. No reaching into another team’s systems, no back doors. Crucially, it said nothing about how teams built anything or which technology they used. Each team kept full control of its own service. What it insisted on was that everyone else could use that service cleanly and independently, without a meeting or a handoff. That is the shift from assigning tasks to making capabilities available, enforced across a whole company, and one thing it eventually produced was AWS, because a company whose every internal capability is already consumable through a clean interface is most of the way to selling those capabilities to the world.

What strikes me now is how much cheaper that move has become. Amazon needed an edict and years of re-engineering. A lot of what used to be handed to a specialist team as a task can now be done directly, because the tools are good enough that a capable generalist can run the analysis, draft the query, or model the scenario themselves. That doesn’t make the specialist team less valuable. It frees them to build and improve the capability everyone draws on, rather than being the queue in front of it. What once took Amazon’s resources is becoming available to organisations of any size.

I really hope this spreads, though habits are sticky and a way of working doesn’t turn over in a quarter. What I don’t think I’m wrong about is how much is now on offer: the chance to agree an objective, start, and learn the way there at the pace of a whole organisation, with far more return from every hour a colleague works and far more value from the assets a company has already built.

Agree the destination, make the capabilities available, and let people learn the route by doing. I suspect the organisations that lean into that, of any size, are going to surprise people with how much ground they cover.