Articles

by Adrian McPhee

1. 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.
2. Part 1: It's 1999 Again
3. The Brochureware Moment In 1998, a retailer built an impressive website that couldn't take an order. In 2025, companies are deploying AI with the same structural relationship to their business. The transition is faster this time, and less forgiving.
4. The Strategy Deck That Ate the Company A CTO spends four days building a board pack that describes a cleaner organisation than he runs. At each management level, ambiguity resolves in favour of narrative. The deck becomes the thing the organisation manages.
5. Fake Boundaries "Customer Engagement" has a roadmap and a budget but no coherent system boundary. Governance invents boundaries for portfolio legibility. Engineering invents different ones for architecture. Both are chosen for representational convenience.
6. Part 2: How Busy Work Sustains Itself
7. The Meeting That Replaced the Work Twelve people in a room to coordinate a two-day change that takes seven weeks. Nobody owns the notification process end-to-end, so the organisation hires capable people to manage friction it created.
8. The CFO Who Killed the Platform A CFO kills a platform investment because it doesn't show ROI in year one. The cost is a visible line item. The benefits are diffuse and don't appear in any P&L. The incidents arrive months later, attributed to the wrong cause.
9. The People Who Knew Lisa sees the incoherence before anyone else. The organisation selects against her structurally: vague ownership, plans approved for political reasons, people who insist on precision classified as difficult. When she leaves, years of context leave with her.
10. Part 3: Then AI Arrived
11. The Machine That Reads Your Strategy A CTO gives an AI the strategy document, the architecture model, and the codebase. The contradictions appear in minutes. What had lived in his head for years is now inspectable evidence. The CEO asks for silence.
12. The Polished Lie A retailer deploys AI to answer leadership questions about metrics. For three months, nobody checks. Some numbers are wrong. Some are fabricated. The failure is not the AI. The failure is skipping the preconditions.
13. The Fork in the Road Two insurers, same starting point. One uses AI to write a better board pack. The other uses AI to discover whether the board pack matches reality. Twelve months later, the gap is structural and compounding.
14. Part 4: What the Competition Does Instead
15. The Process Is the Product What happens when a business process gets a real owner, a structured definition, and a machine that checks whether it matches production every week. The nine-month sequence, the costs, and the evidence that boards should expect.
16. Where This Is Hard The strongest objections to the argument: genuinely irreducible complexity, scale and legacy, why large firms centralised in the first place, and how political immune systems kill reform before evidence can appear.
17. Reference
18. What Happens Next Lisa, Marcus, and David are not edge cases. They are the ordinary consequences of a system that governs through narrative. What changed is the cost of reconciliation. The first move is smaller than you think.
19. The Strategic Context Stack Purpose, vision, mission, strategy, goals, OKRs, KPIs: what each word is supposed to mean operationally, why most organisations conflate them, and why AI reveals the incoherence instantly.
20. The Diagnostic Toolkit Five questions for boards, a writer-versus-reader scorecard, a 90-day launch sequence for the first process-owning unit, a glossary of corporate euphemism, and sample process definitions you can lift directly.
21. Method
22. Drive vs Drift AI does not just make coding faster. It makes synthesis cheap enough to run continuously. The right unit of management is the milestone artefact, the proof loop, and the weekly judgement about whether Drive is beating Drift.
23. Why Big IT Projects Fail Big IT projects fail for two reasons: they are big, and they are IT projects. The first creates coordination overhead. The second repackages business change as a delivery exercise, guarantees failure, deposits legacy, and ensures IT absorbs the blame.

See also: Chapter previews and contents · Drive vs Drift