The Separation

How software-dependent corporates built a structural separation between "the business" and the people who build the systems, and why AI makes that separation visible for the first time.

If you work inside a software-dependent corporate, or recently left one, you may suspect the organisation was managing representations of work instead of the work itself.

Somewhere around 2005, a phrase entered the vocabulary of these organisations that quietly restructured the relationship between the people who build systems and the people who decide what to build. The phrase was “the business.”

It sounds harmless, even useful: over here, the business; over there, technology. One side decides what is needed, the other side delivers it.

Except that “the business” somehow does not include the people who write the software, define the data models, maintain the systems, and understand, in painful detail, how customers actually receive value. Half the workforce is treated as a support function to the other half. The people who run the machinery do not count as part of the machine’s purpose.

This did not come only from org charts. It was reinforced by the outsourcing era and by the rise of internal IT as a service function to the rest of the firm. One side defined needs. The other, whether an internal department or an outside vendor, was expected to deliver against them. The language of “the business” made that arrangement sound natural. It encouraged companies to see technology not as part of the business itself, but as a function serving it.

Once you see the split between “the business” and its own technologists, you see almost everything that follows: strategy decks that describe systems that do not exist, product roadmaps for products that are really budget labels, architecture diagrams that bear no relationship to production, and meetings designed to reconnect people who would never have needed reconnecting if they had been allowed to own a process together in the first place.

The most exquisite irony is that, having separated engineers from the business, the organisation then spends millions trying to glue them back to it through OKRs, alignment meetings, product owners, delivery leads, quarterly planning rituals, and translation layers of every description. A structural wound turned into a permanent industry.

The separation of engineers from the business had consequences. It encouraged companies to package operating change as technology delivery: programmes, handovers, requirements documents, governance forums, and “IT projects.” Why do big IT projects fail? Because they are big, and because they are IT projects. The first creates scale, delay, and coordination overhead. The second misclassifies a redesign of how the business works as a delivery exercise assigned to a separate function. Once that misclassification is in place, the organisation starts managing representations of work instead of the work itself.

Managing representations of work instead of the work itself is busy work: not laziness, not incompetence, not the absence of effort, but the industrial production of activity that looks like progress, feels like progress, and is measured as progress while remaining disconnected from the reality of how the organisation creates value.

For two decades, firms could absorb the cost of this arrangement because their competitors were organised in roughly the same way. The playing field was level, and the level was low. AI reduces the cost of checking whether strategy, systems, and operations actually match, which makes the mismatch harder to hide and faster to punish.

It’s 1999 Again

If you are old enough to remember 1999, you remember the mood. Every company needed a “web strategy.” Most of them built brochureware: a website that looked modern and changed almost nothing about how orders were fulfilled, inventory was managed, or customers were served. The CEO presented the website to the board. Everyone applauded. The website had no connection to the machinery of the business. It was modernity bolted on to an unchanged operating model.

The winners did not have prettier websites. They built structure: systems that connected the new interface to their actual operations, organisations where the people who understood the technology had the authority to change the business, feedback loops between what customers did and what the system offered.

The same mistake is being repeated with AI. Companies are deploying copilots, chatbots, document generators, and meeting summarisers and calling it “AI transformation.” The underlying structure is unchanged: strategy is still narrative, ownership is still diffuse, and nobody can describe a core business process from end to end in a form the organisation can test.

What is different this time is that AI makes reconciliation cheap. Previous tooling could inspect fragments: observability could show system behaviour, static analysis could inspect code, dashboards could summarise metrics. What most organisations lacked was a cheap, flexible way to compare many different artefacts against each other, quickly enough and plainly enough for ordinary management use. AI changes that. A machine can read the strategy document alongside the architecture model, the deployment manifests, the process definition, the incident log, and the codebase, then tell you where the claims do not match the system. Not perfectly, not infallibly, but cheaply enough to run every week and fast enough to matter.

Cheap reconciliation is the real fork in the road. AI can help you write a better narrative about the business, or it can help you discover whether the business you describe is the one you actually run. The first path accelerates fiction. The second produces accountability.

The three claims

The argument makes three claims. First, that software-dependent corporates have built structures which systematically produce activity disconnected from operational reality. Second, that AI changes the economics of detecting and correcting that disconnection. Third, that organisations which make the structural correction will compound an advantage that narrative-governed competitors cannot close by deploying more AI on an unchanged structure.

The first claim is a pattern diagnosis supported by recurring structural observations across industries. The second is a technology assessment: reconciliation tools that were expensive and episodic are now cheap and continuous. The third is a forward-looking competitive argument, not a prediction but a structural logic whose strength depends on the organisation, its market, and the quality of its execution.

Published research consistently finds that 30–40% of technology delivery capacity in large firms is consumed by coordination rather than production (Stripe’s Developer Coefficient study found 42%; IDC and DORA research corroborates the range). Operational resilience frameworks mandated in the EU (DORA) and the UK (FCA) now require firms to demonstrate end-to-end process traceability, creating regulatory pressure independent of the competitive argument.

None of this means all coordination is waste, all centralisation is theatre, or that every firm should restructure immediately. Where This Is Hard addresses the strongest counterarguments directly.

If you have ever sat in a meeting and thought, “none of that was real,” that instinct was correct.

The Brochureware Moment →