Frameworks / The Solo Trap
The Solo Trap
The belief that a transformation of this scale can be run inside one organisation’s boundary. It is the most expensive of the three traps — because it stays invisible until the integration work arrives.
The Pilot Trap and the Technology-First Trap announce themselves eventually — a portfolio with nothing in production, an initiative named after a tool. The Solo Trap hides longer. An organisation can make real progress alone, for a while, and mistake that early momentum for proof that it can finish alone. The bill comes later, all at once, when the work reaches the parts no single organisation controls.
Why going alone is invisible until it isn’t
The early stages of any transformation are genuinely internal — strategy, initial build, a contained proof. A capable organisation does these well on its own, and the success is real. But transformation at scale eventually depends on things outside the boundary: partners, platforms, standards, suppliers, regulators, an ecosystem of others moving in the same direction. Those dependencies are quiet until you reach them, and then they are the whole problem.
By that point the organisation has usually committed to an architecture, a timeline, and a set of assumptions built entirely on internal control. Discovering the ecosystem dependency at that stage is not a course correction; it is a rebuild. The cost was always there. It was simply deferred until it was maximal.
How to see it in the field
The tell is a transformation plan in which every critical dependency is internal. Read the plan and ask: what here requires someone outside this organisation to move? If the answer is “nothing,” the plan is either genuinely small — or it has quietly assumed away the ecosystem it will eventually need. At real scale, self-sufficiency on paper is a warning, not a strength.
A second tell: partnerships are treated as a procurement step scheduled for late in the programme, rather than as a design input from the start. When “we’ll bring in partners once the core is built” is the plan, the core is usually being built in a shape partners cannot connect to.
Getting out of it
Map the ecosystem dependency before you commit to the architecture, not after. Ask early which parts of the outcome you can never own — the standards you must interoperate with, the platforms you will build on, the partners whose participation is load-bearing — and design outward from those constraints. Bringing the ecosystem in early costs a little speed at the start. Bringing it in late costs the build.
The reframe is simple: stop asking “what can we build?” and start asking “what must we build with others, and how do we design for that from day one?” The strongest transformations are not the most self-sufficient. They are the ones best connected to a moving ecosystem.
Part of the Frameworks series. Related: the Pilot Trap and the Technology-First Trap — together, the three ways AI programmes stall before production.