Steer, don't sequence
Architecture, teams, and AI capability pull on each other like three gravitating masses. You do not sequence a system like that. You steer it.
The roadmap is on the wall and it looks responsible. Modernization this year. The reorg next year, once the platform is stable. The AI program the year after, once the teams have settled. Three neat bars, three budgets, three owners and a logic any board would wave through.
It is wrong before the first bar starts. Not because the order is wrong, but because there is no right order.
The three things on that wall are not three projects waiting their turn. They are one big sociotechnical system, and each part pulls on the other two the moment it moves.
Issue 1 named the failure: sequencing is the trap.
Issue 2 named the destination: AI-native, not AI-ready, and you buy AI-ready by default.
This is the machinery underneath both. The three bodies themselves, what each one is, and what “moving together” looks like on a real roadmap instead of a slide.
No kit this week. Just the machinery, and the standing ask: if you have run one of these, subscribe and tell me where I am wrong.
Why three bodies, not three projects
Borrow the name honestly. In celestial mechanics, two bodies under gravity have a clean solution: you can write down where they will be forever. Add a third and it collapses. Henri Poincaré showed in the 1890s that the three-body problem has no general closed-form solution. Each mass pulls on the other two continuously, so you cannot compute one path while holding the others still. This is settled mathematics, not a metaphor I am stretching, and it is why we fly spacecraft through these systems with continuous course corrections instead of one equation.
That is your transformation. The three bodies are the architecture (the system you are rebuilding), the teams (the org that owns it: topology, cognitive load, decision rights), and the AI capability (what the model now makes buildable, and how it reshapes the other two). Move one and the other two move, whether you planned for it or not. Rebuild the platform and the team that owned the old one is now shaped for a system that no longer exists. Put a model in the loop and what is even worth building changes, and the team shape with it.
Sequencing assumes you can freeze two bodies while you work the third, then unfreeze them. You cannot. Nothing holds still while you take your turn.
Body one: the architecture
These are your systems being constantly stressed and rebuilt, and it is the one everyone books first because it feels like the foundation. It is also the one that yanks the other two hardest. A real modernization does not just swap the runtime. It changes where work happens, which means the team that grew up around the old system is now organized for a shape that no longer exists, and the AI you were going to add later suddenly has a very different surface to attach to. You cannot finish this body and hand a stable artifact to the next program. The moment it moves, it has already reached into the other two.
Body two: the teams
Melvin Conway said it in 1968 and it has never stopped being true: a system’s design mirrors the communication structure of the org that built it. Move the architecture and leave the org boxes where they were, and the old structure quietly pulls the new system back into its shape. This is the reorg that does not take, the one that gets celebrated at launch and reverts by the next quarter.
Team Topologies (Matthew Skelton and Manuel Pais, 2019) gives this a handle: organize teams around the flow of the work and manage cognitive load deliberately, or the load lands on people anyway, uninvited. The team body is not an HR exercise you run after the platform ships (or worse, an excuse for a reorg). It is the difference between a system that holds and one that erodes back into the org chart that predates it.
Body three: the AI capability
The third body is not a library you consult. It is a capability in the loop where the work actually happens, in how code gets written and reviewed, how a platform validates itself, what a team can take on. And it does not sit politely inside the box you drew for it in FY3. It reshapes the other two. It changes what is worth building at all (that is the architecture body moving again) and how many hands a thing takes (that is the team body moving again). Bolt it on at the end and you get AI-ready: a structure that can hold AI, sitting next to a system that never changed to use it. Put it in the loop from the start and it pulls its weight, and pulls on everything else.
Moving together is a verb, not a Gantt chart
Here is the part the wall chart cannot show. Steering three coupled bodies does not look like three bars in a row. It looks like one program that replans continuously, because every time one body moves you re-solve the other two. A platform decision changes the team plan this week, not next year. An AI capability lands and the backlog it was supposed to accelerate turns out to be the wrong backlog, so you change what you are building.
This is also why the vendor split is so expensive. Run modernization with a systems integrator, the org change with a transformation firm, and the AI with a separate consultancy, and you have handed the three coupled bodies to three parties who each optimize their own and none of whom own the coupling. They do not compound into capability. They compound into dysfunction, on three invoices. The alternative is not a bigger program. It is one operator holding all three, with no hand-offs across the seams where the pull actually happens.
The smallest complete example, the whole thing in motion
The cleanest version I have run looked like this. One mandate that, on a normal roadmap, would have been three projects in a line. We rebuilt a batch platform into one that ran in real time. We restructured the team around the flow of the work instead of the old function boxes. And we put a language model into a manual review step, the kind where people used to grind through a queue by hand, and took it from roughly 8% machine-handled to 80%.
Told as three programs, that is a modernization, then a reorg, then an AI pilot, each waiting on the one before it, and the review step stuck at 8% the whole time while everyone waits their turn. Told as one program, it is three bodies moving together: the platform made real-time work possible, the team shape made the platform hold, and the model in the loop was the thing that made the whole rebuild pay. Not the AI beside the process. The AI as the process, on a platform and a team reshaped to own their flow of work.
Run the coupling test on your own program
You can tell steering from sequencing in about three questions:
How many budgets and owners do the modernization, the org change, and the AI sit under, and on whose timeline? Three separate ones, each with its own year: you are sequencing.
What happens to the team plan when the architecture slips a quarter? If the answer is “nothing, that is a different workstream,” the bodies are not coupled on paper, which means they will collide in practice.
When does the AI capability get to change what you build, not just how fast? If the answer is “after the platform is done,” the third body is bolted on, not in the loop.
Run it on your own program before the next planning cycle, not on a vendor after.
The whole thing, in one line
You do not sequence a system whose parts pull on each other. You steer it. Together, or it does not really move at all.
Coming up
Next week I go hands-on inside one body, the AI capability, and what “in the loop” actually means in the delivery pipeline: the model as a build lever, the model as an architectural mirror, and the number that tells you it is working instead of just present.
More soon. :-]
Sources
Because none of this comes only from my head. Every link checked.
The physics: the three-body problem’s lack of a general closed-form solution is due to Henri Poincaré (1890s); a standard scholarly treatment is June Barrow-Green, Poincaré and the Three Body Problem (American Mathematical Society, 1997). Scholarly / peer-reviewed.
The org mirror: Melvin E. Conway, “How Do Committees Invent?“ (Datamation, 1968). The origin of Conway’s Law.
The team body: Matthew Skelton and Manuel Pais, Team Topologies (IT Revolution, 2019). Practitioner book, not peer-reviewed.
The operating-model failure mode (callback to Issue 2): Mik Kersten, Output to Outcome (IT Revolution, 2026). Practitioner book.
I make this Substack thanks to readers like you!