The problem surfaced six weeks later, and it surfaced quietly. A coordinator had asked the assistant to confirm the customs documentation required for a shipment of lithium battery packs into the United Arab Emirates. The assistant answered with total fluency. It cited a specific regulation, named the required certificate, and even gave a plausible-sounding reference number. Every part of that answer was wrong. The regulation it cited did not govern that category of goods, the certificate it named did not exist under that title, and the reference number was a fabrication assembled from the statistical shape of real reference numbers. The coordinator, reasonably, trusted it. The shipment was held at the border, and the resulting delay cost the client a contract penalty that ran well into five figures.

What made this incident instructive was not that the model got something wrong. Every model gets things wrong. What made it instructive was that the system had no way of knowing it had got something wrong, and no way of telling the coordinator that this particular answer was less trustworthy than the shipment-window answers it had been giving correctly for six weeks. The confidence of the delivery was identical in both cases. The architecture treated a hallucinated customs regulation exactly as it treated a database lookup of a delivery date. That is the real failure, and it is an architectural failure, not a model failure.

I have now seen this pattern across enough deployments, in financial services, in healthcare-adjacent operations, in legal support tooling, to be confident it is the defining risk of putting language models into production. Teams pour their effort into making the model answer well and almost none into what the system does when the model answers wrongly. They optimise for the demo, where every question has a clean answer, and they ship an architecture that has no immune system.

The Root Cause: Confidence Is Not Correctness

The instinct when a model hallucinates is to reach for a better model, or to fine-tune, or to write a more careful prompt. These are not useless, but they misdiagnose the problem. A hallucination is not a bug that a sufficiently good model will eventually stop producing. It is an intrinsic property of how these systems work. A language model generates the most statistically plausible continuation of a sequence of tokens. Most of the time, in domains where the training data is dense and consistent, the most plausible continuation is also the true one. In the seams, the rare regulation, the specific reference number, the edge-case entity that appears only a handful of times in the training corpus, the most plausible continuation and the true one diverge, and the model has no internal mechanism that distinguishes the two. It is not lying. It has no concept of truth to lie about.

This is where I find it necessary to draw a distinction that most teams collapse. There is a difference between **model accuracy** and **system reliability**, and they are not the same engineering problem. Model accuracy is about how often the model produces a correct answer. System reliability is about what happens across the whole distribution of outputs, including the wrong ones, whether wrong answers are caught, contained, flagged, or allowed to propagate to a user who will act on them. You can materially improve model accuracy and leave system reliability exactly where it was, because reliability is determined not by the average quality of outputs but by the blast radius of the bad ones.

The logistics assistant had reasonable model accuracy. Ninety-something per cent of its answers were fine. The reason it caused damage is that its system reliability was effectively zero: there was no layer between the model’s output and the coordinator’s action. The correct answers and the fabricated regulation flowed through the same unguarded pipe.

Once you frame the problem this way, the engineering task changes. You stop asking “how do we make the model hallucinate less?”, a question with sharply diminishing returns, and start asking “how do we build a system that remains safe even when the model hallucinates?” That is a tractable architectural question, and it is the one worth answering.

The Four-Layer Guardrail Architecture

What I use, both when auditing systems like the logistics assistant and when designing production LLM deployments from scratch, is a defence-in-depth model I call the **Four-Layer Guardrail Architecture**. The principle borrowed from safety engineering is that no single control is trusted to be sufficient. Instead you place independent layers between the model and the consequence, each catching a different class of failure, so that a hallucination has to defeat all four to reach the user unchallenged. The four layers are grounding, verification, confidence gating, and fallback.

The first layer is grounding. The single most effective structural intervention against hallucination is to stop asking the model to recall facts from its parameters and instead force it to answer from a controlled, retrieved context. This is what retrieval-augmented generation does when it is done seriously rather than as a demo. The model is not asked “what is the HS code for turbine parts?”, it is given the relevant section of a maintained classification database and asked to extract the answer from that provided text. The crucial and frequently skipped discipline is that the system must be able to distinguish “the answer is present in the retrieved context” from “the answer is not present, so I will fill the gap.” A grounded system that cannot detect an empty retrieval will hallucinate exactly as freely as an ungrounded one, it will simply do so while looking authoritative. Grounding buys you enormous reduction in hallucination, but only if it is paired with the honest handling of the case where grounding fails.

The second layer is verification. Grounding reduces hallucination; it does not eliminate it, because the model can still misread, over-extrapolate, or stitch together retrieved fragments incorrectly. The verification layer checks the output against something independent before it is trusted. This takes different forms depending on the domain. For structured claims, a reference number, a code, a date, a monetary figure, verification can be deterministic: does this HS code actually exist in the classification table? Does this regulation number resolve to a real regulation? These are cheap, exact checks and they catch precisely the fabrication that damaged the logistics client. For unstructured claims, verification is often a second model call whose job is not to answer the question but to interrogate the first answer: “Here is a proposed answer and the source text it was supposedly drawn from. Is every claim in the answer actually supported by the source?” A model is far more reliable as a critic of a specific claim against a specific source than as an oracle generating claims from nothing.

The third layer is confidence gating. This is the layer whose absence caused the sixty-coordinator system to fail, and it is the one most teams omit entirely. Every answer that leaves the system should carry a reliability signal, and the system’s behaviour should change based on that signal. Where retrieval was strong and verification passed cleanly, the answer flows through directly. Where retrieval was thin, or verification flagged an unsupported claim, or the question fell into a category the system handles poorly, the answer must be visibly downgraded, surfaced with a warning, routed for human review, or withheld. Confidence gating is what allows a system to say, in effect, “I am sure about the delivery window and unsure about the customs regulation,” which is exactly the distinction the logistics coordinator needed and never received. The confidence signal does not have to be sophisticated. Even a coarse three-tier signal, answered from strong source, answered from weak source, could not ground, transforms the safety profile of the system.

The fourth layer is fallback. When the upper layers determine that a reliable answer cannot be produced, the system needs a defined behaviour that is not “generate something anyway.” The correct fallback is almost never a raw model guess. Depending on context it is a graceful refusal (”I don’t have a confident answer to this; here is who to ask”), an escalation to a human queue, a narrower deterministic answer, or a request for clarification. The discipline here is that the fallback path must be designed and tested with the same seriousness as the happy path, because the fallback is precisely what runs during the incidents that cause damage. A system whose fallback is untested does not have a fallback; it has a hope.

The reason to hold all four as distinct layers rather than blurring them into “we’ll add some validation” is that they fail independently and catch different things. Grounding fails silently on missing data. Verification catches unsupported extrapolation. Confidence gating catches the systemic uncertainty that no single check surfaces. Fallback contains everything that slips through. Remove any one layer and you reopen a specific, nameable class of production incident.

Implementation: What Changed at the Logistics Company

We did not replace the model at the logistics company. The model was fine. We rebuilt the system around it.

Grounding came first, because it was cheapest and highest-impact. The assistant had technically been retrieving data, but its retrieval quietly returned the top matches even when nothing genuinely relevant existed, and the model dutifully answered anyway. We changed the retrieval to return an explicit “no sufficiently relevant source found” signal below a similarity threshold, and we changed the prompt contract so that the model was instructed, and tested, to refuse rather than improvise when the context was empty. That single change eliminated the largest category of fabrication, because most of the dangerous answers had come from questions the underlying data simply could not answer.

Verification came second. For the structured entities that mattered most, HS codes, certificate names, regulation references, we added deterministic checks against the authoritative tables. If the model produced an HS code, the system confirmed it existed before showing it. If it named a certificate, the system checked it against the maintained registry. Any answer containing an unverifiable structured entity was automatically downgraded. This was perhaps two weeks of engineering work and it directly closed the exact failure mode that had cost the contract penalty.

Confidence gating was the cultural change more than the technical one. We introduced a visible three-tier badge on every answer: green for answers grounded in a strong source and fully verified, amber for answers with thin grounding or a partial verification flag, and red for anything the system could not ground, which now triggered the fallback rather than an answer. Coordinators were briefed that amber meant “check before you act” and red meant “the system is telling you to ask a human.” Adoption of the badges was not automatic, I will come to that, but where they were heeded, the incident rate on high-stakes queries dropped to near zero over the following quarter.

What did not work smoothly was the second-model verification for unstructured answers. It added latency that coordinators noticed and resented, and its own judgments were occasionally wrong in ways that eroded trust in the badges. We ended up reserving model-based verification for the genuinely high-consequence query categories and leaving the routine shipment-status questions to grounding and deterministic checks alone. That selective application was the right answer, but we only found it by getting the blanket application wrong first.

Risks and Trade-Offs

This architecture is not free, and it is not universally warranted. The most immediate cost is latency and expense. Every verification call, every deterministic lookup, every confidence computation adds time and money to what could have been a single model call. For a customs assistant where a wrong answer costs a contract, this is obviously worth it. For a low-stakes internal tool that summarises meeting notes, the full four-layer treatment would be absurd over-engineering. The layers should be provisioned in proportion to blast radius, and one of the more common mistakes I see is teams applying heavy guardrails uniformly and then abandoning the whole approach because it made an unimportant feature slow.

The subtler risk is what I call the trust-calibration trap. Confidence gating only works if users respond to the signals, and users will only respond to signals that are accurate. If the amber badge fires too often on answers that turn out to be fine, coordinators learn to ignore it, and a system with an ignored guardrail is arguably more dangerous than a system with none, because it manufactures a false sense of oversight. Getting the thresholds right is an ongoing calibration exercise, not a set-and-forget configuration, and it requires someone owning the false-positive rate as a live operational metric. Teams that ship guardrails and never tune them tend to watch those guardrails become invisible within a quarter.

There is also a failure mode in verification itself: the verifier can hallucinate. A second model asked to check the first is still a model, and it can wrongly approve a bad answer or wrongly reject a good one. This is why the deterministic checks, wherever a claim can be checked deterministically, are worth far more than model-based verification. Reserve the model-as-critic pattern for the claims that genuinely cannot be checked any other way, and never treat its approval as proof.

Finally, none of this addresses the case where the retrieved source itself is wrong. Grounding a model in an out-of-date regulation database produces confident, verified, well-gated answers that are also incorrect. The guardrail architecture protects against the model inventing things; it does nothing about the quality of what you ground it in. That remains a data-governance problem, and it sits upstream of everything discussed here.

Strategic Reflection

The organisations getting real value from language models in production are not the ones with the best models. They are the ones that stopped treating the model as the system and started treating it as one probabilistic component inside a system that must remain trustworthy even when that component is wrong. This is a familiar move for anyone who has built serious infrastructure. We do not trust individual network packets to arrive; we build protocols that remain reliable across an unreliable medium. We do not trust a single disk; we build redundancy around the assumption of failure. The language model is an unreliable medium of extraordinary usefulness, and the engineering discipline it demands is the same one we have always applied to unreliable components: assume failure, contain the blast radius, and never let confidence be mistaken for correctness.

The logistics coordinator’s real problem was never that the model hallucinated a customs regulation. It was that the system spoke with one voice for everything it knew and everything it invented. The entire task of production AI architecture is to give the system a second voice, the one that says, clearly and in time, “I am not sure about this one.” Every organisation deploying these tools will eventually learn this. The only question is whether they learn it from an architecture diagram or from a shipment held at a border.

On paper the programme was healthy. Fortnightly steering committee. A RAID log with several hundred entries. A delivery partner with a respectable name and a methodology with an even more respectable acronym. Integration, data-migration and change-management workstreams, and a PMO producing a status pack thick enough to prop open a fire door. By every conventional measure of programme governance, it was being run correctly.

And yet nothing moved. A decision that should have taken an afternoon took three weeks, because it touched four workstreams and no one could say which one owned it. A configuration change that looked trivial in the demo required sign-off from a forum that met monthly, so a two-hour task waited twenty-eight days for permission. The programme was not failing dramatically. It was quietly strangling itself.

Here is the thing that took me too long to understand about digital transformation failure, and that I now look for first: the problem is almost never scope, and it is almost never effort. It is complexity, and complexity is something a programme does to itself.

Complexity Is Not Scope

The word “complexity” gets used loosely, and that looseness is part of how the problem hides. People routinely conflate complexity with scope, and the two are not the same thing.

Scope is the volume of work a transformation intends to do, the number of processes, systems and users in the target state. Complexity is the number of interdependencies between the parts, and the degree to which those interdependencies are hidden, undocumented, or governed by different owners. You can double the scope of a programme and, if the parts remain loosely coupled, barely increase its difficulty. You can hold scope perfectly constant and, by adding a few cross-cutting dependencies and a couple of extra approval gates, make it structurally unmanageable.

This distinction matters because almost every instinctive management response to a struggling transformation adds complexity in the name of reducing risk. A decision keeps going wrong, so a new approval step appears. Two teams keep colliding, so a coordination forum is created. A supplier delivers something unexpected, so a more detailed specification process is mandated. Each intervention is locally rational. Each adds an interdependency, a handoff, or a gate. The aggregate effect, which no single intervention is responsible for and no single owner is accountable for, is a system harder to change than the one it replaced.

Fred Brooks drew the underlying distinction forty years ago in No Silver Bullet: some complexity is essential, inherent to the problem you are solving, and some is accidental, an artefact of how you chose to solve it. His argument was about software. It applies with more force to transformation programmes, because programmes generate accidental complexity through governance in a way codebases generate it through architecture, and unlike code, nobody refactors a governance structure.

Complexity of this kind is structural rather than individual. It emerges from the relationships between parts of the programme, not from the competence of anyone within it. You can staff a transformation with excellent people and still watch it seize up, because no individual is positioned to see the whole dependency graph. Each person optimises their own workstream; the interactions between workstreams are nobody’s job. This is why “the team needs to try harder” is the wrong diagnosis. Effort applied inside a badly coupled system does not reduce the coupling. It usually tightens it.

What follows is the framework I use to name the specific forms this takes. There are five, and they are deliberately chosen to be non-overlapping: each addresses a different surface of the programme, how the work is divided, who is allowed to say yes, what the past left behind, what the future is being bent into, and what the programme can see about itself.

The Five Complexity Traps

1. The Coupling Trap, the work is divided against the grain of change

This is the one strangling the manufacturing programme above. It shows up in two symptoms that are usually treated as separate problems: coordination overhead (people spend more time synchronising than doing) and dependency chains (nothing can move until something else moves first, and the critical path becomes a critical web).

They are the same disease. Both occur when boundaries between teams, workstreams or delivery stages have been drawn across things that change together. Conway’s observation that systems mirror the communication structures that build them runs in reverse here: draw your workstream boundaries badly and you will spend the programme paying a coordination tax to reassemble what you split.

The escape is to redraw the boundaries, not to coordinate better across them. Concretely:

• Take the last twenty significant decisions the programme made. For each, record which workstreams had to be involved before it could be settled. This takes an afternoon and requires no new tooling.

• Count the crossings per boundary. A boundary that is crossed by most decisions is not a boundary; it is a seam running through the middle of a single piece of work.

• Merge across the highest-crossing seams into one team, one owner, one backlog. If two workstreams cannot decide without a joint forum, they are one workstream with a bad boundary, and merging them eliminates the forum rather than improving it.

• For what genuinely must stay separate, sequence so that each stage can complete and deliver value before the next depends on it, accepting some duplicated effort as the price. Slack in the schedule is not waste; it is the shock absorber that stops one delay becoming ten.

The instinct to change the whole estate at once, process, data, platform, integration and org design in a single synchronised push, is usually justified on efficiency grounds. It is the single most reliable way to build a critical web.

2. The Permission Trap, too many people can say no

Formal approval gates and informal veto points look like different problems and are managed by different people, but they are one mechanism: someone must say yes before the work can move. Governance boards, review ceremonies, sign-offs, and the accumulating stakeholders who each acquire an opinion and a veto, all of them add latency to the same path.

Governance that is never pruned grows monotonically. Each gate is added in response to a past failure and none is ever removed, until a programme spends more energy asking permission than making progress. Meanwhile, as a transformation grows visible it accumulates stakeholders, and past a threshold it starts optimising for internal consensus rather than for outcomes. Consensus is not a governance model; it is the absence of one.

The escape is to audit permission as a cost and delegate it downward. Concretely:

• List every forum, board and sign-off. For each, write down three things: what decisions it actually owns, its cadence, and the last time it rejected something. A gate that has never rejected anything is not a control, it is a queue.

• Set a threshold. Route routine decisions below a defined cost or risk line to a single named individual inside the delivery team, and reserve the forum for what sits above it. Most programmes discover that the large majority of decisions are routine.

• Publish decision rights explicitly, in advance: for each decision class, who decides, who is consulted, and who is informed. The value is not the document; it is that writing it forces the argument about authority to happen once, in the open, rather than continuously and by ambush.

• Put an expiry date on every new forum. A gate that must justify its renewal is a gate someone will eventually let lapse.

I have never once seen a transformation suffer from too little governance. I have seen many suffocate under too much.

3. The Data Trap, the estate is dirtier than the plan assumes

Transformations routinely underestimate the complexity hiding inside their own data: undocumented business rules, special cases encoded in spreadsheets, fields whose meaning drifted years ago and are now maintained by one person in finance who is retiring in March.

The trap is not the mess itself. It is discovering the mess late, after the plan has hardened around an assumption of cleanliness and the budget has been committed.

The escape is to go looking for it before it ambushes you. Concretely:

• Profile the production data, not the schema. Schemas describe intent; data describes what actually happened. Run distributions on every field that will be migrated and look at the tails, the nulls, the outliers, the sentinel values someone used because there was no proper field for it.

• Find the shadow systems. Ask each operational team which spreadsheets they maintain and why. The answers map the business rules that never made it into the platform, and they are the ones that will break the migration.

• Interview the exception handlers, not the process owners. Process owners describe the designed process; the people who handle exceptions know the real one.

• Price remediation as its own budget line, established before design freezes. Data cleanup funded out of the change budget competes with functionality and always loses.

Do this in the first eight weeks or you will do it in the last eight, at four times the cost.

4. The Customisation Trap, the standard platform becomes a bespoke one

This is the slow bending of a standard platform to match every existing quirk of the organisation, until the off-the-shelf system is a bespoke one that must be maintained forever and cannot be upgraded. Each individual customisation is justified by a real process need. The aggregate re-creates the complexity the platform was bought to eliminate.

Note that this trap and the Data Trap are mirror images: one is complexity inherited from the past, the other is complexity being manufactured for the future. They need opposite disciplines, curiosity about the first, resistance to the second.

The escape is a standing presumption in favour of the vanilla process. Concretely:

• Require every customisation request to name a lifetime owner: the person or function accountable for maintaining and re-testing it at every upgrade for as long as the platform lives. Requests frequently evaporate at this step.

• Force the request to state what the process difference is worth, in cost avoided or revenue enabled, not what it is. “This is how we do it” is a description, not a justification.

• Track the customisation count as a headline programme metric with an agreed ceiling. Once the ceiling is a number on the front page, the trade-off becomes visible to the people making it.

• Time-box the exception. Approve customisations with a review date at which the default is removal unless someone re-argues for it.

The question is never “can we configure this?” It is “is this difference worth carrying forever?”

5. The Measurement Trap, the programme cannot see its own complexity

This is the most insidious, because it disguises the other four. It occurs when a programme measures activity, tasks closed, workshops held, documents produced, RAID entries logged, rather than outcomes, so a transformation drowning in complexity reports itself as busy and therefore healthy. The status pack that propped open the fire door was a monument to this trap.

The escape is to measure the things complexity actually degrades. Three signals, none of which can be improved by working harder, because effort is precisely what they hold constant:

• Decision latency, time from a question being raised to an answer being given.

• Change lead time, time from request to live. This one is borrowed directly from the DORA research on software delivery performance, where it has been validated at scale; it transfers to transformation programmes with no modification.

• Rework rate, proportion of delivered work that has to be redone.

Decision latency is the least standard of the three and the one people most often ask how to instrument, so specifically:

Keep a single decision register. Every request for a decision is logged with the date raised, the named owner, and the date an answer was given. Report the 90th percentile, not the mean, the mean is dominated by the trivial decisions and hides exactly the ones that are hurting you. Two things will try to defeat this. The first is people stopping logging, which you solve by making the register the only route to an answer: an unlogged question does not get one. The second is gaming through pre-approval, where a team makes latency look good by waving through decisions that deserved scrutiny. That is why the three metrics are reported together, pre-approved bad decisions surface as rework two months later, so latency and rework rate check each other. Neither number means much alone.

Making Subtraction Politically Survivable

Every escape above takes something away from someone: a forum they chaired, a sign-off that signalled their importance, a customisation their department fought for. This is the part most frameworks skip, and it is where most of them die. Organisations are far better at addition than subtraction. Three things help:

Do it at a natural boundary. Replans, phase gates, budget cycles and partner changes are moments when structural change is expected. Proposing a merge of four workstreams mid-phase reads as a criticism of four owners; proposing it as part of a replan reads as planning.

Give displaced owners something to own. The person whose forum you delete needs a role in what replaces it, ideally a more consequential one, the delegated decision authority, the named owner of the merged backlog. Complexity removal fails far more often on dignity than on logic.

Let the numbers make the argument. “Your board is a bottleneck” is a personal accusation. “Configuration decisions have a p90 latency of twenty-eight days and eighty per cent of them fall below the risk threshold” is an observation about a system. The metrics from Trap 5 are not just diagnostics; they are the political instrument that makes subtraction discussable.

What Actually Changed at the Manufacturing Group

We did not add anything. That was the first and hardest decision, because every instinct in the room was to install a new control.

We spent two weeks mapping the actual dependency graph, which decisions touched which workstreams, and which forums had authority over what, and the map made the Coupling and Permission traps impossible to ignore. There were eleven standing forums. Four existed only to reconcile the outputs of the other seven.

We collapsed the four workstreams that were colliding most often into a single team with a single owner and a single backlog, which eliminated the reconciliation forums entirely because there was no longer a boundary to negotiate across. We took the monthly configuration-governance board and gave its routine decisions to a named individual in the delivery team, reserving the board for changes above a defined cost and risk threshold, turning a twenty-eight-day wait into a same-day answer for roughly four in five requests. And we replaced the front page of the status pack with three numbers: decision latency, change lead time, open rework. The first fortnight those numbers were embarrassing, which was the point. They were the first honest signal the programme had produced in a year.

Within two months the programme was visibly moving again, not because anyone worked harder, but because friction had been removed from the paths that mattered.

The standardisation discipline did not work, at least not immediately. The organisation had committed to a raft of customisations before I arrived, and unwinding a decision is far more expensive than not making it. We stopped the bleeding on new customisations and had to live with those already in flight. That is the honest version: some traps you escape, and some you have merely stopped digging deeper into.

Where This Framework Breaks Down

A framework that claims to explain everything explains nothing, so the limits matter.

Complexity reduction has a floor. Some transformations are genuinely, irreducibly complex, a core banking migration, a safety-critical systems replacement, and past a point, stripping out coordination or governance does not simplify the work; it removes controls that were legitimately holding a dangerous thing together. Distinguishing accidental from essential complexity, in Brooks’s terms, is a judgement this framework informs but cannot make for you. Apply the escapes indiscriminately and you will eventually decouple something that needed to be coupled, or delete the one gate standing between you and a regulatory breach. The audit questions in Trap 2 are designed to surface this: a forum that regularly rejects things is doing work.

The political fixes are not reliable. The three moves above improve the odds; they do not guarantee outcomes. In more than one programme the diagnosis was correct and the recommendation still failed, because the person who owned the redundant governance forum also owned the budget. Naming a trap does not neutralise the interests that built it.

The metrics can become the disease. Goodhart’s law applies here as everywhere: a measure that becomes a target stops being a good measure. Pairing latency with rework raises the cost of gaming but does not eliminate it. These three numbers are a diagnostic instrument, not a steering wheel, and the moment a programme is managed to them rather than informed by them, they have joined the Measurement Trap they were meant to expose.

Five is a working taxonomy, not a natural law. I have stopped finding categories that do not reduce to these five, but the value is not in the number. It is that a trap with a name can be governed, and one without a name feels like the weather.

The Deeper Pattern

Underneath all five: complexity is not something that happens to a transformation. It is something a transformation does to itself, one locally sensible decision at a time, in the sincere pursuit of control.

Nobody sets out to build a programme that strangles itself. They set out to manage risk, and they manage it the only way most organisations know how, by adding structure. Past a certain density, the structure built to hold the risk becomes the risk.

The organisations that transform well are not the ones with the most sophisticated governance. They are the ones with the discipline to treat every unit of complexity as a liability that must continually justify its existence, to ask of every forum, gate, customisation and dependency not “is this useful?” but “is this useful enough to be worth what it costs us in speed?”

Most complexity fails that test. Adding it was never the hard part.

The CTO wanted to build. His argument was reasonable on its face , the workflow touched proprietary data, the routing logic was specific to their operation, and he did not want to hand a core customer-facing capability to a vendor who could raise prices or disappear. The Head of Customer Operations wanted to buy. Her argument was equally reasonable , she had a queue that was growing faster than her headcount, and every month spent building was a month the problem got worse. Both of them were right. That was precisely the problem. The meeting kept circling because the two of them were optimising for different things and neither had a shared way to make the trade-off explicit. What should have been a decision had become a standoff.

I have now watched this exact standoff play out enough times, across enough organisations, that I am confident it is not a quirk of personalities. It is structural. The build-versus-buy question for AI agents feels like a technology decision, so it gets handed to technologists, who answer it with technology criteria. But it is not primarily a technology decision. It is a decision about where an organisation wants to hold risk, where it wants to hold control, and how much it is willing to pay , in money and in time , for each. When you frame it that way, the standoff dissolves, because you can finally see that the CTO and the Head of Customer Operations were not disagreeing about facts. They were disagreeing about which risks mattered more, and no one had ever asked them to say so out loud.

Why the Question Feels Harder Than It Is

The reason build-versus-buy has become genuinely difficult with AI agents , harder than it ever was with, say, a CRM or an accounting package , is that the market has collapsed the middle ground that used to make the choice clear. With traditional enterprise software, “build” meant writing an application from scratch and “buy” meant licensing a finished product, and the gap between those two was so vast that most decisions were obvious. AI agents live in a different landscape. You can now assemble a capable agent from foundation models you rent by the token, orchestration frameworks you install for free, and vector stores you spin up in an afternoon. “Build” no longer means building from nothing. And “buy” no longer means buying something finished, because most agent platforms still require you to configure prompts, connect data sources, define tools, and tune behaviour , which is to say, they require you to build inside their walls.

This is the first thing I try to get leadership teams to see clearly, because it reframes everything that follows. The real spectrum is not build versus buy. It is a question of how much of the stack you own and how much you rent, and at which layers. An organisation that “buys” an agent platform but writes all its own prompts, tools, and evaluation logic has, in truth, built most of what matters and bought a runtime. An organisation that “builds” on an open-source framework but leans entirely on a hosted foundation model has bought the single most expensive and most strategically consequential component. The vocabulary of build-versus-buy hides these distinctions, and hidden distinctions are where bad decisions breed.

Here I want to draw a line between two things that get conflated constantly in these discussions: control and ownership. They are not the same. Ownership is about who holds the asset , whose code it is, whose infrastructure it runs on, whose intellectual property the configuration represents. Control is about who can change the agent’s behaviour, how quickly, and without whose permission. You can own something and have little practical control over it, as anyone who has inherited an undocumented internal system knows. And you can control something you do not own, as anyone running a well-configured SaaS platform with a good API knows. The logistics company’s CTO was arguing about ownership. His counterpart was arguing about control , specifically, her ability to change the agent’s behaviour the day a shipping partner changed its status codes. Until you separate these two ideas, the conversation is doomed to talk past itself, because the words people are using do not mean the same thing to each of them.

The second confusion worth naming is between cost and time-to-value. Building almost always looks cheaper on a spreadsheet, because you are only counting the marginal cost of engineering time you have already paid for. What the spreadsheet does not count is the opportunity cost of the queue that keeps growing while you build. In the logistics case, the buy option was roughly three times the annual cost of the build option on paper , and the build option was, in reality, far more expensive, because it deferred value by two quarters during which the ticket backlog would have grown by an amount that dwarfed the licence fee. Cost and time-to-value are different axes, and treating them as one number is how organisations end up building things that were cheap to build and ruinously expensive to have waited for.

The Four-Lens Framework

What I use to break these decisions open , both when I am advising a leadership team and when I am designing an AI operating model from scratch , is a framework I call the Four-Lens Framework for Agent Sourcing. The idea is simple: a build-versus-buy decision about an AI agent should be examined through four independent lenses, each of which answers a different question, and the decision should only be made once all four have been looked through separately. The failure mode I described in that steering meeting comes almost entirely from people looking through one lens each and assuming they are seeing the whole picture.

The first lens is Strategic Proximity. The question here is: how close is this agent to the thing your organisation actually competes on? Not how important it is , importance is a distraction, because everything feels important. The question is differentiation. A shipment-status agent, however valuable, does not differentiate a logistics company from its competitors; every logistics company answers those queries. A pricing-optimisation agent that encodes a decade of hard-won margin intelligence is a different matter entirely. The closer an agent sits to your source of competitive advantage, the stronger the case for building, because you do not want your differentiation living inside a product your competitors can also license. The further it sits from that core, the more comfortable you should be buying, because you gain nothing by owning a commodity capability except the burden of maintaining it.

The second lens is Change Velocity. How often will this agent’s behaviour need to change, and who needs to be able to change it? Some agents operate in stable domains where the logic barely shifts from one year to the next. Others live in environments that churn constantly , regulatory regimes that update, partner integrations that break, product catalogues that turn over monthly. The higher the change velocity, the more it matters that control sits with the people closest to the change, and this cuts in a direction that surprises people: high change velocity often argues for building, because a good internal build puts the tuning controls in your own hands, whereas a bought platform can make you wait for a vendor’s release cycle or, worse, a professional-services engagement to change behaviour you need to change tomorrow. But it can also argue for buying, if the vendor’s platform is specifically designed for fast self-service configuration. The lens does not give you the answer; it forces you to ask whether your control model matches your change model.

The third lens is Capability Distance. This is an honest assessment of the gap between what building well requires and what your organisation can actually do , not aspirationally, but today. Building a production AI agent is not the same as building the demo that impressed everyone in the sprint review. It requires evaluation harnesses, monitoring, fallback design, prompt versioning, data pipelines, and the operational discipline to keep all of it running when the underlying model changes underneath you. I have seen more agent builds fail on capability distance than on any other lens. An organisation looks at a working prototype, concludes that building is easy, and discovers eighteen months later that it has built a fragile artefact no one knows how to maintain. The larger the capability distance, the stronger the case for buying , or, more precisely, for buying the parts you cannot yet build and building only where you have genuine, demonstrated strength.

The fourth lens is Exit Cost, and it is the one most often skipped, because it asks an unglamorous question at the moment of greatest enthusiasm: if this goes wrong, or if something better comes along, how hard is it to get out? Vendor lock-in with AI agents is subtler than with traditional software, because the lock-in is not only in the data and the integrations but in the accumulated configuration , the prompts, the tuning, the institutional knowledge encoded in a specific platform’s idioms. An agent you have spent a year tuning inside a proprietary platform is expensive to leave even if the licence itself is cheap to cancel. Building does not eliminate exit cost , a bespoke system nobody understands is its own kind of trap , but it changes its character. The discipline the Exit Cost lens imposes is to make the exit path explicit before you commit, so that you are choosing lock-in knowingly rather than discovering it later.

The framework’s real value is not in the four lenses individually , most experienced leaders could name similar considerations if pressed. Its value is that it separates them, and insists they be examined one at a time. The standoff in that steering meeting happened because Strategic Proximity, Change Velocity, and Exit Cost had all been mashed into a single argument about whether to “trust a vendor.” Pulled apart, the arguments stopped competing and started composing.

What Actually Happened

We took the logistics company through the four lenses in a single ninety-minute session, and the picture that emerged was not the one either protagonist had been arguing for. On Strategic Proximity, the shipment-status agent scored low , it was valuable but not differentiating, which weakened the CTO’s build case considerably. On Change Velocity, it scored high, because shipping partners changed status codes and SLAs constantly, which was exactly the Head of Operations’ fear. On Capability Distance, the honest answer was uncomfortable: they had two capable engineers who had built the prototype, but no evaluation harness, no monitoring, and no one who had ever run an agent in production. The distance was large. On Exit Cost, the buy options varied enormously , one vendor’s platform was a walled garden, another exposed everything through open standards.

The decision that fell out of this was a hybrid that neither party had proposed. They bought a platform , but specifically the one that scored well on Exit Cost, exposing its configuration through open, portable formats , and they used it to close the growing queue immediately, satisfying the time-to-value pressure that was genuinely urgent. In parallel, they used the six months of running that bought platform to close their capability distance deliberately: the two engineers built the evaluation harness and monitoring against a real production workload rather than a hypothetical one. The plan, revisited quarterly, was that if the pricing-optimisation agent , which scored high on Strategic Proximity , ever became a priority, they would now have the operational muscle to build it, having practised on something lower-stakes.

What worked was the sequencing. By buying first, they stopped the bleeding and bought themselves the time to build capability rather than pretending they already had it. What did not work, at least not smoothly, was the internal messaging: the CTO initially read “buy” as a verdict on his team’s ability, and it took a deliberate conversation to reframe it as a staged path toward building the things that actually mattered. The framework had resolved the technical decision cleanly; it had not, on its own, resolved the human one. That took a separate effort.

Where This Framework Breaks Down

I want to be honest about the limits, because a framework sold as universal is a framework that will eventually embarrass you. The Four-Lens Framework assumes you have enough clarity about your own strategy to score Strategic Proximity meaningfully, and many organisations do not. If a leadership team cannot say what it competes on, the first lens produces noise, and the whole exercise tilts toward the more measurable lenses , Capability Distance and Exit Cost , which quietly biases every decision toward buying. That bias is not always wrong, but it should be recognised as an artefact of strategic vagueness rather than a genuine conclusion.

The framework is also weakest in fast-moving foundational technology, where the ground shifts under all four lenses simultaneously. An Exit Cost assessment made against today’s agent platforms may be obsolete in a year, because the entire category is immature and consolidating. I have watched organisations make a careful, defensible build decision that was correct on the day and wrong within twelve months, simply because a bought option that did not exist at decision time arrived and made their bespoke work redundant. The lenses discipline the decision; they cannot see the future. This argues strongly for revisiting agent-sourcing decisions on a deliberate cadence rather than treating them as permanent, and for weighting the Exit Cost lens more heavily in immature categories precisely because you expect to change your mind.

The most common failure mode in adoption is subtler than getting the answer wrong. It is using the framework to ratify a decision that has already been made emotionally , the CTO who wants to build and scores the lenses to justify it, the operations leader who wants to buy and does the same. The framework only works if the scoring is done honestly and, ideally, by people who do not have a stake in a particular outcome. When it becomes a theatre of justification, it produces worse decisions than a coin toss, because it dresses a predetermined conclusion in the costume of rigour. If you cannot get an honest scoring, you are better served by naming the political reality directly than by pretending the framework has spoken.

The Real Decision Underneath the Decision

The thing I have come to believe, after watching a great many of these choices play out over the years that follow them, is that build-versus-buy for AI agents is rarely the decision it appears to be. It appears to be a choice between two options. It is almost always a choice about sequencing and capability , about what an organisation should be good at building itself, eventually, and what it should be content to rent forever. The organisations that handle this well are not the ones that always build or always buy. They are the ones that treat each agent as a deliberate bet on where to invest their own competence, buying the commodity capabilities without apology and building, patiently, only where owning the capability compounds into advantage.

The question worth carrying out of any steering meeting like the one I sat in on is therefore not “build or buy?” It is: if we build this, is it because we will be meaningfully better for having built it , or merely because we could? The word “could” has bankrupted more engineering roadmaps than any vendor ever has. A senior technology leader’s job is not to build everything that is buildable. It is to know, precisely and honestly, the difference between the capabilities worth owning and the ones worth renting , and to have the discipline to rent the rest.

Nine months later the same company was missing on all three. Not by a little. The first priority a shift toward a subscription revenue model had produced a pilot with fourteen customers and no plan to scale it. The second, a consolidation of the product portfolio, had quietly stalled because no single executive believed it was theirs to drive. The third had been reinterpreted so many times on its way down the organisation that the people executing it were working toward a goal that bore only a passing resemblance to what the board had approved. When I interviewed the head of one of the affected business units and asked what the company’s top priority was, she gave me a confident, articulate answer. It was wrong. Not vague wrong. She was executing diligently against a version of the strategy that had mutated three layers above her.

This is the part that should worry every board and executive team, because nothing in that story involved incompetence or bad faith. The strategy was sound. The people were capable and committed. The communication had, by every conventional measure, happened. The CEO could point to the all-hands, the emails, the OKR tool where the priorities were dutifully logged. And yet the strategic intent that existed with total clarity in the boardroom had, by the time it reached the people whose daily decisions would actually determine the outcome, degraded into something unrecognisable. This is not a communication problem, and treating it as one is precisely why it keeps happening. What I was watching was a failure of the accountability cascade the mechanism by which strategic intent at the top is meant to convert, layer by layer, into individual ownership at the bottom. In my experience across more than 1,200 projects, this is the single most under-diagnosed reason that good strategies fail to execute.

The Difference Between Communication and Cascade

The instinct, when strategy fails to land, is to communicate harder. More town halls, clearer decks, a snappier framing of the priorities. This almost never works, because it misdiagnoses the failure. Communication moves information. A cascade moves accountability and these are structurally different things.

When you communicate a strategy, you are transferring understanding. The recipient now knows what the priority is. But knowing a priority and owning an outcome are separated by a gap that no amount of clarity can close on its own. The head of the business unit in my opening story understood the strategy perfectly well at the moment it was communicated to her. What she did not have was a translated, owned version of it: a specific outcome she was personally accountable for, expressed in the terms of her own function, with the authority and resources to pursue it and a consequence attached to whether it happened. Communication ended at understanding. The cascade never completed.

Here is the pattern I have learned to look for, because it is remarkably consistent. Strategic intent degrades not through a single dramatic failure but through a series of small, reasonable-looking translations. At the board level, the priority is “shift to a subscription model.” The executive who owns it translates it into “grow recurring revenue to 40 per cent of the mix.” Sensible. Her direct reports translate that into “launch three subscription products this year.” Also sensible. Their teams translate that into “ship the subscription billing feature by Q3.” Each translation is locally rational. But somewhere in that chain, the strategic intent change how we make money, and therefore how we relate to customers has quietly become a feature-delivery task. The people at the bottom are now accountable for shipping a billing system, not for changing the revenue model. They can succeed completely at their objective while the strategy fails entirely.

This is what I call translation drift, and it is the mechanism through which most cascades fail. It is important to distinguish it from two things it resembles but is not. It is not misalignment, in the usual sense, because at every individual handoff the two parties are aligned. And it is not a lack of accountability everyone in the chain is accountable for something, often quite rigorously. The problem is that accountability for the *right thing* is not what got passed down. Each layer took ownership of its local translation, and the sum of all those locally owned translations did not reconstitute the original strategic intent. The cascade preserved the appearance of ownership while losing its substance.

The Cascade-Mapping Framework

What I use to diagnose and repair this, both in reviews like the one above and when designing delivery structures from the outset, is a cascade map built on four tests applied at every layer of translation. The map treats each handoff board to executive, executive to function head, function head to team, team to individual as a formal transfer that either succeeds or leaks. The four tests are what determine which.

The first is the Translation Test. At each layer, can the person receiving the objective restate it in a way that still contains the strategic *why*, not just the local *what*? This is not a comprehension check; it is a fidelity check. When I ask a team lead what they are working toward and they say “shipping the billing feature,” the cascade has leaked, because the why has been stripped out. When they say “we are shipping the billing feature because it is the enabling step in moving the company to recurring revenue, and if it does not drive adoption it has not done its job,” the translation has held. The test is whether the strategic intent survives the handoff, not whether the task is understood. Most organisations never test for this, because their OKR and objective-setting tools record the local what and have no field for the inherited why.

The second is the Ownership Test. For every strategic priority, is there exactly one named individual at each layer who owns it not a committee, not a function, not “the leadership team”? This sounds obvious and is almost never true in practice. In the portfolio-consolidation failure from my opening story, the reason nothing moved was that ownership was diffuse: three executives each felt partly responsible and therefore none felt decisively accountable. Diffuse ownership is functionally identical to no ownership. The Ownership Test forces a single name against each priority at each level, and it exposes the layers where a priority has been “assigned to the team” which is the polite organisational phrase for orphaned.

The third is the Authority Test, and it is the one most often missed. Accountability without matching authority is not accountability; it is a setup for blame. At each layer, does the owner actually control the decisions and resources required to deliver the outcome they have been made accountable for? I have repeatedly seen executives hold a function head accountable for a cross-functional outcome while withholding the authority to direct the other functions involved. When that outcome fails as it inevitably does the organisation records it as an accountability failure by an individual, when it was in fact an authority failure by design. The Authority Test asks, bluntly, at every layer: can this person actually cause the thing they are accountable for to happen? If the honest answer is no, the cascade is broken at that layer regardless of how clear the objective is. This connects directly to the logic of the Decision-Right Framework you cannot cascade accountability faster than you cascade the authority to act on it.

The fourth is the Consequence Test. Is there a real, observable difference in what happens to the owner depending on whether the outcome is delivered? Consequence does not mean punishment; the most powerful consequences in mature organisations are reputational and developmental rather than punitive. But if delivering the strategic priority and quietly not delivering it produce identical outcomes for the individual, then the priority is not actually being cascaded it is being suggested. The Consequence Test is uncomfortable because it usually reveals that the organisation’s real accountability structure, the one encoded in promotions and standing and who gets the interesting work, is decoupled from its stated strategic priorities. People are extraordinarily good at reading which one is real.

Applied together, these four tests turn the abstract idea of “cascading strategy” into something you can actually audit. You take a single strategic priority, trace it down through every layer of the organisation, and mark at each handoff whether the translation held, whether ownership was singular, whether authority matched accountability, and whether consequence was real. The layer where the first test fails is where your strategy is dying and it is almost never the layer people assume.

What Changed in Practice

When I mapped the subscription-model priority for the company in my opening story, the results were clarifying in a way that no amount of further communication could have been. The Translation Test held for the first two layers and failed sharply at the third: below the function-head level, nobody could articulate the revenue-model why, only the feature-delivery what. The Ownership Test failed at the executive layer for the portfolio priority three names, no single owner. The Authority Test failed for the subscription priority, because the executive accountable for the revenue mix did not control the pricing decisions that sat with a separate commercial function. And the Consequence Test failed almost everywhere, because the company’s promotion cycle rewarded shipping features on time, which is exactly the local translation that had displaced the strategic intent.

We did not fix this by relaunching the strategy. We fixed it one broken layer at a time. For the subscription priority, we reassigned authority so that the accountable executive genuinely controlled pricing, packaging, and go-to-market for the recurring line a change that required the CEO to override a functional boundary that had existed for years, and which was resisted precisely because it was consequential. For the portfolio priority, we collapsed three diffuse owners into one, and the executive who took it did so knowing it would now define her quarter. We rewrote the team-level objectives to carry the inherited why explicitly, so that “ship billing by Q3” became “drive subscription adoption, of which billing is the enabling step, measured by activated recurring accounts.” And we changed what the quarterly review actually examined not activity, but whether the strategic why had survived to the layer doing the work.

What worked was the diagnostic discipline of tracing a single priority all the way down before touching anything. What did not work, at first, was the authority reallocation: the commercial function experienced it as a loss of territory, and it took a direct and slightly uncomfortable intervention from the CEO to hold the line. The lesson there is that a cascade cannot be repaired by the layer where it broke it almost always requires action from the layer above, which is why boards that delegate cascade repair to the middle of the organisation watch it fail again.

Where the Cascade Model Falls Short

I want to be honest about the limits of this, because a framework presented without its failure modes is a sales pitch, not a tool. The cascade map is powerful for a specific class of problem: strategic priorities that must convert into individual ownership through several organisational layers. It is overkill for a flat organisation of thirty people where the founder and the person executing are one conversation apart. In that setting, formalising a four-test cascade would introduce exactly the bureaucratic drag it is meant to prevent.

The more serious limitation is that the model assumes the strategy is worth cascading. A perfectly executed cascade of a bad strategy simply delivers failure faster and with more conviction. The framework tests fidelity of transmission, not quality of intent, and it is entirely possible to pass all four tests at every layer while marching the whole organisation off a cliff with excellent alignment. I have seen this too, and it is more dangerous than translation drift, because drift at least tends to blunt bad strategies as much as good ones.

There is also a real failure mode in adoption: organisations that embrace the Consequence Test as licence for a blame culture. The test asks whether outcomes differ, not whether individuals should be punished. When leaders hear “consequence” and reach for punishment, the predictable result is that people stop taking accountability for anything ambiguous or risky which is to say, for anything strategically interesting. The cascade then optimises for safe, deliverable, locally rational objectives, which is precisely the disease it was meant to cure. Consequence must attach to ownership honestly held, not to outcomes that were never within the owner’s authority to control which is why the Authority Test must always be applied before the Consequence Test, never after.

The Real Test of a Strategy

The uncomfortable truth that this framework keeps surfacing is that most organisations do not have a strategy problem or a talent problem. They have a transmission problem, and it hides in plain sight because every individual link in the chain looks sound. The board is clear. The executives are aligned. The teams are diligent. And the strategy still fails, because clarity, alignment, and diligence at each layer do not add up to fidelity across all of them. Accountability is not a substance that flows downhill by gravity once you have communicated it well enough. It is transferred, deliberately, one tested handoff at a time or it is not transferred at all.

The most senior thing a board can do is stop asking whether the strategy has been communicated and start asking whether it has survived. Trace one priority to the individual whose daily decisions determine its fate, and listen to how they describe what they are doing. If the why is still intact when it reaches the bottom, you have a cascade. If only the what remains, you have an echo and an echo has never delivered a strategy in the history of organisations.

A little over a year ago I was asked to sit in on a quarterly review at a mid-sized financial services firm that had, by any reasonable measure, invested seriously in artificial intelligence. They had a head of AI. They had a budget line that would have made a Series B startup blush. They had, spread across the business, no fewer than fourteen distinct AI initiatives - a document-summarisation tool in legal, a customer-triage classifier in support, a forecasting model in finance, a couple of retrieval-augmented chat assistants stitched together by whichever teams had the appetite to build them. On paper, this was an organisation that had embraced AI. In the room, the mood told a different story.

The head of AI presented a slide with all fourteen initiatives arranged in a neat grid. Green ticks everywhere. Then the CFO asked a question that, in my experience, is the single most revealing question you can ask in these meetings. He did not ask whether the models worked. He asked: “Which of these could we turn off tomorrow without anyone noticing, and which ones would break something if they failed at three in the morning?” The room went quiet. Nobody could answer. Not because the people were not capable - they were some of the sharpest technologists I had worked with that year - but because the question exposed a truth the grid of green ticks had been designed, however unconsciously, to hide. They had fourteen experiments. They did not have a single AI operation.

This is the pattern I now see more often than almost any other in AI adoption, and it is worth naming precisely because it masquerades as success. The firm had confused *activity* with *maturity*. They had assumed that because they were doing a great deal with AI, they must be advanced in AI. But volume of experimentation is not the same as operational readiness, and the gap between the two is where most of the money quietly disappears. What should have worked - hiring the right people, funding the right projects, encouraging teams to build - had produced fourteen isolated proofs of concept that shared no infrastructure, no monitoring, no governance, and no honest account of what would happen when one of them failed in a way that mattered.

I have now watched enough organisations move through this journey, across financial services, logistics, professional services, and manufacturing, to be confident that the progression from AI experiment to AI operation is not random. It follows a recognisable path, with recognisable stages, each of which demands something structurally different from the one before. And the reason so many organisations stall is that they mistake motion within a stage for progress between stages.

Why Activity Is Not Maturity

The instinct, when AI adoption feels stuck, is to reach for more. More models, more use cases, more headcount, more compute. This is almost always the wrong move, and understanding why requires distinguishing two things that leaders routinely conflate: *capability* and *maturity*.

Capability is what a system can do in the right conditions. A model that summarises contracts beautifully in a demo has capability. Maturity is what a system does *reliably, observably, and safely* in the conditions your business actually operates under - at scale, under load, with real data, when the on-call engineer is asleep and the input is malformed and the downstream process has no idea the answer came from a model. These are not points on the same line. An organisation can have enormous AI capability and almost no AI maturity, which is precisely the trap the financial services firm had fallen into. Their fourteen initiatives were, individually, capable. Collectively, they were operationally immature, because not one of them had been built to be operated. They had been built to be demonstrated.

This distinction is structural, not a matter of individual competence. The people building those tools were doing exactly what the organisation rewarded them for: shipping something that worked in a review. The failure was not that they lacked skill. It was that the organisation had no shared definition of what “done” meant beyond the demo, and so every team drew the finish line at the point where the model first produced a plausible answer. The finish line for an *experiment* is a working demo. The finish line for an *operation* is a system you can depend on and be held accountable for. Nobody had ever told them to run the second race, so they all won the first one, fourteen times over, and the business was no more able to rely on AI than it had been before it started.

The second confusion worth separating is between *adoption* and *integration*. Adoption is measured in usage: how many people touch the tool, how many queries it handles. Integration is measured in dependency: how much of a real business process now runs through the system, and what breaks if it stops. High adoption with low integration is a comfortable illusion - lots of people using AI to do things they could have done another way. It feels like progress and commits you to nothing. Real maturity shows up when integration is high, because that is the point at which the organisation has actually staked something on the technology, and where the discipline of operating it becomes non-negotiable rather than optional.

The AI Operations Maturity Model

What I use, both to diagnose organisations like the one above and to design AI adoption programmes from scratch, is a five-stage model. It is not a scorecard to feel good about. It is a diagnostic that tells you honestly where you are and - more importantly - what the *next* stage specifically demands, because the mistake that kills momentum is trying to skip a stage rather than earn it.

Stage One - Ad Hoc. At this stage, AI happens to the organisation rather than being directed by it. Individual employees discover tools and use them privately; a keen engineer builds something over a weekend; a department buys a licence and experiments. There is no strategy, no governance, no shared infrastructure, and frequently no visibility - this is the stage at which shadow AI flourishes. The defining characteristic is that AI use is invisible to leadership and unaccountable to anyone. Stage One is not shameful; every organisation starts here. The danger is remaining here while telling yourself you have “adopted AI” because usage is high. The task of Stage One is not to do more AI. It is to make the AI you are already doing *visible* - to inventory it, name it, and bring it into the light.

Stage Two - Experimental. Here the organisation has decided to take AI seriously and begins funding deliberate pilots. This is where the financial services firm lived, and where a great many well-resourced companies get stuck for years. The work is real, the intent is genuine, but each initiative is an island. Pilots are built to prove a point, not to be operated. Success is defined as a working demonstration. There is no shared platform, no common monitoring, no consistent evaluation standard. The defining characteristic of Stage Two is *proliferation without consolidation* - you accumulate proofs of concept faster than you can turn any of them into something dependable. The task of Stage Two is brutally counterintuitive: stop starting new things, and start finishing the ones that matter. Maturity here means choosing which experiments deserve to become operations and letting the rest die honestly rather than lingering as zombie projects.

Stage Three - Operational. This is the threshold most organisations never cross, and crossing it is the whole game. At Stage Three, at least one AI system has been genuinely productionised: it has monitoring, it has defined ownership, it has fallback behaviour when it fails, it has an evaluation regime that catches degradation before users do, and someone is accountable for it in the way they would be accountable for any other production system. The distinction between Stage Two and Stage Three is not the sophistication of the model. It is the presence of *operational scaffolding* around it. A modest model that is properly operated is more mature than a brilliant one that is merely demonstrated. The task of Stage Three is to build, once, the platform and the disciplines - observability, evaluation, incident response, human-in-the-loop escalation - that the next system can inherit rather than reinvent.

Stage Four - Systemic. At this stage, operating AI is no longer a per-project heroic effort but an organisational capability. There is a shared platform. New AI systems are onboarded onto common infrastructure with common standards for monitoring, evaluation, and governance. The marginal cost of the next AI operation has fallen dramatically, because the scaffolding built painfully in Stage Three is now reused. Crucially, this is where governance stops being a brake and becomes an enabler - because the guardrails are built into the platform, teams can move faster *within* them rather than negotiating safety from scratch each time. The defining characteristic of Stage Four is that AI operations scale sub-linearly in effort: the tenth system costs far less to run well than the first.

Stage Five - Strategic. The final stage is not about running AI well; it is about the organisation’s strategy being shaped by what its AI operations make possible. Here, mature AI capability changes what the business chooses to do - new products, new operating models, new economics that were previously infeasible. Very few organisations are genuinely at Stage Five, and many that claim to be are flattering themselves. The honest marker is this: at Stage Five, if you removed the AI operations, the *strategy itself* would no longer be viable, not merely inconvenienced. That is a high bar, and it should be.

The value of the model is not in the labels. It is in the diagnosis. The financial services firm, for all its investment, was firmly at Stage Two - and every instinct in the room was to solve a Stage Two problem by doing more Stage Two things. The model told them, uncomfortably, that their next move was not to launch a fifteenth initiative but to productionise one.

What Actually Changed

I took the firm through this model in the review that followed, and the immediate effect was deflating in the most useful way. Fourteen green ticks became one honest sentence: *we are at Stage Two, and we have been for two years.* Nobody enjoyed hearing it, but the CFO’s original question - which of these would break something at three in the morning - suddenly had an answer. The answer was “none of them, because none of them are load-bearing, which is another way of saying none of them matter yet.”

The intervention was not glamorous. We did not start anything new for a full quarter - a moratorium that was, politically, the hardest thing to sell. Instead we picked exactly one of the fourteen: the customer-triage classifier in support, chosen because it touched a real process with measurable volume and had the clearest path to genuine dependency. Then we did the unglamorous work of Stage Three around that single system. We built monitoring that watched not just uptime but the distribution of the model’s outputs, so drift would surface before customers felt it. We defined an owner - a named person, accountable, not a committee. We designed the fallback: what happens to a ticket when the classifier is uncertain or unavailable, so that failure degraded gracefully into the existing human process rather than dropping tickets silently. And we built an evaluation set from real historical cases so we could tell, on any given week, whether the thing was getting better or quietly worse.

What worked was the focus. By refusing to spread effort across fourteen initiatives, the team built, for the first time, a piece of AI they could actually stand behind. Within two months the classifier was not a demo but a dependency - support genuinely relied on it, and when it wobbled, the monitoring caught it before the customers did. That single productionised system became the template. The observability tooling, the evaluation harness, the incident runbook - all of it was built to be inherited, which is what moved them from a one-off Stage Three win toward the shared platform of Stage Four. What did not work, at least at first, was the cultural adjustment. The engineers who had enjoyed the freedom of endless experimentation found the discipline of operations constraining, and two of them, quite reasonably, disliked it. Maturity is not universally more fun than experimentation. It is simply more valuable.

Where the Model Breaks Down

I would be misrepresenting the framework if I presented it as a ladder every organisation should climb as fast as possible. It is not. The most important caveat is that **not every organisation should reach Stage Five, or even Stage Four.** Maturity has a cost, and that cost is only justified by dependency. If AI is genuinely peripheral to your business - a convenience rather than a capability - then investing in systemic AI operations is over-engineering, and the correct place to stop may be a well-run Stage Three around a small number of systems. The model tells you where you are; it does not command you to climb. Ambition should be calibrated to how load-bearing AI actually is for your strategy, not to how the maturity curve looks in a board deck.

The second failure mode is treating the stages as a tidy linear march. In reality, a large organisation is often at different stages in different functions simultaneously - Stage Three in support, Stage One in legal - and the mistake is to average these into a single misleading number. The model is most useful applied *per capability*, not per company. Rolling it up to a single organisational grade produces exactly the kind of comfortable illusion it was designed to puncture.

The third and subtlest risk is that the model can be weaponised as a compliance exercise. I have seen organisations turn a maturity assessment into a checklist to be gamed, where teams perform the artefacts of Stage Three - a monitoring dashboard nobody reads, an “owner” who owns nothing - without the underlying reality. Scaffolding built to pass an audit is worse than no scaffolding, because it manufactures false confidence. The stages describe capabilities that must be genuinely present, not documents that must be produced. If your maturity assessment feels good to complete, you are almost certainly doing it wrong.

The Real Measure of AI Maturity

The organisations that succeed with AI are rarely the ones doing the most with it. They are the ones that have understood, earlier than their competitors, that the interesting engineering problem was never getting a model to produce a good answer in a demo. That part is now close to free. The hard, valuable, defensible work is everything that surrounds the model - the observability, the ownership, the fallback behaviour, the honest evaluation, the governance that enables rather than obstructs. This is the unfashionable infrastructure of dependability, and it is precisely what separates an organisation that *has AI* from one that can *rely on AI*.

The CFO’s question at that review has stayed with me, because it is, in the end, the only maturity assessment that matters. Not “how much AI are we doing?” but “what would break if it failed, and would we know before our customers did?” An organisation that can answer that question, system by system, has crossed the line that the maturity model is really about - the line between having experiments you are proud of and having operations you can depend on. Everything else is just green ticks on a slide, waiting for the Sunday evening phone call that tells you which of them was load-bearing all along.

This is the pattern I want to name precisely, because it’s disguised as a virtue almost everywhere it occurs: hero culture. Every tech organisation has, or has had, someone like this - the person who gets paged first because they’re the one who actually knows, who stays late without being asked because they can see the consequence of not staying, who becomes, without anyone deciding it deliberately, the organisation’s actual disaster recovery plan. The uncomfortable finding, across every version of this I’ve reviewed, is that hero culture doesn’t emerge from bad intentions. It emerges from an organisation quietly optimising for the person who solves the immediate problem fastest, at the expense of ever building the thing that would make the problem un-solvable by design. The heroism is real. The resilience it’s mistaken for is not, and the gap between the two is where the actual risk accumulates, invisibly, for years, until a Sunday evening makes it visible at the worst possible time.

Why Competence Gets Mistaken for Resilience

The confusion is understandable because, from inside the organisation, the two look identical for a long time. Incidents get resolved. Deadlines get hit, usually because someone worked the weekend to hit them. Systems that shouldn’t really still be running keep running, because someone who understands their undocumented quirks intervenes before they fail publicly. Leadership sees a track record of problems getting solved and reasonably concludes the organisation is capable - without ever separating the question of whether the organisation is capable from the question of whether one or two specific people are, and whether that distinction has ever been tested.

It gets tested exactly once, involuntarily, when the hero is unavailable - on leave, poached by a competitor, burned out and finally saying no, or simply on a flight at the wrong moment - and what the organisation discovers in that moment is the actual state of its infrastructure, its documentation, and its decision-making capacity, stripped of the one person who had been quietly compensating for all three. This is what I mean by the difference between competence and resilience: competence solves the problem in front of you; resilience means the organisation doesn’t need a specific person to solve it. Most tech organisations I review have invested heavily in the first and have no clear mechanism for building the second, because the first is visible and rewarded continuously, while the second is invisible until the day it’s tested - and by definition, you don’t get advance warning of which day that will be.

Four Patterns That Build Hero Dependency Without Anyone Deciding To

The informal escalation shortcut.
Every organisation has an official incident process - an on-call rotation, a runbook, an escalation ladder - and in organisations with hero dependency, that official process exists mostly as documentation nobody actually follows under pressure, because everyone has learned that the fastest path to resolution is routing directly to the person who actually knows, bypassing the rotation entirely. This isn’t malicious; it’s rational individual behaviour that produces a collectively catastrophic outcome, because every time someone routes around the official process to get a faster fix, the official process gets marginally weaker and the hero dependency gets marginally stronger, and nobody experiences this as a decision because it never gets made explicitly. It accumulates one shortcut at a time until the org chart says one thing and the actual dependency graph says another.

Tribal knowledge as load-bearing infrastructure.
The reconciliation job in the opening example wasn’t undocumented because anyone had decided documentation wasn’t worth doing. It was undocumented because documenting it properly would have taken the one person who understood it away from solving the next fire, and there was always a next fire, and the organisation’s incentive structure rewarded him for solving fires, not for writing the runbook that would make his own presence unnecessary. This is the structural trap: the people best positioned to eliminate a knowledge single-point-of-failure are the same people whose daily incentives push them toward using that knowledge to solve problems quickly rather than toward transferring it, and no organisation I’ve reviewed has solved this by asking people to document more in their spare time. It gets solved, when it gets solved, by making knowledge transfer an explicitly assigned and measured piece of work, not a virtuous afterthought competing with an always-full queue of urgent fixes.

Firefighting rewarded over fire prevention.
Performance review cycles, promotion narratives, and informal reputation inside engineering organisations consistently reward the visible save - the person who stayed up all night and fixed the outage - far more reliably than they reward the invisible absence of an outage that would have happened if someone hadn’t spent a quarter earlier redesigning the failure-prone system. This is a measurement problem with real behavioural consequences: if the organisation’s reward signal only fires when there’s a fire to fight, the rational response from capable people is to become excellent firefighters rather than to invest in fire prevention, because fire prevention is unrewarded, hard to attribute, and actively reduces the number of opportunities to be visibly heroic. I’ve watched organisations promote their best firefighters into leadership roles repeatedly while the engineers quietly doing preventive systems work - the unglamorous kind that means nothing breaks in the first place - got passed over for having a thinner list of dramatic saves.

Post-incident reviews that thank the hero instead of fixing the structure.
The retrospective after most fire-drill incidents follows a predictable shape: relief that it’s resolved, genuine gratitude toward whoever fixed it, a timeline of what happened, and an action item or two about monitoring. What’s consistently missing is the harder question - why did this depend on one specific person being available, and what would need to be true structurally so that the next version of this incident doesn’t depend on anyone’s specific availability at all. Gratitude toward the hero is appropriate and should be expressed. It is not, on its own, a fix, and organisations that stop at gratitude are guaranteeing a repeat performance, with the same person carrying the same disproportionate load until they can’t or won’t anymore.

What Systems-Based Resilience Actually Requires

The fix isn’t “document everything” as a slogan, because that instruction has been given to every engineering organisation at every all-hands for a decade and has produced, on its own, almost no measurable change in hero dependency. What actually shifts the pattern is a small number of structural changes that remove the informal shortcuts hero dependency runs on, rather than appealing to individual discipline to close a gap the incentive structure keeps reopening.

The escalation path needs to be the fastest path, not just the official one - which means investing in the on-call rotation and runbooks enough that routing through them is genuinely quicker than finding the one person who knows, because as long as the informal shortcut remains faster under pressure, it will keep winning regardless of what the org chart says. This is the same discipline I’ve written about in the context of execution accountability more broadly: the gap between the designed process and the process people actually use under pressure needs a visible, monitored channel, because it stays invisible until it’s expensive. (check Execution Accountability: How to Build a Culture That Delivers) for the underlying mechanism - the same principle that applies to status reporting applies directly to whether an incident process is actually being used.)

Knowledge transfer needs to be assigned, scheduled, and measured as real work competing for the same calendar space as feature delivery, not left to compete against an always-full queue of urgent fires where it will lose every time by default. Concretely, this means naming specific systems with a documented single point of knowledge failure, assigning a named second person to reach working competence within a defined window, and tracking that as a deliverable with the same seriousness as a shipped feature - because if it’s not tracked, it’s not real, regardless of how many times it gets mentioned as a priority.

Reward structures need an explicit mechanism for recognising prevention, not only response - which is genuinely harder to measure than a dramatic save, and organisations that don’t solve the measurement problem will keep defaulting to rewarding visible heroics, because visible heroics are easy to see and prevention is, by design, invisible. This is directly connected to the governance discipline that fast-growing organisations need more broadly: growth doesn’t create hero dependency on its own, but it multiplies the cost of every shortcut the organisation has been quietly taking, at exactly the pace where nobody has time to notice. (See [Scaling Without Chaos: Governance Frameworks for Fast-Growth Teams](/scaling-without-chaos-governance-fast-growth-teams) for how this compounds specifically under growth conditions.)

And post-incident reviews need a standing structural question, asked every time regardless of how quickly the incident was resolved: what specific single point of dependency - human or system - did this incident expose, and what is the committed fix with an owner and a date. Without that standing question, retrospectives will keep producing gratitude and monitoring tickets, which feel like progress and change nothing about the underlying dependency graph.

Implementation Trade-offs

None of this is free, and the trade-offs deserve honest treatment rather than being waved away as pure upside. Investing in the official escalation path and runbooks over the informal shortcut takes real engineering time away from feature delivery in the near term, and it will be tempting to defer this work indefinitely because the informal shortcut keeps working - right up until the specific person it depends on is unavailable, at which point the cost of not having done it arrives all at once and considerably larger than the cost of having done it gradually.

Making knowledge transfer an explicit, tracked deliverable creates near-term friction with the people who are best at their jobs, because the instruction is effectively asking your most capable individual contributors to spend time making themselves less uniquely necessary, which runs against both the natural pull toward being the indispensable expert and, in some cases, against a genuine (if often unconscious) instinct toward job security through irreplaceability. This needs to be handled directly and honestly in how the organisation frames career growth - the message needs to be that becoming un-necessary for a specific system is what enables the next level of scope, not a threat to it, and that only works if leadership actually follows through on giving expanded scope to people who do this well.

Rebalancing reward structures toward prevention requires genuine measurement discipline that most organisations don’t currently have - you need some way of attributing “this didn’t happen because of preventive work six months ago” that’s more rigorous than anecdote, or the rebalancing will be perceived, correctly, as unfairly favouring whoever tells the better story in a calibration meeting rather than whoever actually reduced risk.

The Strategic Reflection

Hero culture persists in tech organisations not because leaders fail to notice it, but because it works, continuously and visibly, right up until the specific day it doesn’t - and that day rarely announces itself in advance. The organisations that build genuine resilience are the ones that treat every heroic save as a diagnostic signal rather than a success story: not “great job, crisis averted,” full stop, but “great job, crisis averted - now what does it tell us about a dependency we haven’t fixed, and who owns fixing it by when.” That reframe is uncomfortable in the moment, because it takes something that feels like an unambiguous win and insists on treating it as evidence of unfinished structural work, and it will meet resistance from people who’d rather be thanked than assigned a follow-up.

If your organisation depends, right now, on a small number of specific people being available for things to keep working, the diagnostic question worth sitting with isn’t whether those people are good at their jobs. They almost certainly are - that’s usually not in question. The question is what would actually happen, in concrete operational terms, if the best of them left with four weeks’ notice tomorrow, and whether anyone has mapped that answer honestly or has simply been trusting that it won’t happen on their watch. Most organisations running on heroics can’t answer that question with any confidence. The ones that build real resilience are the ones that make answering it, uncomfortably and specifically, a standing part of how they operate - before a Sunday evening forces the answer on them.

Not who was consulted. Not who was in the room. Who, when the room disagreed, had the standing to make the call and make it stick.

Nobody could answer that with confidence, including the COO. I asked six people separately and got five different responses. The honest answer was that it depended on who escalated fastest and how much political capital they were willing to spend that week. The feature shipped. Support volume tripled. The retrospective spent four hours on the feature’s design flaws and about four minutes on the fact that the decision had never actually belonged to anyone - which was the real cause and the only one guaranteed to recur.

That scale-up isn’t unusual. It’s the median case. Most organisations past a certain size don’t have a decision-making problem in the sense people usually mean it - bad judgment, slow meetings, insufficient data. They have an authority problem: an accumulated, undocumented, largely improvised set of assumptions about who gets to decide what. Those assumptions were roughly accurate when the company was fifteen people in one room. They have quietly stopped being accurate at every size since and nobody ever sat down to rebuild them on purpose.

I want to work through why this failure is so common, why the standard tools don’t fix it and what a decision rights framework that holds up under real complexity looks like.

The diagnostic: authority doesn’t scale the way structure does

Across nearly every fast-growing organisation I work with, the same pattern holds. Org charts scale reasonably well - you can draw a bigger chart, add layers, add titles. Decision authority does not, because authority was never actually assigned in the first place. It was inherited from a founding moment when the founder held every decision by default, simply because there was no one else to hold it.

As the company grows, that default authority gets delegated piecemeal and informally, in response to whatever crisis or hire prompted the delegation. Nobody deliberately designs who should hold which category of decision at scale. A VP gets hired and absorbs “product decisions” as a vague bundle. Which product decisions? Pricing, roadmap sequencing, feature scope, architecture trade-offs? Which of those actually sit inside the bundle and which remain - unstated - with the founder or the executive team?

The bundle feels like clarity because there’s a name attached to it. It functions as ambiguity, because the boundary was never drawn.

This is the structural reason RACI matrices and org charts fail to solve the problem, even when organisations diligently fill them out. A RACI matrix answers “who is responsible, accountable, consulted, informed” for a task. But most consequential organisational conflict isn’t about who executes a task. It’s about who has the standing to resolve a disagreement about a decision - a different question, answered by a different structure.

You can have a perfectly clear RACI for “who builds the feature” and zero clarity for “who decides whether the feature should exist, given the support-cost trade-off.” That second question was never a task on anyone’s matrix. It’s a judgment call that surfaces only when two legitimate functional priorities collide - and collision points are precisely the places RACI was never designed to arbitrate. The scale-up above had a RACI for feature delivery. It had nothing for feature approval under cross-functional trade-off, which is where the expensive mistake actually occurred.

Why the standard responses fall short

Faced with visible paralysis or a costly bad call, most organisations reach for one of two fixes. Both under-deliver in predictable ways.

The first is escalation-by-default: when functions disagree, push it up a layer and eventually to the executive team or the founder. This works the first few times. Then it becomes the organisation’s real decision-making mechanism by accident. Executives who resolve enough of these escalations personally never have to build a system that resolves them without their involvement. Worse, every escalation they handle is implicit proof, to everyone watching, that the system works fine as is.

It doesn’t scale. Escalation-by-default has a hard ceiling: the number of disputes a small group of senior people can personally adjudicate per week. Organisations hit that ceiling right around the point where growth has produced more cross-functional collision points than the executive team has attention. Not coincidentally, that’s usually the stage at which I get the call - because the founder has just spent a Tuesday resolving three disputes that shouldn’t have needed them and is beginning to suspect this isn’t leadership. It’s a bottleneck wearing leadership’s clothes.

The second fix is the comprehensive governance rewrite: a project, often consultant-led, to document every decision type across the company and assign it formally. This is directionally correct and usually fails anyway. The failure has nothing to do with the quality of the analysis and everything to do with sequencing. These projects try to map decision rights for the entire organisation at once. They produce an exhaustive document six months later. By then the org has changed shape, two of the people the document assigned authority to have moved roles and the document’s main afterlife is as an artifact nobody consults - referenced occasionally in a dispute as evidence, never used as the operating system it was meant to become.

Comprehensive and current are in tension for a fast-moving organisation. Projects that optimise for comprehensive lose currency faster than they can be adopted.

Both failures share a root cause I’ve written about before in a different context: they treat decision authority as something you solve once, comprehensively, rather than as infrastructure you build incrementally at the exact points where it’s load-bearing and revisit on a cadence. (It’s the same sequencing mistake I discuss in Scaling Without Chaos - comprehensive-but-static structure loses to targeted-but-maintained structure at every stage of growth I’ve observed.)

A framework: decision rights mapped by collision point

What actually works is narrower and more disciplined than a full governance overhaul: identify the specific points where functional authority collides and resolve those points explicitly, before the collision produces a costly ad hoc decision. Four components.

1. Collision-point identification, built from real disputes, not hypothetical org design. Don’t try to map every conceivable decision. Start from the disputes that have already happened, or that senior people can name as recurring friction. The product-versus-support trade-off above is one instance of a category - “features with material downstream operational cost” - that will recur. Mapping that category matters far more than mapping every decision Product theoretically makes.

In practice, this means interviewing the leadership team with one question: where, in the last two quarters, did a decision involve genuine disagreement between two functions and how was it actually resolved? The answers cluster fast, usually into five or six recurring categories. Those categories are where the framework applies first.

2. Explicit authority per category, with a named decision-owner - not a bundle. For each category, assign a single named role. Not a committee. Not “product and support together.” One role with the explicit standing to make the final call when the functions disagree, after input has genuinely been sought from the other side.

This is the part organisations resist most, because it feels like it disempowers the function that doesn’t get the authority. The honest response to that discomfort: ambiguity was never empowering anyone. It was deferring the fight to whoever had more energy or standing in the moment - a worse allocation mechanism than a deliberately chosen owner, even one a given function occasionally disagrees with.

3. An escalation path that is genuinely rare, not a relabeled default. Some decisions will be significant or novel enough to warrant escalation above the named owner. But the framework only works if escalation stays the exception, reserved for consequences beyond what the category anticipated - not the same default-to-the-top pattern with an extra documented step in front of it.

A useful test: if the same category escalates more than roughly once a quarter, either the ownership assignment is wrong or the owner isn’t being given the standing the document says they have. Either problem needs fixing at the root, not absorbing as routine escalation volume.

4. Scheduled review, not permanent assignment. Revisit ownership on a fixed cadence - every two quarters for a fast-growing organisation. The collision-point categories themselves shift as the company scales. New ones emerge, old ones become irrelevant and the right owner at one stage of growth is not automatically the right owner at the next. A built-in expiry-and-renewal mechanism is what stops the framework calcifying into exactly the kind of static document that made the comprehensive rewrite fail.

Implementation risks and trade-offs

This framework carries real costs and leaders should weigh them honestly.

Naming a single decision-owner for a category will, correctly, feel like a loss of influence to whichever function doesn’t get the authority. That reaction needs managing directly, not smoothing over with vague language about “collaborative decision-making.” The entire point of the framework is that collaboration happens in the input stage, not in the final call. Pretending otherwise reintroduces the ambiguity the framework exists to remove.

Starting from real disputes rather than comprehensive mapping means some categories will go unaddressed until they produce their own costly collision. Leadership has to accept that the framework is deliberately incomplete at any given moment, prioritising the highest-friction categories first. This is a genuine trade-off, not a flaw to apologise for. Complete coverage delivered slowly arrives too late and too stale to be useful. Partial coverage delivered where the friction actually is compounds in value, because each resolved category removes a recurring source of ad hoc conflict.

The review cadence, skipped once under time pressure, tends to get skipped permanently. There’s rarely an obvious trigger forcing the review the way there is for the original collision. The org just gradually re-accumulates ambiguity as it changes shape - quietly, until a new dispute makes the drift visible, by which point the fix costs more than the review would have.

And there’s a habit underneath all of this worth naming directly. Once decision rights are assigned, the temptation is to treat the owner’s call as unchallengeable rather than accountable. The framework is meant to produce clear authority with genuine input from affected functions - not authority that stops listening once it’s been formally granted. Confusing the two turns a governance improvement into a new source of the same resentment the ambiguity originally produced, just relocated to a different name on the document.

The strategic reflection

The organisations that scale without descending into paralysis or chaos are rarely the ones with the most sophisticated org charts. They’re the ones that did the less glamorous work of deciding, deliberately and in writing, who actually makes the call at the specific points where functional priorities collide - and then had the discipline to revisit that assignment as the organisation changed shape.

The SaaS scale-up above didn’t need a better feature-review process. It needed one person with the standing to say “this ships” or “this doesn’t,” known in advance by everyone in the room, so the decision didn’t have to be re-litigated from first principles, under time pressure, by whoever showed up loudest that week.

If your organisation resolves cross-functional disagreements primarily through escalation, seniority, or whoever argues longest, the question worth asking isn’t whether you need better people in the room. It’s whether you’ve ever actually assigned authority for the categories of decision that keep colliding - or whether, like most organisations at your stage, you’re still relying on an informal allocation system that was never built to survive the size you’ve already grown past.

Gustavo De Felice is a senior digital project leader and systems architect with over 1,200 managed projects across technology, logistics and digital transformation. He writes on execution governance, performance accountability and the structural design of teams that deliver under complexity.

What I found, over the following few weeks, was not a company in crisis. It was something more subtle and more common: an operating structure designed - quite reasonably - for forty people, never redesigned as headcount multiplied by five. Nobody had made a bad decision. Nobody had been negligent. The company had just kept running the same decision-making architecture at a scale it was never built for the cracks that produces don’t look like crisis. They look like drag.

Specific symptoms, once I started asking the right people the right questions: product decisions that used to take a same-day Slack thread between the CEO and the head of engineering now required four separate meetings across three time zones, because the two people who used to just decide were no longer close enough to the work to decide alone, but nobody had explicitly given that authority to anyone else. Marketing had launched a campaign that finance discovered only after the invoices arrived, because there was no defined threshold above which spend needed visibility before commitment. Two regional teams had built, independently and in parallel, functionally identical internal tools, because neither had any mechanism for knowing what the other was working on. And underneath all of it, the company’s most capable senior people - the ones who had joined at twenty employees and scaled personal responsibility along with the company - were quietly burning out. Not from overwork, exactly, but from being the accidental, unacknowledged decision bottlenecks for a company that had outgrown their bandwidth six months earlier.

This is the pattern I want to work through in this piece the governance framework for fast-growth teams I now use to fix it - because the pattern is close to universal because the standard responses to it - hire a COO, adopt a framework, restructure the org chart - routinely miss what is actually wrong.

The Diagnostic: Growth Doesn’t Break Governance, It Reveals That You Never Built Any

The uncomfortable truth I have to deliver to founders in this situation, almost every time, is that their forty-person operating model was never really a governance structure. It was a set of informal habits that worked because of proximity. At forty people, in one or two locations, everyone who mattered could see everyone else’s work. The CEO could sit in on most important conversations. Decisions didn’t need explicit decision rights because trust and visibility substituted for structure. This is not a design flaw at that stage - it is, in fact, the correct way to run a company that small. Formalising decision rights at forty people would likely have been premature bureaucracy, adding friction the company didn’t yet need.

The problem is that proximity-based governance has a hard ceiling organisations blow past it without noticing, because the transition from “small enough that trust and visibility work” to “too large for that” doesn’t happen at a dramatic, visible threshold. It happens quietly, function by function, as new offices open, as management layers get added as the founders’ bandwidth to be personally present in every important conversation gets divided across an ever-larger set of demands. By the time a company passes roughly 150 to 200 people, the informal model has quietly failed everywhere at once - and nobody sent a memo announcing it. That threshold is not arbitrary. It echoes a long line of organisational research on the limits of informal coordination, most famously Robin Dunbar’s work on the cognitive ceiling of stable social groups: past it, trust and visibility can no longer substitute for structure, whatever the industry.

What makes this diagnosis hard to make from the inside is that the symptoms rarely present as a governance problem. They present as individual, seemingly unrelated frustrations: a slow decision here, a duplicated effort there, a surprised finance team, a burned-out VP. Leadership teams treat these as isolated performance issues - this person needs coaching, that team needs a better process, this function needs a new hire - when the actual root cause is structural: nobody has explicitly decided who has the authority to decide what, at what threshold visibility is required before a decision proceeds what information needs to flow between which teams before those teams can operate independently without colliding.

This is the core insight that most fast-growth leadership teams miss it’s worth stating plainly: chaos at scale is very rarely a symptom of too little management effort. It is almost always a symptom of an operating model that was never designed for the scale it is now being asked to carry. You cannot manage your way out of a structural gap. You have to build the structure.

Why the Conventional Responses Make It Worse

Faced with this pattern, most leadership teams reach for one of two conventional fixes I want to be specific about why each one, on its own, tends to fail - because both come from a reasonable instinct and both routinely backfire.

The first is importing enterprise process wholesale. A founder who has read about how a much larger, more mature company runs its planning cycles or its approval chains decides to adopt something structurally similar, all at once, across the organisation. This usually fails for a simple reason: enterprise governance structures are calibrated for enterprise risk profiles and enterprise coordination costs. A two-hundred-person company does not have the same risk surface as a ten-thousand-person one importing that level of process produces exactly the kind of decision latency and accountability diffusion that slows a fast-growth company down without meaningfully reducing its actual exposure. I have watched scale-ups install multi-stage approval chains for decisions that, a year earlier, one person made unilaterally in an afternoon - and watched the same organisation’s actual velocity collapse by a third within two quarters, while the underlying coordination failures that prompted the change remained almost entirely unaddressed. The new process targeted the appearance of the problem, not its structure.

The second conventional response is hiring a senior operator - a COO, a VP of Operations, sometimes an entire “PMO” - and delegating the governance problem to them as a headcount solution rather than a design problem. This can work, but it fails more often than it succeeds the reason is instructive: a single hire, however capable, cannot retrofit governance onto an organisation through personal authority and hustle any more effectively than the founders could. If the new hire’s mandate is vague - “fix how we operate” - they inherit exactly the same informal, proximity-dependent decision model the founders were running, just with one more person now expected to be everywhere at once. Within two or three quarters, the new operator has become the new bottleneck the company is back where it started, with an additional salary line and no structural change to show for it.

Both failure modes share the same underlying error: they treat governance as a resourcing question - more process, more headcount - rather than a design question about where decision rights actually sit and how information needs to move for those rights to be exercised well. (This is the same structural misdiagnosis I’ve written about in the context of over-engineered process more broadly - see Complexity Traps: Why More Process Doesn’t Mean Less Risk - but at the fast-growth stage it shows up specifically as a decision-rights vacuum rather than an excess of controls.)

A Governance Framework: Decision Architecture for Fast-Growth Organisations

What I use with fast-growth leadership teams what we eventually built with the software company from the opening, is a framework built around four elements. I want to be precise about each, because the value is in how they interact, not in the labels themselves.

Decision mapping by category, not by org chart. The first move is to stop thinking about decisions in terms of who reports to whom start thinking in terms of decision categories - pricing changes, hiring above a certain level, spend above a certain threshold, product scope changes, external partnership commitments - and assigning each category an explicit, named decision-maker along with the specific conditions under which that decision-maker must consult others before acting. This sounds like a RACI exercise structurally it resembles one, but a RACI chart starts from the assumption that authority already exists and merely needs documenting. This exercise starts from the opposite assumption: that for a meaningful share of decision categories, authority has never actually been assigned - and the point of the walkthrough is to force those assignments for the first time. Which means the exercise itself - asking “who, specifically, decides this who genuinely needs to be consulted versus merely informed” - surfaces disagreements and gaps the organisation has been quietly living with, sometimes for a year or more. At the software company, this exercise revealed that no one had actual, sole authority over marketing spend commitments above five figures; three different people believed, independently and in good faith, that the authority was theirs. This is a close cousin of the diffuse-ownership problem I’ve described in software delivery contexts - see Execution Accountability: How to Build a Culture That Delivers - except here the ambiguity sits at the level of company-wide decision categories rather than individual workstreams.

Escalation thresholds, not escalation vibes. Once decision categories have named owners, the second element is defining, in specific and falsifiable terms, what triggers escalation beyond that owner - a monetary threshold, a customer-facing risk, a cross-functional dependency, a reversibility question. The instinct in fast-growth companies is to rely on judgment: “use your discretion, escalate if it feels big.” This sounds sensible and is, in practice, close to useless, because “feels big” is calibrated differently by every individual the people most likely to under-escalate are precisely the confident, capable operators a fast-growth company depends on most - the ones whose judgment has been correct often enough that they’ve stopped questioning where its limits are. Specific thresholds remove that ambiguity. A spend commitment above a defined figure requires visibility before, not after, commitment. A product change that affects a named enterprise account’s contractual terms requires a specific sign-off. This is not about distrust of good operators. It’s about giving good operators a clear, low-friction signal for when their excellent individual judgment needs to be joined by someone else’s context.

Information flow designed around collision points, not comprehensive reporting. This is the element fast-growth companies get most wrong, usually by overcorrecting into more status meetings and more dashboards once they sense a coordination problem. The actual fix is narrower and more surgical: identify the specific points where two or more teams are likely to make decisions that affect each other - parallel product workstreams, regional teams solving similar operational problems, sales commitments that touch delivery capacity - and build a lightweight, specific information channel at exactly those collision points, rather than a general-purpose reporting layer that tries to give everyone visibility into everything. More reporting volume does not solve a coordination problem; it usually just buries the specific signal that matters inside noise nobody has time to read closely. There, the fix for the duplicated internal tools problem was not a new all-hands reporting cadence. It was a single, mandatory, thirty-minute cross-regional sync specifically for engineering leads before any new internal tooling project began - a narrow, targeted channel aimed precisely at the collision point that had actually caused the duplication. Left unaddressed, this kind of uncoordinated parallel build-out is exactly how organisations accumulate the kind of fragmented internal tooling and integration debt I’ve written about separately - see Integration Debt - The Hidden Cost of Point Solutions.

Review cadence tied to growth stage, not to the calendar. The fourth element the one leadership teams find hardest to internalise, is that the governance structure you build is not a permanent artefact. It is calibrated to a specific headcount, complexity level geographic footprint it needs a scheduled review - not an annual ritual, but a trigger tied to actual growth milestones: doubling headcount, opening a new region, crossing a defined revenue threshold, adding a management layer. That leadership team committed to reviewing its decision map and escalation thresholds at every 50% headcount increase, treating governance the way a good engineering team treats technical architecture: something that was correct for its scale yesterday and needs deliberate, scheduled reassessment, not something you get right once and leave alone.

Implementation Risks and Trade-offs

None of this installs cleanly leaders who expect a frictionless rollout will misread the early resistance as a sign the framework is wrong, when it is usually a sign it is working.

Decision mapping surfaces uncomfortable ambiguity surfacing it is uncomfortable by design. Some of your most capable people have been operating with informal authority they were never explicitly granted clarifying decision rights will, in some cases, mean taking authority away from someone who has been exercising it - often well - without a formal mandate. Expect this to generate genuine friction expect some of the most articulate objections to come from exactly the people whose informal scope is being narrowed. This does not mean the objection is wrong every time. Sometimes the existing informal arrangement really is the right one the exercise should confirm and formalise it rather than change it. But the assumption should not be that resistance signals a design flaw. Often it signals that the design is doing precisely what it is meant to do.

Escalation thresholds, set too conservatively, recreate the exact problem you are trying to solve. If every threshold is set low enough to catch every possible risk, you have simply rebuilt centralised bottleneck decision-making with extra paperwork. This is the single most common failure I see in early implementations: leadership, nervous about losing visibility, sets thresholds so low that nearly everything still routes through the same one or two people the company experiences no meaningful improvement in velocity while believing it has “done governance.” Thresholds need real calibration, revisited genuinely at each growth-stage review, not set once out of caution and left untouched.

There is also a real cost to the initial mapping exercise itself. It takes real senior time - the team spent roughly three weeks of concentrated leadership effort building the first version of its decision map - and it will, in the short term, feel like a distraction from the operational fires the framework is ultimately meant to reduce. Leaders under real pressure will be tempted to defer it indefinitely in favour of firefighting the immediate crisis. This is precisely backwards, because the immediate crises are, in a fast-growth company that has outgrown its informal model, usually downstream symptoms of the exact structural gap the mapping exercise is designed to close.

And finally: none of this survives a founder who, having built the framework, continues to personally intervene in decisions the framework has explicitly delegated elsewhere, out of habit or discomfort with letting go. I have watched this specific failure sink an otherwise well-designed governance rebuild more than once. If the CEO keeps overriding the named decision-owner for a category they have formally delegated, the organisation learns, correctly, that the framework is decorative reverts within a quarter to routing everything through the founder informally again, regardless of what the documentation says. Governance frameworks are tested either validated or destroyed, by leadership’s actual behaviour the first time a delegated decision goes a way the founder wouldn’t have chosen personally.

What Changed What It Cost

Eight months after the initial diagnostic, the company had a functioning decision map covering eleven major categories, calibrated escalation thresholds reviewed at their most recent headcount milestone, four targeted cross-functional sync points replacing what had briefly become an over-correction into excessive general reporting a scheduled governance review tied explicitly to their next growth trigger rather than the calendar. Decision cycle time on the categories we mapped dropped by roughly half within the first quarter, measured simply by tracking time from “decision needed” to “decision made” across a sample of recurring decision types. More tellingly, the CEO reported something he hadn’t anticipated: he was in noticeably fewer meetings, not because the company had become less active, but because a large number of decisions that used to require his informal presence now had an explicit, legitimate owner who didn’t need him in the room to act.

The duplicated tooling problem did not recur. Marketing spend surprises didn’t recur in the two quarters that followed - not through more scrutiny of marketing, but through a threshold that made pre-commitment visibility automatic rather than dependent on someone remembering to mention it. And several of the senior people who had been quietly burning out as informal decision bottlenecks reported, unprompted, that they finally felt like their actual scope matched what they had authority to decide - which turned out to matter more for retention than any compensation adjustment the company had considered making instead.

The Strategic Reflection

Fast-growth companies do not fail at governance because their leaders lack discipline or their teams lack talent. They fail because the informal, proximity-based operating model that got them through their first hundred employees quietly stops working somewhere past it nobody schedules the redesign, because there is no dramatic moment that announces the model has broken. It just gets slower, more duplicated, more surprising more exhausting for the people holding it together informally.

The organisations that scale without descending into chaos are not the ones that grew slower, or the ones that hired the single right operator to hold it all together through force of will. They are the ones that treated their decision architecture the way they would treat any other piece of infrastructure under load: something designed for a specific scale, monitored for signs it has been outgrown deliberately redesigned at defined intervals rather than left to erode until a crisis forces the conversation.

If you are leading a company somewhere on that curve - past the size where everyone can see everyone else’s work, but without an explicit answer to who decides what and at what threshold visibility is required - the uncomfortable but useful question is not “do we need more management.” It’s “have we actually designed decision rights for the size we are now, or are we still quietly running the structure that worked when we were a third this size hoping nobody notices it’s stopped fitting.” Answer that honestly the drag that looks like a hundred unrelated problems usually turns out to be one problem, wearing a hundred different disguises.

Gustavo De Felice is a senior digital project leader and systems architect with over 1,200 managed projects across technology, logistics digital transformation. He writes on execution governance, performance accountability the structural design of teams that deliver under complexity.

A few years ago I was brought into a mid-sized software services company to diagnose why a flagship client programme kept slipping. On paper, there was nothing wrong with how the team worked. They ran daily stand-ups. They maintained a dashboard with red-amber-green status indicators updated every Friday. Every workstream had a named owner. Steering committee decks were polished, colour-coded, and delivered on time, every time. If you sat in on a status meeting, you would have walked away thinking this was a well-governed programme.

And yet the programme was nine weeks behind a schedule that had already been re-baselined twice, the client’s trust was eroding visibly in every call, and nobody inside the delivery organisation could tell me, with a straight face, why any individual milestone had actually been missed.

This is the pattern I want to unpack in this piece, because I have now seen it enough times, across enough industries, to be confident it is not an anomaly. It is close to the default failure mode for organisations that believe they have built an accountability culture and have, in fact, built something else entirely — a set of rituals that produce the appearance of ownership without any of its substance.

The Diagnostic: What Was Actually Happening

Let me describe what I found when I looked past the dashboards, because the gap between the reporting layer and the operational reality is where most of this story lives.

The programme had seventeen workstreams. Each had a named lead. Each lead reported status weekly. But when I asked individual leads a simple question — “what specifically are you accountable for delivering, and what decisions are entirely yours to make without escalation?” — I got seventeen different answers, most of them vague, several of them contradictory, and at least four that directly conflicted with what a peer lead believed about the same boundary.

One workstream lead believed she owned the integration testing schedule. The engineering manager she worked with believed he owned it, because he controlled the environment it ran in. Neither had told the other this.

Both had been reporting “green” status independently for three consecutive weeks, based on two entirely different — and incompatible — definitions of what “on track” meant for that workstream. Nobody discovered the discrepancy until the actual test cycle collapsed under a scheduling conflict that either of them could have flagged individually, weeks earlier, if either had felt it was unambiguously theirs to flag.

This was not an isolated case. Across the programme, I found the same shape repeating: status reports that were accurate reflections of what each individual believed to be true, built on foundations of ownership that were never actually assigned with any precision. The dashboard was not lying. It was faithfully reporting the outputs of a system that had never established, in any binding way, who was accountable for what.

Layered on top of this was something more corrosive. Because the organisation’s leadership had, at some point, decided the programme needed “more accountability,” the response had been to intensify scrutiny. More status meetings. More detailed reporting templates. A weekly “root cause” review where missed items were publicly walked through in front of the wider team. The intent was good. The effect was the opposite of what was intended.

What I observed in that root cause review was people optimising for a very specific and very human objective: not missing anything visibly, this week, in this meeting. Workstream leads had learned — correctly, given the incentives — that the fastest way to survive a root cause review was to keep your status reporting vague enough that nothing you said could be pinned on you later, while still looking sufficiently detailed to satisfy the reviewer in the room.

Precision in reporting had become a liability. Ambiguity had become a survival strategy. And so the reporting got more elaborate in form and less useful in substance, cycle after cycle.

This is the trap I want to name directly, because it is the single most common misdiagnosis I encounter in organisations trying to fix delivery problems: they believe their culture lacks accountability, when what it actually lacks is a working definition of ownership, decision rights, and honest status — and what they have built instead, in the absence of that definition, is a surveillance apparatus that punishes visibility rather than rewarding it.

Why Most Accountability Initiatives Fail

Before I get to what fixed this particular programme, it is worth being precise about why the conventional response to delivery problems so reliably makes things worse rather than better. In my experience, accountability initiatives fail for one of two structural reasons, and almost never because people involved lack the will to perform.

The first failure mode is conflating accountability with blame. When leadership responds to missed delivery by intensifying scrutiny on individuals - publicly reviewing misses, tightening reporting cadence, adding layers of sign-off - the underlying message received by the organisation is not “we need clearer ownership.” It is “mistakes will be found and attributed to you personally.”

This produces entirely rational defensive behaviour. People stop surfacing problems early, because early surfacing means longer exposure to scrutiny. They stop making explicit commitments, because explicit commitments are the thing that gets used against them later. They learn to manage the optics of status rather than the substance of delivery. Blame cultures do not produce more accountability. They produce more sophisticated concealment, executed by capable people who have correctly read the incentive structure they are operating in.

The second failure mode, subtler and more common in organisations that have already learned to avoid overt blame culture, is conflating accountability with process compliance. This is what had happened in the programme I described. Leadership had installed more process — more meetings, more templates, more sign-offs — believing that more structured reporting would produce more accountability. But process compliance and accountability are not the same thing, and treating them as interchangeable is where a huge amount of organisational energy gets wasted.

Process compliance asks: did you follow the ritual? Did you show up to stand-up? Did you fill in the status template? Did you attend the steering committee? Accountability asks a fundamentally different question: did you deliver what you specifically committed to, and if not, did you say so clearly and early enough for someone to act on it?

An organisation can achieve perfect process compliance - full attendance, complete templates, on-time reports - while accountability, in the substantive sense, is entirely absent. This is exactly what a status dashboard full of green indicators next to a nine-week schedule slip actually represents: a system that has faithfully executed its rituals while failing at the thing the rituals were meant to serve.

Both failure modes share a common root. They treat accountability as something you enforce through monitoring intensity, rather than something you design through structural clarity. You cannot monitor your way into a culture that delivers. You have to build the underlying architecture that makes honest, precise commitment the path of least resistance — and then monitoring becomes a much smaller, much less adversarial part of the system.

A Framework: Four Pillars of Genuine Execution Accountability

What I use, both in diagnosing programmes like the one above and in designing delivery structures from scratch, is a four-pillar framework. I want to walk through each pillar in some depth, because the value is in the precision of each one, not in the headline categories.

1. Clear ownership

Ownership, properly defined, means that a specific named individual is accountable for a specific, bounded outcome — not a task, not an activity, an outcome. This distinction matters enormously in practice.

“Owns the integration testing workstream” is an activity description. “Owns the decision of whether the system is ready to move to the next test phase, and is accountable if that decision proves wrong” is an outcome-based ownership statement, and it is unambiguous in a way the first version is not.

Genuine ownership can be tested with a simple question: if this outcome fails, is there exactly one person whose job it was to prevent that, and does that person know it is them? In the programme I described, the honest answer for several critical outcomes was no — there were zero people who considered themselves unambiguously accountable, or there were two, which functionally amounts to the same problem. Diffuse ownership is not shared accountability. It is an absence of accountability wearing a disguise.

2. Decision rights

Ownership without the authority to make the relevant decisions is not accountability, it is exposure — you are being asked to answer for outcomes you do not actually control. This is a distinction leadership teams underestimate constantly.

In the case above, the integration testing lead did not have the authority to unilaterally resolve environment scheduling conflicts, because that authority sat with an engineering manager who had a different set of priorities and a different reporting line. She was accountable for an outcome she could not fully control. This is structurally unfair, and it produces exactly the behaviour you would expect from a capable person placed in an unfair position: hedged reporting, deflected responsibility, and an unwillingness to commit to timelines she could not actually guarantee.

Decision rights need to be explicit and need to travel with ownership. If someone owns an outcome, they need either the authority to make the decisions that determine that outcome, or an unambiguous and fast escalation path to whoever holds that authority. Silence on this point is where accountability structures quietly collapse.

3. Visible commitments

This is the pillar most organisations underinvest in, because it requires a level of specificity that feels uncomfortable to install.

A visible commitment is not “on track” or “green.” It is a specific, dated, falsifiable statement: this component will be integration-tested by this date, using this environment, with this dependency resolved by this other date.

The value of this level of specificity is not bureaucratic precision for its own sake. It is that specific commitments are falsifiable in a way vague commitments are not, and falsifiability is what makes early problem detection possible. A vague commitment can drift for weeks without anyone being able to say, definitively, that it has slipped. A specific commitment either holds or it doesn’t, and everyone can see which, in real time, without waiting for a retrospective root cause review to reconstruct what actually happened. Visible commitments transform status reporting from a narrative exercise into a verifiable one.

4. Honest status reporting

This pillar depends entirely on the first three being in place, and this is the sequencing point that most organisations get backwards. They try to install honest status reporting first — through more detailed templates, more frequent updates, more scrutiny — without first fixing ownership ambiguity, decision-rights gaps, or vague commitments.

This does not work, because honesty in status reporting is not primarily a discipline problem. It is a consequence problem. People report honestly when the consequences of honest reporting are less costly than the consequences of dishonest reporting, and that calculus is set by the surrounding structure, not by exhortation.

If ownership is ambiguous, honest reporting exposes you to blame for outcomes that were never clearly yours, and dishonesty becomes the rational choice. If commitments are vague, there is nothing precise to report honestly against, so reports default to impressionistic status colours instead of falsifiable statements. Fix the first three pillars, and honest reporting becomes the natural output of the system rather than something you have to extract through pressure.

What Actually Changed the Programme

Returning to the programme that opened this piece: the intervention was not more process. If anything, we removed process. The weekly root cause review, in its original public, blame-adjacent format, was retired entirely. In its place, we did three things, in this order, over about six weeks.

First, we rebuilt the ownership map from scratch, workstream by workstream, and forced explicit resolution of every ambiguity we found — including the integration testing conflict, which was resolved by giving the testing lead direct authority over environment scheduling for her workstream’s windows, full stop, with the engineering manager retaining authority over everything outside those windows.

This took an uncomfortable series of conversations, because resolving ambiguity always means someone gains authority they didn’t have and someone else loses authority they assumed they had. There is no way to do this without some friction. Avoiding that friction is precisely how the original ambiguity had been allowed to persist for months.

Second, we rewrote every workstream’s reporting format to require a specific, dated, falsifiable commitment rather than a status colour. No more “on track.” Instead: “integration testing for module four begins Tuesday the 14th, contingent on environment availability confirmed by Friday the 10th.” This felt, to several leads, like an enormous increase in exposure. It was, in fact, the opposite — it gave them a precise basis on which to flag risk early, rather than an ambiguous basis on which any deviation looked like personal failure.

Third, and this was the change that actually shifted behaviour fastest, we changed what leadership did with early warnings. When a workstream lead flagged, three weeks in advance, that a dependency was at risk, leadership’s visible response was to treat this as the system working correctly — the entire point of visible, falsifiable commitments is that they surface risk early enough to act on it — rather than as a performance concern about the lead who raised it.

This single shift in leadership behaviour, repeated consistently over a handful of cycles, did more to produce honest reporting than any template redesign. People believed the signal because leadership’s actions, not its stated policy, confirmed that raising a flag early was safe and useful rather than personally costly.

The programme did not immediately hit its revised deadline — there was too much accumulated schedule debt for a six-week structural fix to erase overnight. But the trajectory changed within a month. Risks started surfacing at four and five weeks of lead time instead of surfacing as surprises in the week they materialised.

The client, notably, commented on this shift before we did - their steering committee reported that status updates had become “more boring,” in their words, because there were fewer surprises. Boring, in delivery, is usually a synonym for accountable.

Implementation Risks and Trade-offs

None of this is free, and it is worth being direct about the costs, because leaders who install this framework expecting a frictionless transition will be disappointed and may abandon it prematurely.

Resolving ownership ambiguity generates conflict. Someone in your organisation is currently benefiting, whether they recognise it or not, from an unresolved boundary — it gives them flexibility, cover, or leverage they will lose once ownership is made explicit. Expect resistance from exactly the people who are, not coincidentally, often the most articulate about why “it’s more complicated than that.” Sometimes it genuinely is more complicated. Most of the time, complexity is the argument people reach for when they prefer ambiguity to accountability.

Requiring falsifiable commitments will, initially, produce a wave of reported risk that looks alarming compared to the artificially smooth reporting you had before. This is not the system degrading. It is the system finally showing you what was always true. Leaders who panic at this initial spike and revert to vaguer reporting formats will lose the entire benefit of the framework at exactly the moment it starts working.

And critically: none of the first three pillars matter if leadership’s actual behaviour, under pressure, reverts to blame when a falsifiable commitment is missed. You can install every structural element of this framework and have it collapse in a single afternoon if a senior leader responds to an honestly reported miss by publicly attributing it to individual failure rather than treating it as information about where the system needs support. Execution accountability is not primarily a documentation exercise. It is a test of whether leadership’s revealed behaviour matches its stated principles the first time those principles cost something.

The Strategic Reflection

The organisations that consistently deliver are not the ones with the most elaborate accountability rituals. In my experience, they often have noticeably less process overhead than the organisations that are struggling, because they have replaced volume of oversight with precision of structure. Clear ownership, matched decision rights, visible and falsifiable commitments, and status reporting that leadership has made genuinely safe to give honestly — these four things, done well, need far less monitoring machinery around them than a culture trying to compensate for their absence through scrutiny.

If you are a leader looking at your own organisation’s delivery problems and reaching instinctively for more process, more reporting, more meetings — pause and ask the harder question first. Is the problem that people are not being watched closely enough? Or is it that nobody has actually been given unambiguous ownership of the outcomes they are being judged on, the authority to act on that ownership, and a system where telling you the truth early costs less than telling you a comfortable story later?

Fix that architecture, and the dashboards start telling the truth on their own. Fail to fix it, and no amount of scrutiny will produce anything but better-disguised versions of the same failure.

What’s the ambiguous ownership boundary in your organisation — the one everyone quietly works around but nobody names? Hit reply and tell me. The patterns that come back are always more universal than people expect, and I may explore the most common ones in a follow-up.

Gustavo De Felice is a senior digital project leader and systems architect with over 1,200 managed projects across technology, logistics, and digital transformation. He writes on execution governance, performance accountability, and the structural design of teams that deliver under complexity.

When I dug in, the pattern became clear. Their entire AI estate was built on a single-shot model: a task comes in, a prompt is constructed, a response comes back, a human reviews it, work continues. Clean. Auditable. Controllable. And, for anything genuinely complex, fundamentally inadequate.

The automation handled the easy cases beautifully. Document summarisation. Template population. First-draft generation. But when they tried to extend it to more substantial work , coordinating multi-step logistics queries, resolving exceptions in real time, handling supplier communications that required back-and-forth reasoning , it stalled. The prompts got longer. The outputs got less reliable. Engineers spent increasing time building elaborate pre- and post-processing layers to compensate for what the single call couldn’t do. The system was straining at the edges of an architecture that was never designed for the kind of work they were now asking it to do.

This is the single-shot ceiling and almost every organisation that has moved past early AI experimentation is beginning to hit it.

Why Single-Shot Prompting Has an Architectural Ceiling

The single-shot model, send a prompt, receive a response, maps neatly onto a certain category of tasks. Tasks that can be fully specified in advance. Tasks whose inputs are clean and complete. Tasks whose outputs can be evaluated in a single pass. For this category, it works well enough.

Real operational work rarely fits this profile.

Consider what actually happens when a senior analyst resolves a complex procurement exception. They read the initial case notes, form a hypothesis, check a few records, revise their understanding, consult a policy document, draft a response, reconsider it against a constraint they just remembered, redraft and then send. This is not a linear process and it is not a single cognitive act. It is an iterative loop of reasoning, action, observation and re-reasoning, repeated until the analyst is satisfied that the output is correct.

Early AI prompting asked language models to collapse all of that into one shot. Write the best possible prompt, get the best possible output, move on. The implicit model was: if the prompt is good enough, the output will be right. But this fundamentally misunderstands what makes complex work complex. The complexity is often not in the specification it’s in the feedback. Knowing whether your first approach was correct requires looking at what happened when you tried it.

Single-shot systems cannot look at what happened. They generate output and stop. The feedback loop exists only in the human reviewer’s head, which means the human must carry the entire cognitive load of the iteration. For high-volume, complex work, this negates a substantial portion of the value the AI was supposed to deliver.

The ceiling is not about model quality. Better models help at the margins, but they cannot overcome a structural limitation in the system design. The ceiling is architectural.

From Chains to Loops: The Structural Shift

Most teams who recognised this limitation responded with chaining, connecting multiple AI calls in sequence, where the output of one becomes the input of the next. This is better than single-shot for some use cases: it decomposes complex tasks into stages, allows for specialised prompting at each stage and produces more structured outputs.

But chaining is still fundamentally linear. It assumes that you can specify the path from input to output in advance. A chain is a fixed route. If the AI encounters something unexpected at step three, an ambiguous input, an error from an external system, information that changes the interpretation of earlier steps, the chain has no mechanism to adapt. It proceeds forward regardless, accumulates the error and delivers a flawed result at the end. Or it fails outright, with no graceful recovery.

The move from chains to loops changes the underlying design philosophy. A loop does not assume a predetermined path. It assumes a goal, provides tools for pursuing it and allows the system to reason about what to do next based on what it has already observed. A loop can discover that its first approach was wrong and try something different. It can request additional information mid-task. It can detect that it is stuck and escalate. None of this is possible in a chain, because chains do not have the concept of “what happened when I tried this.”

The practical difference shows up clearly in exception handling. In a chained system, exceptions are either anticipated in advance (with explicit branches) or they break the flow. In a loop-based system, exceptions are just observations, the agent registers what happened, reasons about what it implies and decides how to respond. This is a profound difference in resilience and it is why loop-based systems tend to outperform chained systems significantly in real operational environments where variability is normal rather than exceptional.

The ReAct Pattern and What It Actually Means in Practice

The theoretical foundation for most modern agentic loops is something called the ReAct pattern, a design that interleaves reasoning steps with action steps. The name is a contraction of Reason and Act and the pattern is straightforward in concept: the agent thinks about what to do, does it, observes the result, thinks about what it learned and decides on the next action. Repeat until the task is complete.

What makes ReAct significant is not the cycle itself, humans have been doing this forever , but the formalisation of reasoning as an explicit, observable step rather than a hidden process inside the model. When reasoning is externalised, you can see what the agent was thinking when it took a particular action. You can identify where its reasoning went wrong. You can build systems that intervene when the reasoning appears to be heading in a bad direction.

In practice, a ReAct-style agent working on a real operational task might look like this. The agent receives a task: resolve a supplier delivery discrepancy. It reasons: the discrepancy involves three items, the purchase order is in the ERP, I should retrieve the PO line items first. It acts: queries the ERP. It observes: two of three items match; the third has a quantity variance. It reasons: this variance might be a system entry error or a genuine partial delivery; I should check the goods receipt notes. It acts: retrieves the goods receipt log. It observes: the goods receipt confirms the partial delivery was physically received but not annotated. It reasons: this is a documentation gap, not a genuine discrepancy; the resolution is a GRN amendment rather than a supplier claim. It acts: drafts the amendment record.

What just happened is qualitatively different from anything a single prompt could produce. The agent made decisions based on information it did not have at the start. It changed direction mid-task based on what it found. It produced a resolution that depended on reasoning across multiple data sources in sequence.

This is not AI as text generator. It is AI as operational participant.

Loop Engineering as a Design Discipline

Here is where most technical teams and most consultants alike go wrong: they treat loop engineering as a technical pattern to implement rather than a design discipline to practise. They build the loop, confirm that it runs and ship it. What they leave behind is everything that makes the loop reliable, governable and safe to operate at scale.

Loop engineering, done properly, is the systematic design of how an agentic system reasons, acts, observes and terminates. Every element of that cycle is a design decision and every design decision has operational consequences.

Goal specification is the first and most important design decision. Loops need termination conditions and termination conditions require precise goal definitions. “Resolve the supplier discrepancy” is not a goal definition. It is a task label. A goal definition specifies what “resolved” looks like: the ERP record matches the physical goods receipt, the supplier has been notified if a claim is warranted, the documentation trail is complete. Vague goals produce endless loops or loops that terminate on the wrong condition. This is not a technical failing , it is a specification failure that happens upstream of any code.

Tool design is the second critical dimension. A loop is only as capable as the tools available to the agent operating it. Tools are the means by which the agent interacts with the real world , querying databases, calling APIs, sending notifications, writing records. Good tool design means tools that return structured, predictable outputs; that surface relevant errors explicitly rather than silently; and that are scoped to the minimum necessary permissions. Tool design is system design and it deserves the same attention and rigour as any other architectural decision.

Context management is where most loop implementations break down in production. Each iteration of a loop generates new information: what the agent tried, what it found, what errors it encountered, what decisions it made. If that context accumulates without management, two things happen: the system becomes expensive (context windows are not free) and the agent’s reasoning degrades as it becomes harder to distinguish relevant recent observations from historical noise. Effective loop engineering requires deliberate strategies for compressing, summarising and pruning context between iterations.

Termination logic is the safety mechanism and it must be treated as a first-class design requirement. Success conditions, failure conditions and escalation conditions must all be explicitly defined before a loop goes into production. Success is obvious in retrospect but must be specified in advance. Failure is often under-specified: many teams define what success looks like but never define what the system should do when it is not making progress. Escalation is the path that connects machine loops to human judgement and without a well-designed escalation path, autonomous systems either run forever or fail silently.

Multi-Agent Loops and Coordination Complexity

The natural evolution beyond single-agent loops is multi-agent systems: architectures where multiple agents operate in coordinated loops, each handling a specialised aspect of a larger task. The planning agent that decomposes complex work. The execution agents that carry it out in parallel. The review agent that validates outputs before they are committed. The escalation agent that monitors for system health and intervenes when something is going wrong.

Multi-agent systems unlock capabilities that single-agent loops cannot achieve. Parallelism , tasks that would run serially in a single-agent loop can run concurrently across multiple agents. Specialisation , different agents can be optimised for different reasoning styles, different tool sets, different risk tolerances. Redundancy , multiple agents can validate the same output independently, increasing reliability.

But multi-agent systems introduce coordination complexity that is qualitatively different from single-agent complexity and organisations that underestimate this pay for it in production instability.

The critical risks in multi-agent coordination fall into three categories.

Inconsistent state is the most pervasive. When multiple agents are reading from and writing to shared systems concurrently, you must reason carefully about consistency. An agent that reads a customer record and then acts on it must have guarantees about whether another agent might have modified that record in the interim. The coordination mechanisms that handle this , locks, queues, optimistic concurrency controls, are not novel, but they must be consciously designed rather than discovered through incident.

Divergent reasoning occurs when agents that should be working toward the same goal develop conflicting interpretations of the task or the available information. This is particularly subtle in large-scale multi-agent deployments because the divergence may not surface as an obvious error , it may surface as a slightly wrong result that passes automated checks but is incorrect in ways that only become visible downstream. Detecting divergent reasoning requires observability that goes beyond output validation; you need to be able to inspect the reasoning chains that produced the outputs.

Cascading failure is the risk that dominates the late stages of multi-agent loop deployments. A failure in one agent , whether a tool call error, a reasoning mistake, or a resource constraint , can propagate through dependent agents if the system has not been designed with blast radius in mind. This requires explicit circuit-breaker design: the ability to isolate a failing agent, prevent it from affecting downstream work and route to fallback behaviour or human escalation.

Coordination complexity does not mean multi-agent systems should be avoided. It means they should be approached with the same engineering discipline that complex distributed systems have always required , because that is, fundamentally, what they are.

Practical Strategies for Implementing Loop-Based AI

After managing AI transitions across multiple organisations and environments, I have developed a set of practical principles for loop-based AI implementation that I apply consistently. These are not universal laws , every context has its own constraints , but they represent the lessons that show up repeatedly.

Start with observability, not capability. The first thing you need from a loop-based system is not that it does more work, but that you can see what it is doing. Before optimising for performance, build the instrumentation that lets you inspect reasoning chains, observe tool calls, measure iteration counts and detect when loops are spending time unproductively. This instrumentation will pay dividends throughout the system’s lifetime and it is far harder to retrofit than to build from the start.

Design termination conditions before building loops. Every loop should have documented success conditions, failure conditions and escalation conditions before a single line of implementation code is written. If you cannot specify the termination conditions clearly before building, you do not understand the task well enough to automate it. This discipline also forces a productive conversation between technical teams and domain experts about what “done” actually means , a conversation that is almost always valuable regardless of what happens to the AI system.

Treat loop failures as designed outcomes, not exceptions. Production loops will hit situations they cannot resolve. This is not a failure of the system , it is the correct behaviour of a system that knows its own limits. What distinguishes well-designed loops from poorly designed ones is not whether they fail, but whether they fail gracefully: surfacing relevant context, escalating to the right person and preserving the state needed for a human to pick up where the agent stopped.

Introduce autonomy incrementally. Most organisations benefit from starting loop implementations in a supervised mode: the agent runs the loop, but a human reviews and approves each iteration’s actions before they are committed. This adds friction, but it generates exactly the kind of feedback you need to understand how the agent reasons, where it makes mistakes and which types of decisions are safe to fully automate versus which should remain human-approved indefinitely. The goal is not to automate human review away as quickly as possible , the goal is to earn the right to automate it through a demonstrated track record.

Match loop architecture to task variability. Not all loops need the same design. A retry loop for a well-defined data processing task needs much simpler termination logic than a multi-step reasoning loop for complex exception resolution. Resist the temptation to build one universal loop architecture for all tasks , the flexibility required to handle high-variability tasks will make your low-variability loop implementations unnecessarily fragile.

Governance: Who Decides When Machines Iterate Autonomously?

This is the question that most technical implementation guides do not answer and it is the question that determines whether organisations successfully scale agentic systems or accumulate operational liability.

When a loop-based agent is working autonomously on a task , iterating, making decisions, taking actions , the governance question is not technical. It is about accountability, authority and risk tolerance. Who has authorised this agent to take these actions? What is the upper bound on the impact those actions can have before a human must be consulted? What happens if the agent’s decisions are wrong?

These are not questions that engineering teams can answer alone. They require participation from risk, compliance, legal and senior operations leadership. And they need to be answered before the system goes into production, not after the first significant incident.

The governance framework for agentic loops needs to address several dimensions.

Scope boundaries define the universe of actions an agent is authorised to take. These should be specific and conservative. An agent authorised to query systems and draft responses has a very different risk profile from an agent authorised to write to systems and send external communications. Scope boundaries should be documented, technically enforced where possible and reviewed periodically as the system’s track record develops.

Escalation authority defines who receives escalations from the agent and what their expected response time is. This sounds procedural, but it is frequently under-specified in practice. If the agent escalates to a general inbox that nobody monitors actively, the escalation path does not function. Escalation paths need named owners, SLAs and backup procedures.

Audit requirements define what must be logged and retained for compliance and incident investigation purposes. For many organisations, this means storing not just inputs and outputs but the full reasoning chains that produced them , particularly for decisions with legal, financial, or customer-facing implications. This has storage and privacy implications that must be addressed in the design rather than the post-incident review.

Model change governance addresses the risk that is often overlooked entirely: what happens when the underlying AI model changes? A loop that behaves correctly today may behave differently after a model update , not catastrophically, but subtly. Organisations need regression testing protocols for loop-based systems that validate behaviour against defined benchmarks every time a dependency changes. The operational estate of a loop-based system is a software estate and it requires the same change management practices as any other critical software.

The Strategic Frame

The shift from single-shot AI to loop-based agentic systems is not primarily a technical transition. It is an operational transformation that requires organisations to develop new capabilities, new governance frameworks and a new conceptual model for what AI systems can and should do autonomously within their operations.

The organisations that are getting this right are not the ones with the most sophisticated models or the most ambitious automation roadmaps. They are the ones that have invested in understanding the design discipline that makes agentic systems reliable: clear goal specification, rigorous termination logic, principled context management, observability from day one and governance structures that give human authority over decisions that carry material risk.

The single-shot ceiling was, in a way, a useful constraint. It kept AI systems in a role that was easy to audit and easy to override. Loop-based systems offer considerably more capability, but they require considerably more discipline in exchange. The capability is real. The discipline is non-negotiable.

For senior leaders evaluating where to take their AI programmes next, the question is not whether to move toward agentic loops. Competitive pressure and operational complexity will eventually make that decision for you. The question is whether you are building the foundation that makes it safe to do so , or whether you are accelerating into a capability you have not yet built the governance infrastructure to control.

That infrastructure , the termination conditions, the escalation paths, the audit trails, the scope boundaries , is not overhead. It is what transforms an interesting technology experiment into a system you can operate with confidence at scale.

Build the loop. But design the stopping conditions first.

*Gustavo De Felice is a senior digital project leader and systems architect with over 1,200 managed projects across technology, logistics and digital transformation. He writes on agentic AI, operational governance and the management of complex technical change.*

This is what technical debt looks like at scale - and by the time most companies notice it, they’ve already been paying interest for years.

What Is Technical Debt, Really?

Ward Cunningham coined the term “technical debt” in 1992 as a deliberate analogy to financial debt. His original insight was simple: **shipping code that isn’t quite right is like borrowing from the future**. You get something now, but you pay interest later - in the form of extra effort every time you work on that part of the system.

Cunningham’s original framing was optimistic. Deliberate, strategic shortcuts were sometimes justified, as long as you paid down the debt quickly. The problem is that in most growing companies, “quickly” never comes.

Modern technical debt has expanded beyond Cunningham’s original framing. Today it encompasses:

- Architectural debt - foundational design decisions that made sense at 10 users but crumble at 10,000

- Dependency debt - outdated libraries, unmaintained packages, legacy APIs

- Test debt - insufficient automated testing that makes every change dangerous

- Documentation debt - knowledge trapped in the heads of early employees

- Operational debt - manual processes that should be automated, infrastructure that isn’t monitored

Most growing companies carry all five. Simultaneously.

The Costs Nobody Talks About

When business leaders hear “technical debt,” they think “developers are slower.” That’s technically true, but it dramatically undersells the problem. The real costs are systemic, compounding, - crucially - mostly invisible until they become catastrophic.

1. Team Morale and Retention

Talented engineers are motivated by building things. When their days are consumed by debugging mysterious failures, wrestling with a brittle codebase, or spending three days to change one line because nothing has tests - they leave.

This isn’t a soft concern. Replacing a senior engineer costs anywhere from 50% to 200% of their annual salary when you factor in recruiting, onboarding, the productivity cliff during the transition period. High-debt codebases create a doom loop: the best engineers leave first (they have options), the remaining team gets slower, the pressure increases, more people leave.

I’ve seen founding engineers quit companies they loved because the codebase became “too painful to work in.” That’s not a people problem. That’s a debt problem.

2. Customer Experience Degradation

Technical debt accumulates in the systems customers interact with most. Slow page loads. Broken edge cases. Features that almost work. A checkout process that fails 2% of the time.

That 2% doesn’t look alarming on a dashboard. But at scale, it represents thousands of lost transactions, support tickets, customers who silently churned and never complained - they just never came back.

The UK’s TSB bank migrated platforms in 2018 amid a highly debt-laden codebase. The result: **1.9 million customers locked out of their accounts**, a £330 million cleanup bill, a CEO resignation. Extreme example, but it illustrates what happens when debt in customer-facing systems finally comes due.

3. Competitive Disadvantage

Speed is a competitive moat. The ability to ship, test, iterate faster than competitors is one of the most durable advantages a technology company can have.

Technical debt destroys that advantage. A competitor built on cleaner foundations can ship a new feature in a week that takes your team six months - not because their developers are better, but because they’re not fighting the codebase while they work.

In fast-moving markets, this is existential. By the time you recognize the feature gap, the customer perception gap may already be irreversible.

4. Innovation Paralysis

The most damaging hidden cost of technical debt is what never gets built.

When the engineering team is consumed with maintenance, firefighting, navigating legacy systems, there’s no capacity for experimentation. Product managers learn to write small, safe tickets because “anything ambitious gets delayed six months.” Leadership stops proposing bold ideas because they’ve been burned too many times.

The company doesn’t die from a single catastrophic failure. It slowly stops being able to respond to the market. Competitors move. Customers evolve. And the company finds itself perpetually catching up, never leading.

5. The Financial Drain (Quantified)

The numbers are stark. McKinsey research found that **technical debt can consume 10–20% of a company’s technology budget** in interest payments - time spent on workarounds, rework, debugging instead of value creation.

For a company spending $5M annually on engineering, that’s $500K–$1M per year in pure waste. Compounding. Every year. Year over year until something breaks or someone pays it down.

A 2022 study by Stripe estimated that developers globally spend **33% of their time dealing with bad code** - nearly one in three working hours lost to debt that accumulated before they joined the company.

Why Growing Companies Are Especially Vulnerable

Technical debt isn’t unique to startups. But growing companies carry a specific combination of risk factors that make it particularly dangerous.

Pressure to ship. Early-stage companies survive by proving product-market fit fast. “Hacky” shortcuts are survival mechanisms. The problem is that the habits and the code both persist after survival is no longer the question.

Success brings scale, not rewrites. The product that worked for 1,000 users wasn’t designed for 100,000. But you can’t stop serving customers to rebuild from scratch. So you patch, extend, hold the thing together with increasingly elaborate workarounds.

Team growth outpaces knowledge transfer. The original developers who understood *why* things were built a certain way move on, get promoted, or burn out. New engineers inherit systems they don’t fully understand, documented by nobody. They write debt because they don’t know the landmines.

Investor pressure misaligns incentives.*Venture timelines reward growth metrics, not engineering quality. Board decks don’t have a slide for “codebase health.” So when there’s a choice between shipping a new feature and refactoring the data model, the feature wins - every time - until the debt calls the decision itself.

How to Identify Technical Debt Before It Becomes a Crisis

You can’t manage what you don’t measure. Here are the signals worth tracking:

Engineering red flags:

- Deployment frequency declining quarter over quarter

- Mean time to resolve (MTTR) increasing after incidents

- New engineer onboarding time exceeding 3–4 months

- High change failure rate (more than 15% of deployments causing incidents)

- Growing backlog of “known issues” that never get prioritized

Organisational red flags:

- Engineers consistently estimating 3–5x longer than business expects

- Recurring “emergency sprints” to fix things that “shouldn’t have broken”

- Senior engineers leaving citing “frustration” without more specific reasons

- Product roadmap items routinely deferred due to “technical constraints”

Quantitative metrics to track:

- Code coverage percentage - below 40% in critical paths is a warning sign

- Cyclomatic complexity - measures how tangled the logic has become

- Dependency age - how many dependencies are more than 2 major versions behind?

- Time-to-feature - how long does an average medium-complexity feature take, trending over time?

Tools like SonarQube, CodeClimate, Sourcegraph can surface many of these automatically. But the most reliable signal is still a direct, honest conversation with your senior engineers: ”If you could fix one thing about the codebase that nobody ever lets you fix, what would it be?” The answer will tell you exactly where your highest-interest debt lives.

Practical Strategies for Managing and Reducing Technical Debt

There’s no quick fix. But there is a path forward - one that requires consistent commitment, not heroic sprints.

Make Debt Visible

Invisible debt doesn’t get resourced. Create a “debt register” - a living document or backlog of known technical debt items, with rough estimates of their current cost and future risk. Review it quarterly with both engineering and business leadership.

When business leaders see “this legacy authentication module creates ~2 days of extra work per feature that touches user accounts,” they make different prioritisation decisions.

The 20% Rule

Allocate a non-negotiable 20% of engineering capacity to debt reduction in every sprint. Not as a favour. Not “when we have time.” As a standing commitment.

This does two things: it gradually reduces debt, it signals to the engineering team that quality is a value, not just rhetoric. Teams that believe their leaders care about code quality build better code - even under pressure.

Strangler Fig Refactoring

For large, high-risk legacy components, the “strangler fig” pattern works well: build the new system alongside the old one, gradually routing traffic to the new version until the old one can be safely retired. This avoids the “big bang rewrite” - which almost always takes 3x as long as estimated and introduces its own new debt.

Debt Budgets for New Features

Before shipping a new feature, explicitly acknowledge the debt it carries. Attach a debt-repayment task to every feature ticket: “This feature is being shipped with [known shortcut]. Repayment task: [specific refactor to complete within N sprints].”

This doesn’t prevent debt accumulation, but it closes the loop and creates accountability.

Hire for Craft

Engineers who care about code quality identify and remediate debt as a natural part of their work, without being explicitly asked. Culture is your highest-leverage tool. Hire people who take pride in leaving the codebase better than they found it.

Final Thoughts: Debt Is a Choice - Until It Isn’t

Technical debt begins as a series of reasonable choices made under time pressure. It becomes a crisis when those choices compound silently for years while everyone is too busy shipping to notice.

The companies that scale well aren’t the ones that never took on debt. They’re the ones that treated it like real debt: acknowledged it, tracked it, paid it down deliberately before it consumed the business.

If you lead a growing company, the most important question you can ask your engineering leadership today isn’t “why is the team so slow?” It’s: ”What does our technical debt cost us right now, what is it going to cost us in 12 months if we don’t act?”

The answer might be uncomfortable. It will almost certainly be worth knowing.

Actionable Takeaways:

1. Audit your debt - Ask your senior engineers to list the top five highest-cost areas. Schedule the conversation this week.

2. Make it visible - Create a debt register and bring it into quarterly business reviews.

3. Protect capacity - Commit 20% of engineering time to debt reduction, every sprint, non-negotiable.

4. Track leading indicators - Deployment frequency, MTTR, onboarding time are your early warning system.

5. Fix the culture - Hire for craft, celebrate refactoring, signal through decisions that quality matters.

Technical debt is a leadership problem before it’s an engineering problem. Own it accordingly.

The immediate instinct is to call this a technology problem. It is not. Or rather: it is a technology symptom of an organisational problem - a procurement dynamic, a governance gap and an architectural philosophy (or the absence of one) that has been compounding quietly for years. And because the root causes are organisational, the standard technology response - replace everything with a more modern stack - tends to reproduce the original problem in a cleaner environment, on a slightly longer timeline.

The question worth asking is not “which tools should we be using?” It is “how did we end up here and what would prevent us from arriving at the same place again?”

How the Spaghetti Forms: The Accumulation Problem

No organisation deliberately builds a spaghetti tech stack. Every tool in the estate was, at some point, a reasonable response to a real problem. Understanding why reasonable decisions compound into architectural dysfunction requires looking not at individual choices but at the decision pattern they collectively form.

The typical accumulation trajectory follows a recognisable sequence. An organisation in its early growth phase adopts tools rapidly, the priority is velocity, not architecture. The CRM is stood up. A marketing automation platform is added. Finance gets a dedicated system. HR needs something for payroll. The product team wants a project management tool. Each decision is made by the function closest to the problem, evaluated primarily on feature fit and integrated opportunistically - a native connector here, a Zapier flow there, a developer writing a quick sync script on a Friday afternoon. At this stage, the estate is manageable because it is small. The team can hold it in their heads.

The problem does not announce itself. It accumulates. The marketing team adds a webinar platform. The sales team adds a sales intelligence tool. The customer success function wants a dedicated CS platform. The finance team buys a forecasting add-on. The product team adopts a roadmapping tool. Each addition is justified. Each creates new integration surface. And because each integration was built to solve the immediate connection problem - not to become part of a coherent architecture - the overall topology grows in ways that no individual decision-maker can see or is accountable for.

What makes this dynamic so persistent is that it is self-reinforcing. Once an estate reaches a certain density of point-to-point connections, adding a new tool to the existing web becomes easier than replacing any existing tool, because replacement requires untangling the dependencies that have accumulated around the old system. The cost of switching becomes high not because any individual tool is deeply embedded - most SaaS tools are relatively shallow individually - but because the integration web around them is not. The stack ossifies around its connections, not around its core systems.

By the time the problem becomes visible - usually when a major integration breaks, or when someone is asked to produce a report that requires data from four systems that do not agree with each other - the estate typically has a decade of compounding decisions encoded in it. The spaghetti is not a metaphor for messiness. It is a structural description of a connectivity topology that has lost coherence.

The Hidden Costs: Operational and Governance

The visible cost of a spaghetti tech stack is the maintenance burden. Engineering teams in organisations with high architectural debt spend a disproportionate share of their capacity on reactive work - fixing broken integrations, resolving data discrepancies, responding to incidents triggered by changes in one system propagating unexpectedly to others. This cost is real but at least partially legible: it shows up in ticket queues and sprint retrospectives and it creates visible pressure on delivery capacity.

The less visible costs are more damaging precisely because they are harder to quantify and easier to defer.

The governance cost is structural opacity. When the integration topology of a technology estate is not documented, owned, or periodically reviewed, leadership loses the ability to make reliable architectural decisions. Every proposal to change, replace, or extend any part of the stack requires a discovery exercise - mapping what the proposed change would affect, which downstream systems depend on it, what failure modes the transition might introduce. In organisations with clean architecture, this is a short exercise. In organisations with spaghetti stacks, it is often weeks of archaeology that produces a map that nobody is confident is complete. The cost of this opacity is not just the time spent on discovery. It is the decisions not taken because the cost and risk of change appear too high - the architectural conservatism that gradually narrows strategic options.

The operational risk is compounding fragility. Spaghetti stacks are not uniformly fragile - they are unevenly fragile in ways that are difficult to predict from the outside. A seemingly minor integration between two peripheral systems may turn out to be load-bearing: the single source of truth for a data field that half a dozen downstream processes depend on, built by an engineer who has since left, documented nowhere and vulnerable to any change in either connected system. These hidden load-bearing connections are discovered not through audit but through incident. And the incidents, when they occur, have a way of arriving at the worst possible moment - during an acquisition due diligence, in the middle of a peak trading period, or precisely when the organisation is trying to demonstrate operational maturity to investors.

The data quality cost is the one that most directly affects business decisions. In an estate where the same entity - a customer, an order, a product - is represented in multiple systems that are not reliably synchronised, data quality degrades predictably. The finance system says one number; the CRM says another; the data warehouse, built to reconcile them, says a third. Teams learn to distrust automated reports and fall back on manually compiled spreadsheets, which introduces human error at the point where it is least visible. Decisions get made on data that is approximately right, with informal adjustments applied by whoever is closest to the underlying reality. This is not a data strategy failure. It is an architectural failure manifesting as a data governance problem.

Diagnosing the Stack: The Coherence Assessment

Before any rationalisation work can be meaningfully planned, the organisation needs an honest assessment of what it is actually managing. I call this a coherence assessment - a structured investigation not into what the estate contains, but into how coherently the parts relate to each other.

A coherence assessment has four dimensions. The first is the dependency map: a complete picture of every active integration between systems, including the mechanism of connection, the data flowing through it, the frequency of exchange and the named owner. This is almost always harder to produce than expected, because in most organisations with architectural debt, the integration estate is partially documented in configuration systems, partially in developer memory and partially in no record at all. The exercise of producing the map is itself diagnostic - the integrations that cannot be mapped without significant archaeological effort are the ones most likely to be creating hidden risk.

The second dimension is the ownership audit: for every system and every integration in the estate, is there a named team or individual who is accountable for its health, its evolution and its eventual decommissioning? Systems and integrations without owners are orphans. They tend to be the ones nobody is maintaining proactively, nobody is monitoring consistently and nobody will notice is degrading until it fails completely.

The third dimension is the data authority map: for every data entity that matters to the business - customer, order, product, contract, transaction - which system is the authoritative source and how does that authority propagate to other systems that also hold versions of the same data? In clean architecture, data authority is intentional and explicit. In spaghetti stacks, it is often contested, ambiguous, or undefined - producing the data quality dysfunction described earlier.

The fourth dimension is the change exposure analysis: given the current integration topology, what are the highest-risk points of change? If vendor A updates its API, how many downstream integrations are affected and how quickly would the organisation know? If system B were to be decommissioned, what would break and what would be the remediation path? This analysis is not primarily about current risk. It is about understanding the architectural constraints that the current stack imposes on future decisions.

Together, these four dimensions produce a coherence profile - a structured view of where the estate is well-governed and where it is not, which is the prerequisite for any meaningful rationalisation strategy.

The Rationalisation Framework: CORE

When rationalisation decisions need to be made - which tools to keep, which to retire, which to replace - the instinct is often to evaluate tools on their individual merits: capability, cost, vendor stability, user satisfaction. These factors matter, but they are insufficient as a basis for architectural decisions, because they evaluate components in isolation rather than as parts of a system.

I use a framework I call CORE - Criticality, Ownership, Replaceability, Ecosystem fit - as a structured basis for rationalisation decisions. Each dimension captures a different aspect of how a tool functions within the architecture, rather than how it performs as an isolated product.

Criticality is the degree to which the tool is load-bearing - not just useful, but structurally necessary for core business processes to function. A tool can be widely used but not critical: if it disappeared tomorrow, workflows would be disrupted but not broken. A tool can be narrowly used but highly critical: if it disappeared, a specific process that everything else depends on would fail. Criticality drives protection decisions - which tools warrant investment in resilience, redundancy and documented failover - rather than procurement decisions.

Ownership is whether the tool has clear, active governance: a named owner, documented integration points, an established change management process and a lifecycle plan. Unowned tools - tools that are running, paid for and depended upon, but that nobody is actively responsible for - are the primary source of hidden architectural risk. The rationalisation question for unowned tools is not whether to keep them but whether the organisation is prepared to establish genuine ownership; if not, the tool should be scheduled for replacement with something that will be owned.

Replaceability is the architectural cost of switching - not the functional difficulty of finding an alternative, but the integration cost of unpicking the current tool from the estate and reconnecting its replacement. Highly embedded tools with many integration points and poorly documented connection logic are expensive to replace regardless of how commoditised their functionality has become. Understanding replaceability is essential for realistic prioritisation: the tools that are most frustrating to use are not always the right starting point for rationalisation if they are also the most expensive to replace.

Ecosystem fit is the degree to which the tool integrates naturally with the core platform strategy - whether it supports standard integration patterns (REST APIs, webhooks, standard authentication), participates in the organisation’s chosen data flow architecture and aligns with the direction the stack is evolving. Tools with poor ecosystem fit create architectural drag: they require bespoke integration work, resist standardisation and tend to generate disproportionate maintenance overhead relative to their functional value.

Applying CORE across the estate produces a structured view of where rationalisation effort is most warranted: tools with low criticality, unclear ownership, poor replaceability assessment and weak ecosystem fit are the highest-priority candidates for replacement. Tools with high criticality and clear ownership that score poorly on replaceability may need architectural investment - better integration documentation, more resilient connection design - rather than replacement.

Building Intentional Architecture: The Three Layers

Rationalisation addresses the existing estate. The more important challenge is architectural intentionality going forward - building a stack that is coherent by design rather than by accident.

Intentional stack architecture requires clarity about three distinct layers: the system of record layer, the integration layer and the workflow layer. Most spaghetti stacks suffer from the absence of this distinction - tools perform functions across multiple layers without it being clear which layer they belong to and the result is a topology without structure.

The system of record layer is where authoritative data lives. Every business-critical data entity has one system of record: the single source of truth to which all other systems defer. CRM is the authoritative record for customers and opportunities. ERP or accounting software is the authoritative record for financial transactions. HRIS is the authoritative record for employees. These designations need to be explicit, documented and enforced through integration design - data should flow from systems of record to dependent systems, not be maintained independently in multiple places.

The integration layer is the connective tissue - the mechanisms through which data flows between systems of record and the tools that consume or contribute to that data. The critical architectural decision at this layer is whether to manage a topology of bilateral point-to-point connections, or to invest in integration infrastructure - an iPaaS, an event bus, an API gateway - that provides a managed, observable and governable connection layer. For organisations with more than fifteen to twenty active integrations, the integration infrastructure model typically becomes more efficient to maintain, because it constrains the failure surface and enables consistent monitoring and documentation practices. Below that threshold, well-governed bilateral connections may be adequate if ownership and documentation disciplines are applied consistently.

The workflow layer is where business processes execute - the automation tools, AI agents, dashboards and collaborative applications that orchestrate work across systems of record. This layer should be treated as a consumer of the integration layer, not a builder of its own connections. The mistake many organisations make is allowing workflow tools - process automation platforms, no-code builders, reporting tools - to develop direct, undocumented integrations with systems of record, effectively bypassing the integration governance that the middle layer is meant to provide. When this happens, the workflow layer begins to reproduce the spaghetti pattern and the integration infrastructure investment is undermined.

Maintaining clarity across these three layers is not a one-time architectural decision. It is an ongoing governance discipline - the practice of evaluating every proposed new tool, integration, or automation against the architectural model and resisting the organisational pressure to make expedient exceptions.

Common Mistakes When Trying to Fix It

The most costly mistake in stack rationalisation is the big bang migration - the attempt to solve an architectural accumulation problem through a single, comprehensive replacement programme. The appeal is understandable: if the spaghetti is the problem, replace everything with a clean, integrated platform and start fresh. In practice, big bang migrations have a structural failure mode that is almost universal. The programme is scoped in a moment of architectural optimism, before the full complexity of the existing estate is understood. As the project proceeds, the complexity of untangling the old estate and rebuilding its functionality in the new one consistently exceeds initial estimates. Timescales slip, costs escalate and the organisation ends up running parallel stacks - the old estate that operational teams are reluctant to abandon and the new platform that is perpetually six months from being fully ready. By the time the migration is complete, or more often by the time the programme is quietly scaled back to something deliverable, the architectural principles that motivated it have been compromised by the practical pressure to keep things running.

The alternative is incremental rationalisation, guided by the coherence assessment and CORE analysis: identify the highest-risk, lowest-ownership, lowest-ecosystem-fit components of the estate; build a replacement sequence that addresses them in order of priority; and establish the integration and governance infrastructure before - not after - migrating the data and workflows that depend on it. This approach is slower in headline terms but faster in practice, because it does not carry the catastrophic risk of a failed big bang and because each completed step improves the architectural foundation on which the next step builds.

The second common mistake is tool proliferation as a rationalisation strategy - adding new integration or orchestration tools to manage the complexity of existing tools, without addressing the underlying architectural dysfunction. An iPaaS platform deployed on top of a poorly governed estate does not fix the governance problem; it adds another layer to the spaghetti and creates the illusion of control without the substance of it. Integration infrastructure is only as effective as the governance practices that operate it. Without those practices, the platform becomes another undermanaged component in an estate that already has too many of them.

The third mistake is treating rationalisation as a project rather than a practice. Stack architecture degrades continuously because the organisational dynamics that produced the original accumulation do not change unless they are explicitly addressed. Completing a rationalisation programme and then reverting to the previous procurement and governance patterns will produce the same result on a predictable timeline. The structural governance changes - the integration cost accounting, the ownership requirements, the review cycles - are not the output of the rationalisation project. They are the mechanism by which the project’s outcomes are sustained.

The Governance Model for Ongoing SaaS Decisions

Sustainable stack architecture requires a governance model that is simple enough to operate without dedicated overhead, robust enough to prevent the accumulation dynamic from reasserting itself and authoritative enough that exceptions genuinely require justification rather than just approval.

The governance model I have found most effective in practice has three components: a procurement gate, an ownership requirement and an integration review cycle.

The procurement gate is a lightweight evaluation process applied to every proposed new tool before adoption. It does not need to be bureaucratic. It needs to answer five questions: What problem is this solving and is that problem not already addressed by something in the current estate? What is the integration cost - initial build and ongoing maintenance - and which team owns it? What is the data authority model - does this tool create, consume, or duplicate data that already exists in a system of record? What is the exit strategy if the tool needs to be replaced? And does this tool align with the integration layer architecture, or does it require a bespoke connection? These questions do not prevent adoption. They prevent adoption without acknowledgement of the obligations it creates.

The ownership requirement is the rule that no tool or integration goes live without a named owner who accepts accountability for its ongoing health. Ownership is not a role - it is a commitment by a team to include the tool or integration in their operational remit, to monitor it proactively, to respond to incidents involving it and to plan for its evolution or decommissioning as part of their regular work. This requirement is easy to apply to new additions. It is more difficult and more important, to retroactively establish ownership for the orphaned components of the existing estate. An amnesty process - a defined period during which teams are invited to accept ownership of unowned components, with the understanding that unowned components after a certain date will be scheduled for decommissioning - is often the most effective mechanism for closing the orphan gap.

The integration review cycle is a scheduled, periodic assessment of the integration estate - ideally quarterly - that asks three questions about every active integration: Is it still necessary? Is it operating within acceptable parameters? Is its documentation current and its ownership confirmed? Integrations that fail the first question are immediately scheduled for decommissioning. Integrations that fail the second are escalated to engineering as a prioritised remediation item. Integrations that fail the third are treated as governance actions before anything else proceeds. The review cycle is not an audit. It is a maintenance practice - the organisational equivalent of code review applied to the integration estate as a whole.

Together, these three components do not require a dedicated architecture team or a significant ongoing investment. They require a consistent cultural commitment to treating the integration estate as a managed asset rather than an emergent phenomenon.

The Strategic Reflection

There is a question behind all of this that does not often get asked at the right level of the organisation: what does the state of your technology estate say about the quality of your governance?

A spaghetti tech stack is not primarily evidence of poor vendor selection or inadequate engineering. It is evidence of a governance model that allowed consequential decisions - decisions that accumulate architectural obligation over years - to be made without adequate visibility of their full implications. The accumulated dysfunction is the sum of thousands of individually rational, locally optimised decisions made without a systems view.

The organisations that maintain coherent stack architecture over time are not the ones with the best tools. They are the ones where the decision architecture for technology adoption is mature enough to make the long-term costs of each decision visible at the point of decision, where ownership of the consequences is clear and accepted and where the review mechanisms exist to catch drift before it compounds into crisis.

That is a governance question before it is an architecture question. And governance questions are always, ultimately, leadership questions. The CTO who can articulate not just what the organisation’s stack contains but how it is governed - who owns what, what the architectural principles are and how decisions are made and reviewed - is demonstrating something more valuable than technical knowledge. They are demonstrating that the organisation has the structural clarity to make its technology estate a strategic asset rather than a compounding liability.

A clean tech stack is not the goal. An understood, owned and governable one is. The difference between those two things is the difference between a one-time project and a sustained organisational capability.

Then it flags the wrong company. A name collision in the CRM, a misclassified entity type, a scoring model that weighted price over compliance posture — the exact cause is unclear, and that ambiguity is itself part of the problem. The preferred supplier turns out to be a shell entity linked to a sanctioned entity in a secondary jurisdiction. The procurement manager, under time pressure, signs off without scrutiny. The contract proceeds. Legal eventually catches it during a routine audit six weeks later.

Who was accountable? The agent, which had no concept of accountability? The operations team that deployed it, operating within a mandate from IT? The IT function that configured the tool, working from a brief from the business? The executive who approved the automation programme without asking what guard-rails were in place? Or the vendor who sold a capability without documenting its failure modes?

In most organisations today, the honest answer is that nobody was accountable — because nobody had defined what accountability meant in an environment where a non-human system was executing judgement-adjacent tasks. That gap is not a technology problem. It is a governance problem. And it is becoming one of the most consequential structural risks in enterprise AI adoption.

The Speed-Accountability

The commercial case for AI agents rests almost entirely on speed. They operate continuously, without fatigue, across time zones, at a cadence that no human workforce can match. A customer service agent can handle thousands of interactions simultaneously. A data classification agent can process millions of records overnight. A compliance monitoring agent can scan every transaction in real time, flagging anomalies before a human reviewer would have opened their inbox.

This speed is real and, in the right contexts, genuinely valuable. But it creates a structural tension that organisations are consistently failing to address: the speed at which agents act is fundamentally incompatible with the speed at which humans can review, reflect, and intervene.

Governance frameworks are built on the assumption of legible, reviewable decision chains. A human makes a call, a manager reviews it, an audit trail documents it. This model assumes that the rate of consequential decisions is low enough that oversight is feasible. When you introduce agents, that assumption collapses. An agent can execute hundreds of decisions per minute. The governance infrastructure that would be adequate for a human analyst becomes structurally irrelevant for a system operating at machine speed.

What organisations actually need — and what most are not building — is a fundamentally different model: one in which governance operates prospectively (before the agent acts) rather than retrospectively (after the damage is done). This means defining with precision, before deployment, what the agent can do, what it cannot do, and what it must pause and check before proceeding. It means configuring the system to enforce those limits, not merely to record them. And it means accepting that the speed advantage of an agent is only sustainable if the governance structure surrounding it is designed to match the speed at which things can go wrong.

The Chain-of-Responsibility Problem

When a human employee makes a bad decision, there is a well-established, if imperfect, accountability chain. Employment law, professional liability, management hierarchy, and organisational culture all contribute to a structure in which consequences attach to people. The chain may be contested, the attribution may be argued, but the framework exists.

When an AI agent makes a bad decision, none of that framework maps cleanly. The agent has no legal personality. It cannot be reprimanded, disciplined, or held to account. The liability must flow somewhere — but where it flows depends on a set of governance choices that most organisations have not yet made.

There are four candidate accountability points, and each has genuine merit: the deploying organisation, which made the strategic decision to use an agent for this class of task; the team or individual who configured and deployed the agent instance; the vendor who built the underlying system, including its failure modes; and the executive or governance body that approved the deployment without establishing accountability norms.

In the absence of a deliberate governance structure, accountability tends to diffuse across all four — which in practice means it attaches to none of them with sufficient force to drive learning or remediation. The organisation runs a post-mortem, identifies several contributing factors, and distributes responsibility broadly enough that no single owner has the mandate or the incentive to change the system.

The practical consequence of this diffusion is not just that individual incidents go unaddressed. It is that the feedback loop that would normally improve decision quality over time is severed. Human decision-makers learn from consequences. Organisations that assign clear accountability improve over iterations. When accountability is diffuse, improvement is structural, which means it is slow, inconsistent, and easily crowded out by the next operational priority.

Task Delegation Is Not Authority Delegation

There is a distinction that sits at the heart of effective AI agent governance, and it is one that technical and operational teams consistently collapse: the difference between delegating a task and delegating authority.

When an organisation deploys an AI agent to handle vendor outreach, it is delegating a task. The task is: contact these candidates, request these documents, score them against these criteria. That delegation is bounded, specific, and in principle, reversible. A human could review any output at any point and override it without systemic consequence.

Authority delegation is categorically different. Authority means the right to make binding decisions that commit the organisation — to select a vendor, to send an offer, to reject an applicant, to approve a transaction. Authority carries legal and reputational weight. It is not something that can be casually extended to a system that has no legal standing and no capacity for contextual judgement.

Most organisations deploying AI agents today are performing task delegation in their governance documentation and authority delegation in practice. The agent is framed as an assistant or copilot — language that implies task support. But the operational reality is that its outputs flow directly into consequential decisions without meaningful human review, because the review process would destroy the speed advantage that justified the deployment in the first place.

This gap between governance documentation and operational reality is not unusual. It is, in fact, the expected outcome when governance is designed to satisfy compliance requirements rather than to reflect how the system actually functions. The solution is not to slow the agents down — it is to be honest about what authority the agent is exercising, and to build governance structures that are appropriate to that level of authority, not to the level of authority the documentation describes.

A Four-Layer Governance Framework for AI Agent Deployment

Governance for AI agents does not require a new vocabulary. It requires a clear-eyed application of existing governance principles to a new operational context. The following framework identifies four layers that, together, provide the structural foundation for sustainable agent deployment.

Policy Layer: What the Agent Can and Cannot Do

The policy layer is the foundational constraint set. It defines, explicitly and in writing, the boundaries within which any given agent operates: the tasks it is authorised to execute, the data it is permitted to access, the decisions it is permitted to surface, and the actions it is explicitly prohibited from taking without human review. This is not a technical configuration document. It is a governance document, owned at senior level, reviewed on a defined schedule, and updated whenever the agent’s operating context changes.

Most organisations have something that resembles this — a brief, a requirements document, a configuration checklist. What they rarely have is a document that explicitly lists prohibited actions, documents the reasoning behind each constraint, and is reviewed by someone with governance authority rather than technical authority. That specificity matters because it is the difference between a policy that provides real guardrails and one that simply records intent.

Oversight Layer: Who Monitors in Real Time

The oversight layer addresses a question that sounds simple but is operationally complex: who is watching the agent, and what are they watching for? Oversight is not passive logging. It is active monitoring against defined behavioural expectations, with clear escalation paths when those expectations are breached.

Effective oversight requires first defining what normal looks like for a given agent — its expected output range, its typical decision distribution, its standard error rate. It then requires building monitoring tools that detect deviation from that baseline, and assigning a human role — not a team, but a named role with a specific mandate — to receive, assess, and act on those deviations. In high-frequency agent environments, this will necessarily involve automated monitoring; the oversight layer cannot itself require human review of every agent output. But it must ensure that anomalies reach human attention quickly enough to be actionable.

Accountability Layer: Who Owns the Outcomes

The accountability layer answers the chain-of-responsibility question before it becomes a post-incident dispute. For each agent deployment, there must be a named accountable owner — an individual with sufficient authority and visibility to be genuinely responsible for the agent’s conduct and its consequences. This owner is not the developer who built the integration, nor the analyst who maintains the configuration. They are a senior decision-maker who understands the agent’s scope, approves its policy layer, and accepts that their name is attached to its outcomes.

This level of accountability changes the dynamic of agent deployment substantially. When an accountable owner knows that their professional reputation is linked to an agent’s conduct, they have a direct incentive to ensure the policy layer is realistic, the oversight layer is functional, and the audit layer is complete. Diffuse accountability produces diffuse incentives. Named accountability produces named attention.

Audit Layer: What Gets Recorded and Why

The audit layer is the institutional memory of agent governance. Every consequential decision made by or through an agent should be recorded in a form that supports retrospective review: what the agent did, what data it acted on, what policy it was operating under at the time, and what human review (if any) was applied before the action was taken.

Audit is not primarily a compliance function, though it serves compliance. Its primary value is operational learning. Without a complete audit trail, organisations cannot determine whether their agents are performing within expected parameters, cannot identify systematic biases in agent decision-making, and cannot reconstruct decision chains when things go wrong. The audit layer is what makes governance iterative rather than static — it is how policy constraints get refined, oversight thresholds get calibrated, and accountability decisions get revisited.

What Senior Leaders Must Decide Before Deployment

There are five questions that no agent deployment should proceed without answering at the senior leadership level. They are not technical questions. They are governance questions, and they require governance answers.

What is the precise scope of this agent’s authority, and where does task execution end and decision-making begin? This question forces the delegation distinction into the open, where it belongs.

What are the escalation triggers — the specific conditions under which the agent must pause and seek human review before proceeding? These must be defined in advance, not inferred after the first incident.

What is the human-in-the-loop threshold for this deployment, and does that threshold reflect the actual risk profile of the tasks the agent is executing? An agent handling low-stakes internal queries requires different oversight than one operating in a procurement, compliance, or customer-facing context.

Who is the named accountable owner, and do they have the authority and visibility to exercise that accountability meaningfully? Accountability assigned to someone without authority or access is accountability in name only.

What are the failure modes, and what happens to the organisation’s operations if the agent acts outside its intended scope? The failure mode question should be answered before deployment, not during incident response.

The Regulatory Horizon: What the EU AI Act Signals

The EU AI Act, which entered into force in August 2024 and is being applied in stages through 2026 and 2027, represents the most significant regulatory intervention in AI governance to date. Its relevance for agent governance is not primarily about the specific obligations it imposes — those are specific to risk categories and will evolve through secondary legislation. Its relevance is in what it signals about the direction of regulatory expectation.

The Act introduces the concept of the AI system operator as a distinct accountability category, with specific obligations around risk assessment, conformity documentation, human oversight, and incident reporting. For organisations deploying AI agents at scale, this framing has direct implications: the organisation that deploys an agent is the operator, and the operator bears accountability obligations that cannot be contractually transferred to the technology vendor.

The Act’s requirement for human oversight in high-risk AI applications is not a technical requirement — it does not specify how oversight must be implemented. It is a governance requirement. It establishes that oversight must be real, documented, and demonstrably effective. Organisations that satisfy this requirement with a nominal review step, or that document oversight mechanisms that are not actually observed in practice, are not compliant. They are exposed.

Beyond compliance, the Act signals a broader regulatory direction: that autonomous systems operating in consequential contexts will be subject to increasing scrutiny, that accountability will be expected to attach to identifiable human actors, and that governance documentation will need to reflect operational reality rather than idealistic intent. The organisations that build genuine governance infrastructure now are not over-investing in compliance. They are positioning for an environment in which governance capability will be a prerequisite for continued deployment, not an optional enhancement.

Governance Is Not a Constraint. It Is the Condition for Scale.

There is a persistent framing in conversations about AI governance that positions oversight as a drag on deployment — a necessary bureaucratic cost that slows the speed advantage that makes agents valuable in the first place. This framing is both common and wrong.

Governance is not the enemy of agent scale. It is the precondition for it. Organisations that deploy agents without governance structures are not moving faster. They are accumulating risk at the speed of deployment, and they are doing so invisibly, which is the most dangerous kind of accumulation. The speed advantage is real, but it is not durable if the foundation is ungoverned. Every incident that a poorly governed agent produces — every wrong call, every misclassified record, every unauthorised action — creates remediation cost, reputational exposure, and in regulated environments, legal liability. The aggregate cost of those incidents will eventually exceed the aggregate efficiency gain that justified the deployment.

The organisations that will sustain AI agent deployment at scale are not the ones that deployed fastest. They are the ones that built governance infrastructure that was proportionate to the authority being delegated, honest about the failure modes, and clear about where human judgement remains irreplaceable. Speed without accountability is not a competitive advantage. It is a liability that has not yet been called.

The decision to deploy an AI agent is, at its core, a governance decision. It is a decision about what authority to extend, to what kind of system, under what constraints, with what accountability. Organisations that treat it as a technology decision are answering the wrong question. The more important question is not what the agent can do. It is who decided what the agent is allowed to do — and who will be responsible when the answer turns out to have been incomplete.

Gustavo De Felice is a senior digital project leader and systems architect with over 1,200 managed projects across enterprise technology transformation.*

The project delivered twelve weeks late. The final root-cause analysis attributed most of the overrun to integration failures at vendor boundaries, not to any vendor’s individual performance.

This is the most consistent pattern in complex outsourced programmes: the failure does not sit inside any workstream — it sits between them. And the space between workstreams is exactly where governance attention is least concentrated, because every governance structure in project management is designed around entities — teams, vendors, systems — rather than relationships, interfaces, and dependencies.

Managing third-party dependencies well requires a different mental model than managing internal teams. The assumptions that underpin internal delivery — shared context, aligned incentives, informal escalation, cultural coherence — do not transfer. What replaces them must be designed explicitly, or the dependency becomes a liability the moment conditions deviate from plan.

The Dependency Illusion

The core problem with third-party dependencies is that they are systematically underestimated at the point when the decision to create them is made. This is not irrational behaviour — it reflects how outsourcing decisions are evaluated. The evaluation focuses on capability, cost, and contractual scope. It rarely focuses on dependency depth: how extensively the vendor’s output is embedded in the delivery path of the broader programme, how many decisions downstream of the vendor’s work will be constrained by choices made upstream of it, and how much of the project’s operational risk is transferred to a party the client cannot directly manage.

Dependency depth is a structural characteristic that is almost never modelled at contract stage. A vendor delivering a standalone component with a clean interface and no downstream sequencing is a very different dependency from a vendor delivering a foundational data model that every other workstream builds on. The contract may be the same size and scope. The governance burden is radically different. Treating them equivalently, because the procurement model encourages scope comparison rather than dependency analysis, is how leadership teams arrive at month five with three simultaneous coordination crises.

The dependency illusion is compounded by a common framing error: once a contract is signed, the risk is considered managed. The due diligence is done. The terms are set. The vendor is accountable. This framing mistakes legal accountability for operational control. A vendor can be contractually liable for late delivery while simultaneously creating conditions that make late delivery inevitable, because the governance structure does not detect problems at the point when intervention is still cheap.

Where Third-Party Programmes Actually Fail

The failure patterns are consistent enough across industry, project type, and vendor category that they can be characterized precisely.

Interface Ownership Voids

Every dependency creates an interface: a point at which one party’s output becomes another party’s input. Interfaces are rarely governed with the same precision as workstreams. Contracts define scope boundaries — what each vendor delivers — but frequently fail to define the quality and format of the artefact at the boundary, the process by which boundary disputes are identified and resolved, and who owns the governance of the boundary itself. When the data format delivered by the migration vendor does not precisely match what the integration vendor was expecting, neither party accepts that the problem is theirs. Both are technically correct. The gap is an orphan — it belongs to the programme management layer, which is often the least resourced part of a multi-vendor structure.

Interface ownership voids proliferate in proportion to the number of vendors. With two vendors, there is one interface. With four vendors, there are up to six. With six vendors and complex sequencing, the combinatorial expansion of potential interfaces rapidly exceeds what informal coordination can manage. Mapping, assigning, and governing interfaces explicitly is the minimum viable response to dependency complexity.

Contractual Scope as an Escalation Barrier

Vendors have an incentive to interpret their contractual scope conservatively when problems arise. This is rational behaviour: scope creep, from a vendor’s perspective, is a commercial risk. When a project encounters an unanticipated situation — a technology decision that creates ambiguity in the integration boundary, a regulatory requirement that emerged after contracting — the vendor’s first response is typically to evaluate whether resolving the situation falls within their contracted scope. If it does not, they will escalate a variation request. The escalation and approval cycle creates delay. In a sequenced programme, the delay at one workstream compounds into delay across all downstream workstreams.

This is not vendor intransigence. It is the expected behaviour of any commercially rational party operating under fixed-price scope constraints. The governance response is not to wish for more cooperative vendors. It is to design the commercial structure to minimize the frequency of scope boundary encounters, and to establish rapid-resolution mechanisms for the ones that occur despite good design.

Progress Measurement Asymmetry

Clients typically measure progress against the reporting cadence they negotiate at contract stage: monthly status reports, RAG updates, milestone sign-offs. This is fine for stable workstreams. It is inadequate for detecting the early-stage problems that create delivery failures in complex dependencies. A vendor reporting green at the end of month three may be carrying a technical decision that will surface as a critical blocker in month five, but which would be visible and resolvable if the governance structure provided sufficient operational transparency to identify it.

The asymmetry is structural. The client is managing the programme from the outside; the vendor has the operational view. Bridging this requires more than a better reporting template. It requires access to the vendor’s working-level activity at a frequency and granularity that most contractual relationships do not accommodate, and which many vendors actively resist as intrusive. The governance design has to create this access by negotiating for it explicitly, not assuming it will emerge from good intentions on both sides.

Single Points of Failure in Vendor Relationships

Key person dependency in vendor delivery teams is underestimated consistently. A vendor organisation may have strong capability at the practice level; the individual assigned to deliver on a specific contract may be considerably more variable. The consultant leading the integration workstream may be the person who holds six months of context, all the stakeholder relationships, and the informal knowledge of how the system actually behaves. When they move to another engagement — a routine occurrence in consulting organisations managing multiple client relationships — the impact on the programme is sudden and significant.

Clients who have experienced this once generally respond by negotiating notice periods and knowledge transfer obligations. These are necessary but insufficient. The deeper governance response is to design the working relationship so that programme-critical knowledge is captured in shared artefacts and maintained in client-accessible repositories, rather than carried in the heads of vendor individuals. This is harder to achieve than to describe: vendors often resist it as competitive sensitivity, and the disciplines required to maintain quality documentation are frequently sacrificed to delivery pressure. But the programmes that manage vendor single-point-of-failure risk well are the ones that treat documentation as a governance obligation rather than a delivery overhead.

Governance Principles for Third-Party Dependencies

The principles that make a dependency manageable are not primarily contractual. They are structural — built into how the programme is organised, how information flows, and how decisions are made.

Explicit Dependency Mapping as a Governance Artefact

Before a programme launches, every dependency between workstreams — including dependencies involving vendors — should be mapped explicitly: what does each party need from each other party, when do they need it, in what format, and who resolves it if the need is not met on time and in the required form. This map is a governance artefact that should be maintained and reviewed at every major milestone.

Dependency maps sound straightforward. In practice, creating one with genuine precision is a forcing function that surfaces planning gaps before they become delivery problems. It reveals interface ownership voids, identifies single-path dependencies that create programme-level risk, and generates the questions that contract terms need to answer rather than the questions that contracts typically do answer.

The map also creates a shared reference that all parties — including vendors — can use to understand how their work connects to others. This is culturally significant: it makes the integration of workstreams visible in a way that encourages the people delivering each workstream to think about their interfaces, not just their own outputs.

Risk-Adjusted Contractual Architecture

Contract design for complex programmes needs to match the dependency profile of the engagement. A vendor delivering an isolated component with minimal interface complexity warrants a different contractual structure than a vendor whose output feeds three downstream workstreams and whose schedule is on the critical path.

For high-dependency vendors, the contractual structure should include: milestone-based payment tied to specific integration outcomes rather than generic deliverables, explicit process obligations for early-warning disclosure when the vendor identifies risks that may affect the programme, variation resolution mechanisms with defined response timescales, and governance access rights — specifically, the client’s right to observe working-level delivery activity at defined intervals. These provisions are standard in sophisticated programme management but are routinely omitted from vendor contracts that prioritise commercial simplicity over governance adequacy.

Parallel Governance Structures

Multi-vendor programmes require a governance layer specifically accountable for integration and dependency management. This is distinct from the governance of individual vendor workstreams. The integration governance function owns interface mapping, coordinates cross-vendor technical decisions, manages the boundary disputes that fall between vendor scopes, and maintains the end-to-end picture that no individual vendor has an incentive to hold.

In practice, this function is underresourced in most outsourced programmes. The assumption is that a project manager can carry it alongside workstream oversight. In programmes beyond modest complexity, this assumption fails. The integration governance role requires dedicated capacity and specific skills — the ability to read and resolve technical interface conflicts, the commercial awareness to navigate variation disputes, and the authority to make binding decisions on behalf of the client when the alternative is a cross-vendor standoff that stops delivery.

Structured Information Flow, Not Hope

Effective dependency governance depends on information that the client does not inherently have. The vendor has it. Getting it requires a structured mechanism, not a relational assumption. This means negotiating for specific access: participation in working-level technical reviews at defined intervals, access to vendor issue logs and risk registers, joint technical workshops at key milestones rather than just formal sign-off meetings.

The cadence and depth of information exchange should be calibrated to dependency depth. For a vendor on the critical path with multiple downstream dependencies, weekly working-level touchpoints are not intrusive — they are the minimum viable oversight for a client who needs early visibility of problems while they are still cheap to resolve. For a vendor delivering a standalone component with a clean handoff, monthly review is probably adequate.

The instinct in many client organisations is to avoid anything that looks like micromanagement. This instinct is generally correct for internal teams. For high-dependency external vendors on complex programmes, it conflates two different things: intrusive management of how a vendor works, which is inappropriate, and structured access to information about what a vendor is finding, which is a governance right.

Managing Concentration Risk in Outsourced Programmes

A specific failure mode deserves dedicated attention: concentration risk — the exposure created when too much of a programme’s delivery risk is concentrated in a single vendor relationship.

Concentration risk emerges in two forms. The first is scope concentration: a single vendor holds a large proportion of the delivery scope, making their commercial leverage, operational reliability, and risk profile disproportionately consequential. The second is capability concentration: a vendor holds capability that the client cannot replicate, reassign, or replace quickly if the relationship deteriorates. Both forms create vulnerabilities that go beyond what contract terms can adequately address.

The governance response to concentration risk is not simply to disaggregate scope across more vendors — that creates coordination complexity, as the opening case illustrates. It is to explicitly assess concentration risk as a programme governance concern, and to design mitigation strategies proportionate to the exposure.

For scope concentration, this typically means negotiating break clauses at meaningful intervals rather than locking into end-to-end commitments, building in programme checkpoints where the client has a formal right to reassess scope distribution, and maintaining visibility of the vendor’s delivery pipeline to identify capacity or priority conflicts early. For capability concentration, it means investing in knowledge transfer throughout the engagement rather than at the end, defining internal capability development milestones, and maintaining relationships with alternative providers even when there is no current intention to use them.

Neither form of mitigation is free. Both require investment — commercial, relational, operational — that competes with delivery pressure in the short term. The investment logic is identical to insurance: the cost is visible and certain; the risk it mitigates is contingent. Organisations that consistently underspend on dependency risk management are the ones that consistently encounter the contingency.

The Vendor Relationship Layer

Effective dependency governance requires more than structural and contractual mechanisms. It requires a vendor relationship layer — the set of interpersonal and organisational dynamics that determine whether the structural mechanisms actually work.

Contracts establish obligations. Relationships determine whether those obligations are met cooperatively or adversarially. A vendor relationship characterised by mutual understanding of objectives, open information sharing, and a shared commitment to programme success will navigate unanticipated problems — and there will always be unanticipated problems — far more effectively than a relationship characterised by contractual compliance and mutual suspicion.

This does not mean that good relationships substitute for good governance. It means that governance structures are more effective when they operate in the context of good relationships, and less effective when they operate in the context of adversarial ones. The investment in relationship quality — through regular executive-level touchpoints, honest problem-solving conversations that are not filtered through contract management, and recognition of vendor performance that goes beyond the minimum contractual requirement — pays dividends at precisely the moments when governance structures face their highest demands.

Senior leaders who treat vendor relationships as purely transactional — engaging only through contract management, escalation, and formal review — are surrendering the most flexible tool in the dependency management toolkit. The vendor’s willingness to absorb an unanticipated integration problem, to deploy senior resources at short notice, to prioritise the client’s urgent need over a competing commitment — these behaviours are commercial decisions made by human beings, and they are influenced by the quality of the relationship as much as by the terms of the contract.

A Diagnostic Framework for Dependency Risk

Before entering a significant outsourced programme or at any point where concern about third-party dependency risk is elevated, four questions provide a useful diagnostic.

First: Who owns every interface? For each point where one party’s output becomes another party’s input, is there a named owner — on the client side — who is accountable for the governance of that interface? If the answer is “it will be managed jointly,” the interface is unowned.

Second: What is the early-warning mechanism? If a vendor identifies a problem that will affect another workstream in six weeks, what is the path by which that information reaches the people who need to act on it, and how quickly? If the path is the monthly status report, the mechanism is inadequate for complex dependencies.

Third: Where is concentration risk highest? Which vendor, if they delivered late or underdelivered, would cause the most programme-level damage? Is the mitigation for that scenario proportionate to the exposure? If the answer to the second question is “hope,” the concentration risk is unmanaged.

Fourth: What do we not know? Not what has been reported — what has not been reported, and why? In every complex outsourced programme, vendors manage their information flows as well as their delivery. Understanding the structure of what you are not being told, and designing governance mechanisms to close those gaps, is the distinguishing characteristic of senior programme leadership.

Dependency Management as Strategic Competence

The organisations that manage third-party dependencies effectively treat it as a strategic competence, not an operational task. They invest in programme management capabilities specifically oriented to multi-vendor coordination. They develop commercial frameworks designed for dependency complexity rather than simple procurement. They build vendor relationship management into their leadership structure rather than leaving it to delivery-level project managers. They maintain institutional knowledge of dependency failures from past programmes and use it to shape future governance design.

This is a meaningful competitive differentiator in an environment where outsourcing is structurally embedded in how complex programmes are delivered. The question is not whether to use third-party expertise — for most organisations, the alternative is not credible. The question is whether the governance capacity to manage the dependencies that outsourcing creates is proportionate to the delivery risk it introduces.

The firm in the opening case had three capable vendors. What it lacked was a governance structure sophisticated enough to manage the space between them. That space is where the project actually lived, and where the twelve weeks were lost — not in any failure of individual performance, but in the compounding, unmanaged friction of dependencies that were treated as an operational given rather than a governance challenge.

That distinction — between outsourcing as a capability strategy and outsourcing as a liability — is made before the vendors are even selected. It is made in how the programme is designed, governed, and led from the outset.

This is the paradox of the risk register: the tool that should prevent this outcome is usually sitting in a folder proving it was created, not preventing anything. The problem is not that risk registers are a bad idea. The problem is structural — they are almost universally designed as documentation artefacts and then expected to function as management instruments. These are not the same thing, and treating them as equivalent produces exactly the outcome above: a complete record of the things that were going to go wrong, preserved in meticulous detail, long after they already had.

This article is about the gap between a register that exists and a register that works. The difference is not in the template. It is in the governance logic, the ownership model, the connection to decision-making, and — most fundamentally — the organisational culture that treats risk as a live operational signal rather than a compliance requirement to be filed and forgotten.

Why Risk Registers Fail in Practice

The failure modes are consistent enough across projects and organizations that they are worth naming precisely, because until you understand which failure mode you are actually facing, any redesign effort will address the wrong problem.

The Ownership Vacuum

The most common failure: a risk has a named owner who does not understand what ownership means in this context. Ownership of a risk entry in a register is frequently interpreted as administrative custody — keeping the row updated — rather than active accountability for the mitigation outcome. This is not a personnel failure. It is a design failure. If the register does not define what a risk owner is expected to do, when they are expected to do it, and what happens when they do not, the owner becomes a name in a column rather than a responsible agent.

Genuine risk ownership is a governance function. It means the owner has the authority to act on the risk — allocate time, escalate to leadership, block a decision if necessary — and the obligation to surface it when its status changes. Most registers do not establish this. They assign names. The distinction matters enormously in practice.

Taxonomy Chaos

Many registers collapse under the weight of inconsistent categorisation. Risks are logged at wildly different levels of abstraction: “vendor delays” sits in the same list as “the entire integration layer may need to be rebuilt if the API specification changes before go-live.” These are not the same category of thing. One is an operational contingency. The other is a strategic architecture risk. Treating them equivalently — by assigning them both a red/amber/green status and a nominal likelihood score — produces a register that is technically populated but analytically useless.

The taxonomy problem also manifests as conflation between risks (uncertain future events) and issues (problems that have already materialised), and between risks and assumptions (things we are betting on being true). All three are important to track, but they require different responses and different governance attention. Mixing them into one flat list produces noise that discourages engagement.

The Static Snapshot Problem

A risk register created at project initiation reflects the risk landscape as understood at that moment. Projects evolve. Vendor relationships change. Team structures shift. Technology decisions get revised. Regulatory requirements update. If the register is not treated as a living document — reviewed on a regular cycle, updated when conditions change, and formally reassessed at major milestones — it becomes progressively disconnected from reality. By month four, it may be describing a project that no longer resembles the one being delivered.

This is the most insidious failure mode because the register continues to look functional. It exists. It has entries. Someone dutifully adjusts a RAG status from amber to red when asked. But the underlying analysis has not been refreshed, the risks have not been requalified, and the document is providing a false sense of governance coverage while the actual risk landscape has shifted substantially.

No Decision Linkage

The deepest structural failure is that risk registers are rarely connected to the decisions they are supposed to inform. They exist in a governance silo — produced for the programme board, filed in the document repository, cited in status reports — but they are not part of the sprint review conversation, the change control process, or the steering committee discussion about whether to proceed. Risks are documented. Decisions are made. The connection between these two activities is implicit at best and nonexistent at worst.

When a risk register does not visibly inform decisions, it signals to the team that it does not matter. That signal is correct. It doesn’t matter. And once the team has learned this, the quality of the entries degrades, the update cadence slips, and the register becomes an administrative obligation rather than a management instrument. This is the terminal state of a compliance register, and it is extraordinarily difficult to recover from once it sets in.

Design Principles: What Makes a Register Feel Like a Tool

Effective risk registers are designed backwards from the question: when a decision-maker is about to make an important call, what risk information do they need, in what form, to make a better decision? That question, taken seriously, produces very different design choices than a register built to satisfy a project methodology checklist.

Calibrate the Entry Threshold Deliberately

The single most impactful design choice is deciding what qualifies for inclusion. A register that logs everything — every theoretical uncertainty, every minor dependency, every marginal assumption — becomes a cognitive burden that no one wants to engage with. A register that applies a thoughtful threshold, capturing risks that are material enough to warrant active tracking, remains readable, actionable, and credible.

A useful heuristic: if a risk would not change any decision, conversation, or resource allocation if it materialized tomorrow, it does not belong in the active register. It can sit in a parking log. But the active document should contain only things that a reasonable leader would want to discuss. This is not about being optimistic. It is about being precise.

The opposite failure — over-thinning the register to the point of uselessness — is less common but worth flagging. A register with four entries for a twelve-month, multi-vendor programme is not rigorous; it is avoidant. Granularity should match complexity.

Structure Around Impact Categories, Not Probability Scores

Probability-impact matrices are standard. They are also often counterproductive for active management. Assigning a numerical likelihood to a risk is frequently a false precision exercise that produces spurious confidence. The more useful question is: what does this risk affect, and who needs to act on it?

Structuring the register around impact categories — delivery, budget, quality, vendor dependency, compliance, architecture — makes the document immediately scannable for relevance. A project delivery lead cares about a different slice of the register than a technical architect or a finance controller. A register organized by impact type allows each reader to navigate to what is relevant to them without having to parse the full document.

Make Mitigation Actions Specific and Assigned

The minimum viable entry in a functioning risk register is not a description of a risk plus a RAG status. It is a description plus an owner plus a specific mitigation action that the owner is accountable for, with a next review date. “Monitor” is not a mitigation action. “Owner: Programme Manager” when the register has fifteen entries with the same owner is not real accountability.

Effective mitigation entries look like this: *”Validate API specification freeze date with vendor by 15 June. If freeze cannot be confirmed, escalate to architecture review board for decision on fallback integration approach.”* This is specific, time-bound, and decision-linked. It tells the owner exactly what they need to do, and it tells the steering committee exactly what question needs an answer and by when.

Risk Ownership as a Governance Function

The ownership model deserves extended treatment because it is where the most well-intentioned registers break down in execution.

Risk ownership is not the same as risk proximity. The person closest to a risk — the developer who knows the integration is fragile, the project manager who has noticed the vendor’s response times degrading — is not necessarily the right owner. They may not have the authority to act on it. Effective risk ownership requires three things simultaneously: awareness of the risk, authority to respond to it, and accountability for the outcome. In most organizational hierarchies, these three things are not concentrated in the same person at any level below senior leadership.

This creates a practical governance challenge. The owner needs to be senior enough to have authority and accountability, but engaged enough in the day-to-day to have genuine awareness. The resolution is typically a two-tier model: a named owner who holds the governance accountability and has the authority to escalate or act, and a nominated monitor at the working level who maintains operational awareness and surfaces updates. These are different roles with different obligations, and conflating them is what produces the nominal-name-in-a-column failure mode described earlier.

Escalation criteria must be pre-defined. One of the most consistent gaps in risk governance is the absence of agreed triggers for escalation. When does a risk move from monitored to escalated? When the probability increases past a threshold? When a mitigation action is overdue? When the project schedule absorbs a specific number of days of delay? Without defined triggers, escalation is discretionary, and discretionary escalation consistently under-fires. People do not like to be the bearer of bad news, particularly when the threshold for what constitutes bad news is ambiguous.

Connecting Risk to Actual Decisions

A risk register that is not connected to the decision cycle of the project is, at best, a historical record. Embedding it into the actual governance rhythm of the project is what converts it from documentation to instrument.

In practice, this means three integration points.

Sprint and phase reviews. The risk register should be a standing agenda item in every substantive review — not a full walkthrough, but a targeted scan. Are any risks in the register now affected by what we learned in this sprint? Has anything happened that should add a new entry? This takes five minutes if the register is well-maintained and zero minutes if it is not. The regularity of the touchpoint is what maintains the update discipline.

Steering committee reporting. The top three to five active risks should be summarized in every steering pack, with a specific emphasis on any risk that has changed status, any mitigation action that is overdue, and any risk that is approaching a decision threshold. This is not a passive report. The steering committee’s job, in part, is to make the decisions that only governance authority can make — funding a contingency, renegotiating a vendor contract, accepting a scope reduction. The risk summary should be formatted to prompt those decisions, not to describe the landscape in passive terms.

Change control linkage. Every formal change request should include a risk reassessment. Scope changes, budget reallocations, timeline shifts, vendor additions or removals — each of these changes the risk profile of the project. A change control process that does not update the risk register is producing governance documentation that diverges from reality at every significant decision point. Over time, this produces a register that is formally complete and practically useless.

A Diagnostic Contrast: Mature Register vs. Compliance Register

The practical difference between a functioning risk register and a compliance artefact is visible in how the document behaves over time.

A compliance register looks the same in month eight as it did in month two. The same twenty-four entries, slightly updated probability scores, a shift of one item from amber to red. The entries are generic — “resource constraints may affect delivery” — and they could apply to almost any project. Ownership is nominally assigned but practically hollow. The document’s primary audience is the PMO auditor who needs to verify it exists.

A mature register looks different at every major milestone. Risks are resolved and closed with a brief narrative of how they were resolved. New risks are added as the project evolves. Entries are specific enough to be falsifiable — it is clear when the risk has or has not materialized. The ownership model has a visible operational trail: meeting notes reference specific risk discussions, change control logs cite specific register entries, steering packs show how risk information shaped decisions. The document has an audit trail not of its own maintenance, but of its influence on the project.

The mature register is also shorter than the compliance register, not longer. This is counterintuitive to leaders who associate rigor with volume. A shorter register with higher-quality entries that are actively managed is a more functional governance tool than an exhaustive catalogue that no one can navigate. The discipline to close resolved risks and remove items that are no longer material is as important as the discipline to add new ones.

Implementation Challenges Worth Acknowledging

Building a functioning risk register in an organisation that has normalised compliance registers requires cultural re-entry as much as process redesign. The team has learned, through experience, that risk registers are for auditors. Changing that belief requires visible, consistent behaviour from leadership — and specifically, it requires leaders to visibly use the register when making decisions.

If the project sponsor references the risk register in a steering committee and asks whether a specific entry was a factor in a budget decision, the team notices. If the lead demonstrates that a change request was modified because of a risk entry, the team notices. Symbolic behavior by senior stakeholders is more powerful than any process document in shifting the cultural register around whether the tool matters.

The second implementation challenge is the initial investment in entry quality. The first pass at a meaningful risk register takes time. Writing specific, owner-assigned, decision-linked entries is harder than writing generic descriptions. That investment front-loads the effort that would otherwise be distributed across the project as unmanaged surprises. It is not additional work — it is work moved to when it is cheapest and most useful. But it requires a project environment where that investment is made deliberately, not squeezed out by the pressure to show early delivery progress.

Risk Management as Organisational Culture

The risk register is an instrument of organisational culture. A team that uses it well already treats risk as a legitimate topic of professional conversation — something to be surfaced, analyzed, and acted on rather than avoided, minimized, or managed performatively. In those environments, the register is a natural extension of how people already think about their work.

In environments where surfacing risk is culturally penalized — where saying “this might not work” is read as negativity or inadequate commitment — the register will always be a compliance exercise. It will be populated with risks that are safe to acknowledge and emptied of risks that are politically inconvenient to name. The architecture risk that no one wants to say out loud in a steering committee will not appear in the register. Neither will the vendor relationship that has deteriorated beyond what anyone wants to acknowledge formally.

This is the upstream problem. The risk register cannot solve a culture that treats bad news as disloyalty. What it can do, when designed and governed well, is create a structured, normalising context for risk conversation — a place where naming a problem is the professional expectation rather than the courageous exception. Over time, the discipline of the register shapes the culture around it, incrementally normalising risk as a management variable rather than an admission of failure.

That is the real ambition of a risk register done well. Not compliance documentation. Not an audit trail. A shared organisational capacity to see what is actually true about a project, hold it without flinching, and act on it before it acts on you.

This is not an unusual story, over the course of managing more than 1,200 technology projects, the pattern recurs with remarkable consistency: vendor risk is the category leaders feel most confident about and most frequently get wrong. The confidence is misplaced. It derives from a conflation of procurement hygiene with genuine risk assessment — a procedural check mistaken for strategic analysis.

This article is about what actually makes vendor risk dangerous, how to think about it systematically, and what a rigorous evaluation framework looks like in practice.

The Structural Problem: Vendors Are Not Static Entities

The foundational error is treating vendor selection as a one-time decision applied to a static counterparty. Vendors change. Their financial condition changes. Their leadership changes. Their product strategy changes. Their customer concentration changes. A vendor that was a credible, stable partner at contract signing may be a distressed acquisition target eighteen months later.

Technology leaders focus disproportionately on the point-in-time snapshot — the RFP response, the demo, the security audit.
What they underweight is trajectory: where is this vendor going, and does that trajectory align with where we need to go?

This matters because technology dependencies are not easily severed. When your core ERP, your data pipeline, your customer identity layer, or your deployment infrastructure is tightly coupled to a vendor, the switching cost is not just financial. It is organisational: retraining, re-integration, re-testing, re-negotiating. The asymmetry of the relationship — high cost to exit, relatively low cost to enter — is where vendors extract value and where leaders lose leverage.

The second structural problem is that vendor risk tends to be evaluated in isolation rather than in aggregate. A single vendor dependency is manageable. Five interconnected vendor dependencies, each with their own risk profiles, create a compound exposure that multiplies rather than adds. Most organisations do not have a complete map of their vendor dependency graph, which means they cannot reason clearly about systemic exposure even when they think they can.

The Four Dimensions of Vendor Risk That Actually Matter

A serious vendor risk framework does not begin with contract terms. It begins with a structured assessment across four dimensions that together determine the true exposure profile of any vendor relationship.

Strategic Alignment Risk

The most under appreciated dimension. Strategic alignment risk is the probability that the vendor’s long-term product direction diverges from your operational needs — and the cost of that divergence.

This divergence can take several forms. A vendor may be acquired, shifting product priorities to serve the acquirer’s customer base rather than yours. A vendor may pivot upmarket or downmarket, deprioritising the feature set you depend on. A vendor may enter financial distress and begin cannibalising product investment to extend runway. Or a vendor may simply make honest strategic choices — doubling down on a market segment you are not in, or deprecating a legacy module to fund a new architecture — that leave your integration stranded.

The diagnostic questions here are not about the product as it exists today. They are about the vendor’s investor base and burn rate, their recent hiring patterns (are they growing engineering or shrinking it?), their recent customer wins and losses at the segment level, and the durability of their differentiation in a competitive market. A vendor winning primarily on price in a commoditizing category is a different risk profile than one winning on proprietary capability in a defensible niche.

Operational Dependency Depth

Not all vendor dependencies are equal in their criticality or their replaceability. Operational dependency depth measures how deeply embedded the vendor is in your core workflows and how reversible that embeddedness is.

A vendor providing a peripheral analytics dashboard sits at the shallow end of this spectrum. A vendor providing the identity and access management layer for your entire product sits at the deep end. Between these extremes lie dozens of gradations, and most organizations have not done the work to map their portfolio along this spectrum.

Depth has two components: workflow criticality (what breaks if this vendor fails or changes?) and architectural lock-in (how much would it cost to replace them?). A vendor can be critically important to a workflow but architecturally replaceable — a commodity payment processor, for instance. Or a vendor can be relatively peripheral to core workflows but architecturally entrenched — a bespoke data transformation tool that has become the undocumented glue connecting multiple systems.

The governance implication is that the depth assessment should drive contract terms, integration architecture decisions, and the investment in abstraction layers. You negotiate differently — and build differently — when you understand the actual depth of a dependency.

Concentration and Single-Point-of-Failure Risk

Every technology architecture has nodes whose failure would cause disproportionate damage. Vendor concentration risk is the degree to which those critical nodes are controlled by a single counterparty.

This is distinct from the number of vendors. An organization with forty vendors but with all its compute, storage, and networking concentrated in a single cloud provider has high concentration risk despite apparent vendor diversity. An organization with ten carefully selected vendors, each covering a distinct functional domain with documented alternatives, may have low concentration risk despite a smaller portfolio.

Concentration risk compounds when vendors are interdependent. If your primary data warehouse vendor, your ETL pipeline vendor, and your business intelligence vendor all rely on the same underlying infrastructure provider, a failure or pricing change at the infrastructure level cascades through all three dependencies simultaneously. This kind of second-order concentration is rarely mapped and almost never surfaced in standard vendor assessments.

Contractual and Governance Risk

This is the dimension leaders think they have covered. Often they do not.

The gap is not typically in the presence of contract terms but in their enforceability and their completeness relative to the actual risks. SLA clauses that define uptime but not performance degradation. Data portability provisions that are technically present but practically unusable because they require formats the vendor does not natively export. Termination clauses that allow exit but not within a timeframe that prevents operational disruption.

Beyond the technical adequacy of individual clauses, there is the question of governance during the contract lifecycle. Who owns the vendor relationship on your side? Who monitors compliance? Who has standing to escalate? In many organisations, vendor governance is a procurement function that executes at contract initiation and then effectively disappears. The relationship drifts, changes accumulate unreviewed, and the organisation discovers its actual exposure only when something breaks.

The Vendor Risk Quadrant: A Working Framework

A useful organising model is to plot vendors on two axes: strategic criticality (how important is this vendor to core business operations?) and replaceability (how difficult and costly is it to replace this vendor?).

This produces four quadrants, each with a distinct governance posture.

High Criticality / Low Replaceability— These are your sovereign risks. The vendors in this quadrant have the most leverage and create the most exposure. They warrant dedicated relationship management, architectural investment in abstraction and exit planning, enhanced contractual protections, and regular strategic reviews. The goal is not to eliminate these relationships — some critical dependencies are unavoidable — but to ensure they are chosen deliberately, governed rigorously, and not entered into without clear-eyed understanding of the exposure.

High Criticality / High Replaceability — These vendors matter operationally but can be replaced if necessary. The governance focus here is on maintaining genuine replaceability: keeping integrations standardised, documenting replacement procedures, and periodically testing that alternatives are actually viable rather than theoretically available. The temptation in this quadrant is to let replaceability decay through accumulated customisation and integration debt.

Low Criticality / Low Replaceability — These are vendors that have become entrenched without being important. Often the result of legacy acquisitions or organic growth without governance oversight. The strategic goal is to rationalize: either increase standardization to restore replaceability, or phase out the dependency entirely. These vendors are invisible risks — low enough criticality that they don’t attract attention, but entrenched enough that their failure would cause disproportionate disruption relative to their apparent importance.

Low Criticality / High Replaceability — Standard vendor management applies. Periodic review, basic contractual hygiene, and no disproportionate investment in governance. This is the quadrant where most vendor management attention is concentrated, because it is the safest and most comfortable. The risk is that it consumes governance bandwidth that should be directed at the other three quadrants.

The framework is not static. Vendors move across quadrants as products evolve, architectures change, and strategic priorities shift. A quarterly review of the quadrant mapping — brief but rigorous — is more valuable than an annual comprehensive assessment.

Implementation: Where This Framework Breaks Down

No framework survives contact with organisational reality without modification. The practical challenges in implementing this approach are predictable and worth addressing directly.

The first is data availability. Assessing strategic alignment risk requires information that vendors will not voluntarily provide and that is often not publicly available. Private vendors do not disclose financials. Product roadmaps are guarded. Customer attrition data is confidential. The workaround is triangulation: conversation with peers and industry contacts, pattern analysis from job postings and product updates, and structured dialogue with vendor account teams that goes beyond the standard renewal conversation. None of this is perfect, but directional signal is enough to calibrate relative risk.

The second is organisational ownership. The quadrant framework requires someone to own it — to maintain the mapping, drive the reviews, and translate assessments into governance actions. In most technology organizations, this falls into a gap between procurement (which owns contracting), IT (which owns operations), and the business (which owns strategy). The governance failure is structural, not personal. The fix is explicit assignment of vendor relationship ownership at the appropriate level for each quadrant, with clear accountability for the review process.

The third is the politics of existing relationships. Vendors in the high criticality / low replaceability quadrant are often long-standing relationships with significant internal champions. Raising strategic alignment or concentration risk against a vendor whose implementation was championed by the CTO or a powerful business unit leader is not a comfortable conversation. The framework is only useful if it is applied with sufficient independence from the relationship dynamics it is meant to govern. This requires explicit leadership commitment to the process.

The fourth is the temptation to optimize the framework into uselessness by treating every vendor as high-risk. Risk prioritisation only works if it actually prioritizes. An organisation that applies sovereign-risk governance to forty vendors has not managed vendor risk; it has created governance theater that exhausts the organization without protecting it from anything.

The Strategic Reflection: Vendor Risk as Architecture

The deeper insight that experience in complex technology programs produces is this: vendor risk is not primarily a procurement or legal problem. It is an architecture problem.

The choices that determine vendor exposure — how tightly coupled to integrate, how much to standardise versus customise, how to structure data ownership, how to design for portability — are made by architects and engineers in the early phases of a program, often without explicit consideration of the vendor risk implications. By the time procurement is negotiating the contract, the architectural decisions that will determine the actual exposure have already been made.

This means that vendor risk governance needs to move upstream. It needs to be present in architecture reviews, in integration design decisions, in data modeling, and in the selection of infrastructure patterns. The question “how would we exit this dependency?” should be answered before the dependency is incurred, not after.

For technology leaders, the practical implication is governance integration rather than governance addition. This is not another process layered on top of existing processes. It is the introduction of vendor risk framing into decisions that are already being made — architecture reviews that are already happening, integration designs that are already being drawn, contract negotiations that are already in progress. The marginal cost of doing this well is lower than it appears. The marginal benefit, measured in avoided crises and preserved leverage, is higher than most leaders estimate until the day they find themselves in the logistics company’s position, looking at a 40% price increase on a system they cannot afford to leave.

The leaders who manage vendor risk well are not the ones who sign the best contracts. They are the ones who build architectures that preserve optionality, governance processes that maintain situational awareness, and organizational cultures where the uncomfortable question — “what happens if this vendor is not there in two years?” — is asked routinely and answered honestly.

---

*Gustavo De Felice is a governance architect and strategic advisor with experience across 1,200+ managed technology projects. He writes on project governance, systems thinking, and the operational realities of building technology organizations that last.*

---

The room nods. The instinct is correct. Something went wrong, and structure is the antidote. A working group is formed, a framework is adopted, a new layer of approval is introduced. Six months later, the organisation is slower, decisions are harder to trace, and the underlying risk — the actual source of the failure — is still present. Now it is simply better hidden.

This is the complexity trap. It is not caused by bad intentions or poor thinking. It is caused by a fundamental misdiagnosis: confusing activity with protection, and process with governance.

After more than a decade working across digital transformation programmes, SaaS implementations, and large-scale project portfolios, I have watched this pattern repeat with uncomfortable consistency. The organisations that scale well are not the ones with the most comprehensive process libraries. They are the ones that understand precisely what their processes are actually protecting against — and what those same processes are silently doing to their velocity, their culture, and their ability to make clear decisions under pressure.

The Anatomy of a Complexity Trap

A complexity trap does not arrive fully formed. It accumulates. Each individual addition — a new sign-off requirement, an additional status report, a mandatory pre-meeting before the actual meeting — seems entirely reasonable in isolation. The problem is systemic, not symptomatic.

What tends to happen is this: a process layer is introduced in response to a specific failure. That layer reduces the likelihood of that particular failure recurring. But it also introduces friction. To manage that friction, another layer is added — a coordination mechanism, a tracking tool, a governance committee. That layer creates its own ambiguity about ownership. To resolve the ambiguity, escalation paths are formalised. Those escalation paths slow decision cycles. To compensate, informal workarounds emerge. Those workarounds bypass the original control entirely.

By the end of this sequence, the organisation has more process than before the failure, less clarity about who actually decides anything, and the original risk is now being managed through an informal channel that exists precisely because the formal one became unworkable.

This is not dysfunction in the traditional sense. Every step felt rational. The complexity was built by competent people trying to do the right thing.

Why Risk Doesn’t Reduce Linearly With Process

The intuitive model is linear: more controls, less risk. The reality is far more like an inverted U. Up to a certain point, adding structure genuinely reduces exposure. Beyond that point, you begin generating a different category of risk — one that is harder to see and considerably harder to address.

The risks that emerge from over-engineered process are not the same as the risks you were originally managing. They include:

Decision latency. When every significant choice requires multiple approvals, decisions slow down. In fast-moving environments, slow decisions are not neutral — they are themselves a form of risk. Markets move. Technical dependencies shift. Vendor windows close. A decision made correctly but six weeks too late can be more damaging than a faster decision that was seventy percent right.

Accountability diffusion. Complex approval structures distribute ownership to the point where it becomes genuinely unclear who is responsible for an outcome. When five stakeholders have signed off on a decision, none of them feel fully accountable for what follows. This is not a cultural failure — it is a structural one. The process itself created the conditions for accountability to dissolve.

Risk concealment. Perhaps the most insidious effect. When teams know that surfacing a risk will trigger a complex governance response — escalations, additional reporting cycles, potential project pauses — they develop a rational incentive to manage risks quietly rather than flagging them. The formal risk register looks clean. The actual risk landscape is obscured. The first indication of a problem becomes the problem itself, rather than a signal that could have been acted upon earlier.

Cognitive overhead as a bottleneck. Every process layer requires mental bandwidth to navigate. In senior teams working across multiple programmes simultaneously, this overhead is not trivial. Time spent managing the governance apparatus is time not spent making substantive decisions. Eventually, good people begin to optimise for process compliance rather than outcome quality — not because they have given up, but because the system rewards the former.

The Framework: Distinguishing Governance From Administration

The practical challenge is that most organisations cannot easily distinguish between governance that genuinely manages risk and administration that merely generates the appearance of control. Both look similar from the outside. Both involve meetings, documents, and approvals.

The distinction I have found most useful across large-scale programmes comes down to a single question: does this process change what people do, or does it change what people record?

Genuine governance shapes behaviour. It creates clarity about who decides, what information is required to decide, and what happens when a decision turns out to be wrong. It creates feedback loops. It surfaces information that would otherwise stay buried. It makes accountability legible.

Administration, by contrast, shapes documentation. It ensures that the right forms are completed, the right meetings are attended, the right sign-offs are obtained. It creates the paper trail that demonstrates compliance with the process. But it does not fundamentally alter how decisions are made or how risks are identified.

This distinction points toward a working framework I use when auditing governance structures in scaling organisations:

The Purpose Test. For each governance mechanism — every approval gate, every status report, every committee — ask: what specific risk does this exist to manage, and how does it change behaviour in response to that risk? If the answer is unclear, or if the mechanism has drifted from its original purpose over time, that is a strong signal that you are looking at administrative overhead rather than effective governance.

The Decision Owner Test. For every category of significant decision in your programme portfolio, there should be a single identifiable person who is accountable for that decision — not a committee, not a quorum, not a working group. Committees can advise, consult, and challenge. But accountability must be individual. If you cannot name that person, your governance structure has already failed the most basic test.

The Information Flow Test. Governance exists to move relevant information to decision-makers at the right time. Map the actual flow of information in your organisation: what reaches the people who need it, when, and in what form? Where does information get filtered, delayed, or repackaged? The bottlenecks in your information flow are often more revealing than the formal governance charts.

The Worst-Case Visibility Test. The real measure of a governance structure is not how it performs when everything is on track — it is how it performs when something goes seriously wrong. Ask yourself: if a major risk emerged today, how quickly would it reach the person who needs to act on it? What would prevent it from being flagged? If the honest answer involves workarounds, informal channels, or a reluctance to trigger formal escalation, your governance structure is creating concealment risk.

Implementation Risks and Trade-offs

Applying this framework requires navigating some genuine tensions. Simplifying governance feels, to many senior stakeholders, like loosening control. That perception is a real implementation risk in its own right.

The conversation with a board or a senior leadership team about reducing process overhead is not straightforward. The language of “removing controls” triggers legitimate concern — particularly in regulated industries, publicly funded programmes, or organisations that have recently experienced a high-visibility failure. The argument needs to be reframed: the goal is not fewer controls, but more *effective* controls, and the evidence that a control is effective is that it changes what people do, not just what they document.

There is also a meaningful trade-off between standardisation and adaptability. Organisations operating across multiple projects simultaneously often standardise governance frameworks for efficiency — one approval structure, one reporting cadence, one escalation path. This works reasonably well for programmes of similar scale and risk profile. It works poorly when applied uniformly across a portfolio of genuinely different projects. A large ERP implementation has different governance needs than a rapid UX iteration cycle. Forcing both through the same framework is not consistency — it is the wrong kind of efficiency.

The calibration question is not whether to standardise, but what to standardise. The core logic of governance — who decides, what information is needed, how risk surfaces — can and should be consistent. The specific mechanisms through which that logic is implemented should be proportionate to the programme’s actual risk profile, velocity, and stakeholder complexity.

A third tension worth acknowledging: simplifying governance in an organisation that has developed workaround cultures is harder than it sounds. If teams have spent months or years navigating around formal process, those workarounds have become load-bearing. They are how actual decisions get made. Removing the formal overhead without addressing the informal structures that have replaced it can create genuine confusion about how to proceed. The governance redesign needs to be accompanied by deliberate clarity about the new decision logic — not just removed and replaced with an expectation that people will figure it out.

What Effective Governance Actually Looks Like

The organisations I have seen manage complexity well share a few consistent characteristics that are worth naming explicitly.

They treat governance as a design problem, not a compliance problem. They ask what behaviour they need to produce, and they design the lightest possible structure that reliably produces that behaviour. They revisit that design regularly — not because process is inherently bad, but because context changes and governance structures that were appropriate at one stage of growth often become obstacles at the next.

They maintain a hard distinction between programme-level governance (portfolio oversight, strategic alignment, resource allocation) and project-level execution (daily decision-making, risk surfacing, delivery management). Conflating these two levels is one of the most common sources of the complexity traps described above. Senior leadership gets involved in decisions that should be made closer to execution; execution teams wait for approvals that slow momentum without adding meaningful oversight.

They invest in information architecture rather than approval architecture. The most effective governance interventions I have seen have not been new committees or additional sign-off requirements. They have been improvements in how information reaches decision-makers — better dashboards, clearer risk registers, more honest programme reporting. The instinct to add governance is often, at root, a response to information anxiety: senior leaders do not feel they have enough visibility, so they add mechanisms to generate more reporting. The better response is to make existing information more reliable and more accessible.

And they hold the accountability question with genuine rigour. Named owners. Clear mandates. Explicit authority to make decisions without escalating for every edge case. This is uncomfortable for many organisational cultures — it means that specific people are visibly accountable when things go wrong. But it is also what makes organisations capable of learning rather than just surviving.

The Strategic Reflection

The deeper issue underneath the complexity trap is a particular relationship with uncertainty. Process proliferation is, in many cases, an attempt to reduce the felt experience of risk by increasing the felt experience of control. More approvals feel safer. More documentation feels more rigorous. More committee involvement feels more thorough.

But risk is not reduced by documentation. It is reduced by better decisions, made by people with the right information, who have clear authority to act on what they know, and who surface problems early because the system rewards honesty rather than punishing it.

The measure of a governance structure is not its comprehensiveness. It is whether the people inside it make better decisions than they would without it — and whether the people most likely to see a problem first feel genuinely equipped to flag it.

If your process is doing that, it is worth every layer. If it is not, the question is not whether to simplify. The question is how quickly you can begin.

Not because anyone was slow. Because the quote touched the sales, who needed sign-off from the Sales Manager, who was waiting on a price from a supplier nobody fully trusted — so it got double-checked, which meant the founder re-entered it by hand. Eleven days, four people, for a document the customer expected by Friday.

When we mapped it, the eleven days turned out to be the symptom, not the problem. The real problem was that no single person could see the whole path a decision travelled, so everyone added a check to cover the part they couldn’t see. Each check was rational on its own and catastrophic in aggregate. The business was busy, coherent on paper, and quietly seizing up.

He didn’t have a technology problem or a talent problem. He had a structural information problem — the kind that multiplies silently as a company grows, until the velocity of the business drops below the velocity it needs to stay competitive. AI didn’t cause that. But AI, deployed deliberately, is what eventually resolved it.

That’s the frame I want to use here. Not AI as a category of exciting capability, but AI as a diagnostic and corrective instrument for leaders who already understand that operations are fundamentally about information flow, decision quality, and execution consistency.

When the Bottleneck Is Invisible

The hardest operational problems are the ones that don’t trip an alarm. A server going down is obvious. A project running over budget is visible on a report. But the slow erosion of decision quality, the friction accumulating across a dozen processes, the widening gap between what an organisation knows and what it acts on — these announce themselves to nobody. They just raise the cost of doing business, month after month.

Most leaders I meet have some intuition that their operations are underperforming. They phrase it in their own ways: we’re always firefighting; every simple thing needs too much coordination; the data’s all there but nobody uses it; the team works hard and the output doesn’t match the effort. These are all symptoms of one thing — an information and decision architecture that hasn’t scaled with the business.

This is where AI enters, and the framing matters more than almost anything else that follows. Leaders who treat AI as a productivity tool automate individual tasks. Leaders who treat it as a systems capability redesign how their organisation thinks and decides. The gap in outcomes between those two postures is enormous, and it shows up years later when one company has shaved minutes off scattered tasks and the other has changed what it’s capable of.

I’ve worked across a lot of these projects now, and the pattern is consistent: the organisations that get durable value from AI treat it as an architectural question, not a tooling one. They don’t ask what can AI do? They ask where in our operations does the quality of information or the speed of a decision determine our competitive position? That second question leads somewhere completely different.

Why Most AI Implementations Stall at Pilot

Every week someone forwards a case study: a company used AI to cut a process from three hours to fifteen minutes. The story is usually true. It’s also usually contained — to that one process, in that one team, for that one use case. A year on, the organisation runs much as it did before. The pilot succeeded. The transformation didn’t.

I call this pilot permanence: the tendency of AI initiatives to achieve local success and systemic irrelevance at the same time. It happens because pilots are designed to demonstrate capability, not to test integration. A team runs a proof of concept, it works, everyone’s impressed. Then comes the part nobody planned for. Who owns this now? What does it change about how we work? Which adjacent processes have to change for the benefit to actually land? How do we measure the value six months from now? These questions rarely have good answers, because they weren’t asked at the design stage.

There’s a deeper issue underneath it. Most pilots are chosen for how well they demonstrate, not for how much strategic leverage they carry. Automating a report that took two hours to compile looks great in a board deck. But if that report feeds a fifteen-minute meeting where the decision gets made on instinct anyway, you’ve optimised something that was never the constraint. The constraint was decision quality. AI fixed the visible part of the workflow and left the part that mattered untouched.

Moving past pilot permanence means changing the question you evaluate against. Not can AI do this task? but if AI does this task better, does that meaningfully change the quality of decisions or the speed of execution somewhere that actually affects our position? That filter kills most of the easy wins. It also points straight at the implementations that compound.

The Operational Intelligence Framework

Over the years I’ve ended up with a reasoning model for this — I call it the Operational Intelligence Framework. It isn’t a technology architecture. It’s a way of deciding where AI builds structural advantage rather than surface efficiency.

There are three layers, and each one depends on the one below it. Skipping a layer is the most common implementation mistake I see, and the most expensive, because the failures stay invisible until they’ve already compounded.

Layer One — Signal Clarity

Before AI can improve any decision, reliable and correctly structured information has to be reaching the people and systems that need it, when they need it. Obvious in principle. In practice, most organisations are drowning in signal noise — data that’s technically captured but structurally misaligned with the decisions it’s meant to inform.

The work here is unglamorous: map what information each class of decision actually requires, then check whether that information is available at decision time in a usable form. You almost always find three failure modes tangled together. Information that exists but never surfaces, because it lives in a system nobody opens. Information that surfaces but can’t be trusted, because it’s stale or methodologically inconsistent. And information that was simply never captured — institutional knowledge about a process that nobody codified.

AI helps with all of this — NLP for unstructured data, automated reconciliation, anomaly detection on operational streams — but it can’t substitute for the upstream design work. Feed poorly defined signals into an AI system and the outputs will be confidently wrong. This is the layer where organisations underinvest the most, because they’re impatient to reach the interesting use cases and they treat data infrastructure as a precondition to rush through rather than a design task to get right. The result is AI that’s technically functional and operationally unreliable.

Layer Two — Process Anchoring

Once signal quality holds up, the question becomes where AI belongs in a process, and under what conditions. Process anchoring is the discipline of deciding which steps want AI assistance, which want AI replacement, and which should stay human — and then designing the handoffs between them on purpose rather than by accident.

The reflex is to automate everything possible. The reflex is usually wrong, because the value of AI across a process isn’t evenly distributed. High-volume, low-variance steps — document classification, data extraction, status updates, routine queries — are strong candidates. They eat human capacity without needing human judgement, and AI handles them with a consistency people can’t match. Steps involving novel situations, relationship context, ethical nuance, or genuine strategic trade-offs are a different matter. Insert AI there and you tend to degrade the outcome, not improve it.

So process anchoring forces an honest read on where variance actually lives in your operations. Not variance in volume — AI is good at volume — but variance in context, stakes, and consequence. A customer complaint is high-volume and often low-variance. A contract negotiation is low-volume and almost never low-variance. A system that treats both the same will look fine on the first and do real damage on the second. The right design question isn’t can AI handle this? It’s what does the failure look like when AI handles this wrong — and are we willing to live with that failure at scale?

Layer Three — Decision Integration

This is the layer that decides whether you’ve built organisational capability or just tool capability. Decision integration is about how AI’s outputs actually enter the decision-making structure: who sees them, in what form, at what point, and with what authority.

Here’s where most organisations take the path of least resistance and bolt the AI output on as one more report, one more dashboard, one more input fighting for attention. The result is what I think of as advisory wallpaper — technically present, practically ignored. The people who should use it don’t, because it was never built into their actual workflow. It sits beside the decision instead of inside it.

Real integration means redesigning how a decision gets made, not adding a data source to the pile. Someone owns the AI’s recommendations. There’s a feedback loop so the system learns from when its recommendations are used or overridden. And there’s accountability for the quality of AI-assisted decisions over time. None of this is hard in theory. All of it takes deliberate governance design, which is exactly why so few teams do it well.

The Implementation Risks Nobody Talks About

Every vendor’s risk register covers the same ground — data privacy, model accuracy, integration complexity. Real risks, and any competent team handles them. But there’s a second category that rarely gets airtime: the organisational and strategic risks that show up not when AI fails, but when it works.

Dependency without understanding.
A system that works well gets embedded fast. Decisions start leaning on it, processes get rebuilt around it. Then the outputs shift — a model update, data drift, a config change — and nobody notices, because the people making the decisions stopped engaging critically with the outputs months ago. They trusted the system without keeping the understanding needed to judge whether it was still trustworthy. This isn’t hypothetical. It happens in any organisation that implements the technology without building AI literacy as a leadership capability alongside it.

Strategic displacement.
AI can make a bad strategy look efficient. If your go-to-market is wrong but AI is making you execute it faster and cheaper, you’ve increased your speed of failure, not decreased it. AI amplifies whatever operational logic is already in place — sound logic gets more valuable, flawed logic gets more dangerous. If you’re deploying AI during a period of strategic uncertainty, watch this one closely: you may be busy automating a path you ought to be reconsidering.

The governance vacuum.
AI influences decisions at a speed and scale human governance was never built for. When a person makes a bad call, there’s usually a trail — an owner, a process to review, an accountability structure to invoke. When a system shapes thousands of decisions a day and the quality quietly drifts, that structure often isn’t there to catch it. Building governance that matches the operational scale of AI isn’t optional. It’s the line between deploying a capability and deploying a liability.

Governance Before Scale

Let me be blunt about something I think is systematically underweighted in how this gets discussed at leadership level. Governance is not a bureaucratic tax on AI adoption. It’s the precondition for adoption that doesn’t eventually hurt you.

In practice it comes down to three things. Ownership: for every AI-assisted or automated process, a human role owns the quality of the outcomes, watches the system’s performance, and has both the authority and the knowledge to step in when something’s off. Escalation: there are explicit, understood criteria for when a recommendation should be overridden, reviewed, or kicked up to human judgement. Review cadence: the system’s performance gets assessed on a schedule against the actual operational and strategic outcomes it was built to support — not just against accuracy and uptime.

This doesn’t have to be elaborate. For most teams early in deployment it can be genuinely lightweight. But it has to exist before scale, not after, and the reason is simple: governance is far harder to retrofit onto a running system than to design into one still being built. Once a process operates at scale and the organisation has taken on real dependency, the disruption needed to add governance can be prohibitive — so you end up managing the gap forever instead of closing it.

The leaders who govern AI well treat it as an operational discipline, not a compliance exercise. The test they apply is plain: if this system behaved strangely tomorrow, would we know? Would we know fast enough? Would we know who’s responsible for fixing it? Any “no” is a governance gap to close before deployment, not after.

What a Real AI-Enabled Operation Actually Looks Like

It’s worth being concrete about the end state, because the discourse tends to describe it in terms of flashy individual capabilities rather than operational reality.

A real AI-enabled operation isn’t one where AI does spectacular things. It’s one where the information available for decisions is better, the lag between a situation arising and a fitting response is shorter, and the cognitive load on skilled people is concentrated on the work that genuinely needs their judgement. By the time a senior leader meets a decision, the context has been assembled, the routine elements processed, and the ambiguity surfaced instead of buried. Anomalies get flagged before they become problems, because the system is constantly comparing actual performance to expected patterns. Institutional knowledge survives team changes, because it’s been codified into systems rather than trapped in individuals.

What it does not look like is faster execution of the same processes, at the same decision quality, with fewer people. That’s an AI efficiency play. It has value, but it isn’t the same thing as an AI capability play — and the difference compounds over years into a real gap in competitive position.

The teams I’ve watched make the most durable progress started with honesty about where their operations actually broke, built the signal and process foundations to support intelligent assistance, then aimed AI at a few specific high-leverage points instead of spraying it across the board. Less dramatic in the first quarter. Far more significant by the second year.

So the question I keep putting to executive teams is this: what does your organisation need to be able to do in three years that it can’t do today — and how much of the distance between here and there is your operational decision-making? That reframes AI from a technology investment into a strategic capability investment, and it changes the sequencing, the evaluation criteria, and what success even looks like. It also makes the conversation harder, because it forces leaders to be honest about where their operations are genuinely constrained. The answer is rarely where the most visible problems are.

I’m convinced the leaders who get the most durable advantage from AI won’t be the ones who move fastest, but the ones who think most clearly about where it belongs. The technology is capable. The open question is always whether the organisation around it is built to use that capability in a way that compounds rather than merely accumulates. That work starts with a strategic diagnosis, not a technology decision — and it’s exactly the kind of work a leader should own.

That was eighteen months ago. The model is still running in a sandbox. The team that built it has been reassigned. The workflow it was supposed to automate is still being done by hand.

This story is not unusual. In fact, depending on which research you consult, somewhere between sixty and eighty percent of AI proof-of-concepts never reach production. The numbers vary, but the pattern is consistent: organisations fund pilots enthusiastically, demonstrate results in controlled environments, and then quietly fail to cross the gap between “it works in theory” and “it works in practice, at scale, every day.” The technical community has a name for this liminal state: pilot purgatory.

What’s notable is that pilot purgatory is rarely a technology failure. The models work. The data pipelines, when set up carefully, do what they’re supposed to. The failure is almost always structural — a gap between what a proof-of-concept is designed to demonstrate and what a production system is actually required to do.

Understanding that gap, and building an organisation capable of crossing it, is the real work of AI adoption at scale.

The Pilot Purgatory Problem

It’s worth being precise about why AI pilots fail to scale, because the reasons are more specific than they first appear.

The most common explanation offered by technology vendors is that organisations lack the right infrastructure. More compute, better data lakes, more sophisticated MLOps tooling — these are usually presented as the primary barriers. They’re rarely the actual problem. Most organisations that have reached the point of running serious AI pilots have adequate infrastructure for early production deployment. The infrastructure case for staying in pilot mode is usually a rationalisation, not a cause.

A more honest explanation is this: pilots are designed to be successful. They are scoped carefully to a slice of a workflow where the conditions are favourable. They run on clean data — data that has been selected, prepared, and validated specifically for the exercise. They are supervised by the people who built them. They operate without the noise, the edge cases, the integration dependencies, and the operational variability of a real production environment. And they are evaluated on whether they can demonstrate the core capability, not on whether they can sustain performance under realistic conditions over time.

This is not necessarily wrong.
A pilot should demonstrate feasibility before an organisation invests in the full deployment infrastructure. The problem arises when pilot success becomes the standard by which production readiness is measured. When the question asked is “did it work?” rather than “is it ready?”, organisations almost always get the answer they want to hear — and almost always find themselves surprised by what happens next.

The underlying issue is that a proof-of-concept and a production system are fundamentally different things. Not different versions of the same thing, but different categories of system with different purposes, different failure modes, and different requirements. Conflating them is the foundational error that drives organisations into pilot purgatory.

Why the Demo Environment is a Lie

To make this concrete, it helps to look at exactly where demo and production environments diverge — because the divergence is wider than most organisations realise until they try to cross it.

In a pilot, data arrives pre-formatted. In production, it arrives from eleven different source systems, three of which are legacy, two of which have undocumented schema changes from 2019, and one of which sends inconsistently structured JSON that breaks the parser approximately three percent of the time. That three percent, in a pilot running on hand-curated samples, never shows up. In a production system processing three thousand records a day, it shows up ninety times. And someone has to deal with it.

In a pilot, the team that built the model is present. They know its quirks. They know which queries it handles well and which ones make it hallucinate. They’ve developed an intuitive sense of when to trust its outputs and when to override them. In production, the model is operated by people who weren’t involved in building it, who have other responsibilities, and who need to make decisions quickly. The informal knowledge that kept the pilot running cleanly doesn’t transfer. It lives in the heads of people who are no longer in the room.

In a pilot, failure is visible and non-critical. If the model returns an unexpected result, the team investigates, learns something, and adjusts. In production, failure can propagate downstream before anyone notices. Automated processes consume the model’s output without human review. Decisions get made. Actions get taken. By the time the error is caught, the consequences have already materialised.

In a pilot, the integration surface is minimal. The model connects to one or two data sources, outputs results in a controlled format, and the team reviews everything manually. In production, the model sits inside a network of interconnected systems — CRMs, ERPs, communication platforms, approval workflows, reporting dashboards — each of which has its own API stability characteristics, its own update schedule, and its own set of breaking changes waiting to happen.

None of these differences are insurmountable. But they must be named explicitly, because organisations that treat production deployment as “a bigger pilot” consistently underestimate the gap.

The Four Readiness Gaps

The distance between pilot success and production stability can be understood as four distinct readiness gaps, each of which must be assessed and addressed before deployment can be considered viable.

Technical Readiness: Stability at Scale

Technical readiness is the most familiar of the four gaps, but it’s often assessed too narrowly. The question organisations ask is usually: does the model perform accurately? The more important questions are about what happens when conditions are less than ideal.

Performance under load is one dimension. A model that processes documents accurately when handling ten inputs per hour may degrade significantly at peak capacity — not because the model itself changes, but because the supporting infrastructure wasn’t built to handle the concurrency. Latency, timeout handling, retry logic, and graceful degradation all need to be designed in, not retrofitted.

Observability is another. Production systems need to emit signals that tell operators what they’re doing. Not just whether they’re running, but how they’re performing: confidence distributions, error rates by input type, latency percentiles, and drift indicators that flag when the model is beginning to diverge from its baseline behaviour. Pilots almost never have proper observability built in. Production systems cannot operate without it.

API and integration stability is a third dimension that organisations consistently underestimate. Every upstream data source and every downstream consumer of the model’s output represents a dependency that can and will change. The model needs to handle schema changes gracefully, degrade non-catastrophically when a dependency is unavailable, and alert operators before small integration failures become systemic incidents.

Data Readiness: Consistency Under Pressure

The data conditions in a pilot are almost never the data conditions in production. This is not a complaint about sloppy pilots — it’s a structural reality. Clean data is a prerequisite for demonstrating that a model works. Real operational data is a prerequisite for demonstrating that a model can survive contact with reality.

The relevant questions for data readiness are not about whether the data is good. They’re about whether the data is consistently structured, reliably available, adequately governed, and properly understood. Who owns the data? Who can modify it? What happens when the source system is updated? Is there a process for detecting and handling data quality degradation? Are there labelled datasets available for ongoing model evaluation and retraining?

Data lineage and ownership are particularly important in AI systems, because the consequences of data quality failures are often non-obvious and delayed. When a model begins to underperform because its training data has become stale, or because an upstream system has silently changed its output format, the failure won’t necessarily announce itself clearly. It will manifest as subtly degraded outputs — decisions that are slightly less accurate, classifications that drift toward edge categories, predictions that are technically within range but directionally wrong. Without data governance infrastructure that tracks these signals, organisations can operate degraded AI systems for months without knowing.

Organisational Readiness: People and Process

This is the readiness gap that organisations most consistently underinvest in, and the one that most frequently explains why technically capable AI systems fail in production.

Organisational readiness is about whether the people and processes around the model are prepared to operate it reliably, to trust its outputs appropriately, and to escalate when something is wrong. These are not soft questions. They have precise, structural answers.

Who owns the model in production? Not the team that built it — that team is usually gone or reassigned by the time the system goes live. Who is accountable for its performance? Who decides when it should be overridden, retrained, or decommissioned? If these questions don’t have clear answers before deployment, they will be answered badly under pressure, and usually after something has already gone wrong.

What does the human-in-the-loop structure actually look like? In a pilot, humans are involved everywhere. In a production system optimised for efficiency, human review gets progressively removed as confidence in the model increases. This is reasonable, but it requires that the escalation pathways for edge cases are explicitly designed and that the thresholds for human review are calibrated, documented, and maintained as the model evolves.

Training is underestimated because it’s treated as a one-time onboarding activity rather than an ongoing operational requirement. The people who interact with AI systems in production need to understand what the model can and cannot do, how to recognise when its outputs are suspect, and what to do when they are. This understanding degrades over time as people change roles, as the model is updated, and as the operational context shifts. Sustained capability requires sustained investment.

Governance Readiness: Accountability Structures

Governance is the gap that gets least attention in the technical planning process and causes the most damage when it’s missing. At the pilot stage, governance questions are easy to defer: the system isn’t making real decisions, the stakes are low, and the people involved are close enough to the work to handle edge cases by judgement. In production, none of those things are true.

What decisions is the AI system making, and who is accountable for them? If an AI-assisted credit assessment results in a declined application, who is responsible? If an AI-generated procurement recommendation leads to a suboptimal supplier selection, where does accountability sit? These questions need answers that are embedded in organisational structures, not just assigned to the technology team.

Audit trails are a governance requirement that becomes non-negotiable in regulated environments but is relevant in virtually every production AI deployment. When a decision is made with AI assistance — or made by an AI system operating autonomously — there needs to be a record of the inputs, the model state, the output, and any human review that occurred. This record is the foundation for understanding what went wrong when errors occur, for demonstrating compliance when it’s required, and for the ongoing calibration of where human oversight is and isn’t needed.

Explainability is a related requirement that is often reduced to a technical discussion about model interpretability. But in a production context, explainability is primarily an operational and governance question: can the people who operate the system, and the people affected by its outputs, understand why it made a particular decision? The answer doesn’t need to be a complete technical specification of the model’s internal representations. It needs to be sufficient for the humans involved to make informed judgements about when to trust, question, or override.

A Framework for Production Readiness Assessment

Rather than assessing readiness against a checklist, it’s more useful to think in terms of a structured conversation that forces specific answers to specific questions. The following framework is one way to structure that conversation.

The Stability Audit addresses the technical dimension. Run the system at three times expected peak load and measure: latency degradation, error rate, recovery time from transient failures, and the clarity of the signals the system emits when under stress. If the system can’t be run in a realistic load environment before deployment, that’s itself a signal about readiness — not necessarily a blocker, but a risk that needs to be named and managed.

The Data Contract Review addresses the data dimension. For every upstream data source: document the expected schema, the update frequency, the ownership, the quality SLA, and the fallback behaviour when the source is unavailable or malformed. For every downstream consumer: document the expected output format, the tolerance for latency, and the consequence of unexpected values. This exercise consistently surfaces undocumented dependencies and invisible assumptions that would otherwise emerge as production incidents.

The Operations Handoff Assessment addresses the organisational dimension. Simulate a full handoff from the build team to the operations team. Give the operations team a realistic incident — a model output that appears anomalous, a performance degradation, a data quality failure — and observe what happens. Can they diagnose it? Do they know who to escalate to? Do they trust their own judgement about when to intervene? The gaps that emerge from this exercise are almost always more instructive than any documentation review.

The Accountability Map addresses the governance dimension. For each type of decision the system makes or influences: document who is accountable for the decision, what the escalation path is when the decision is challenged, what audit trail is maintained, and what the process is for reviewing and updating the accountability structure as the system evolves.

None of these assessments are particularly complicated. What makes them useful is that they force specificity. The phrase “we’ll handle that when we get there” is a reliable indicator that an organisation is not ready to deploy. The framework exists to eliminate that phrase from the conversation before something goes wrong.

Change Management is Not Soft Work

There is a tendency in technically oriented organisations to treat change management as the soft, consultancy-adjacent activity that happens around the real work of deployment. The actual situation is closer to the reverse: in most AI production failures, the technical components perform as designed. The failure is in the human system — the way people relate to the model’s outputs, the way trust is calibrated, the way the organisation responds when the model gets it wrong.

The central challenge is that AI systems produce outputs that look authoritative. Humans are not naturally calibrated to be appropriately sceptical of outputs that are presented with confidence, well-formatted, and technically consistent. When a model produces an answer, people tend to treat it as more reliable than it is — not because they are credulous, but because the cognitive default is to trust structured information that appears to have been produced by something capable. Changing this default requires deliberate, sustained effort.

The practical implication is that training for AI system users needs to be primarily about developing accurate mental models of the system’s limitations, not just about how to operate it. People need to understand what the model’s failure modes look like in practice, not just in the abstract. They need to encounter examples of the model being wrong — convincingly, plausibly wrong — before they’re operating it under real conditions. This kind of adversarial familiarity is not a standard feature of onboarding programmes, and it should be.

The other dimension of change management that organisations underestimate is the political dimension. AI systems change the distribution of information and authority inside organisations. When a system surfaces data that was previously unavailable, or makes explicit a process that was previously informal, it creates winners and losers. People whose informal expertise is made less relevant by an AI system have rational incentives to undermine it. People whose performance metrics are now more visible have rational incentives to game the data. These dynamics don’t announce themselves as resistance to AI. They manifest as subtle forms of non-compliance, workarounds, and “edge cases” that mysteriously keep appearing.

Recognising these dynamics early — and addressing them structurally rather than through encouragement or communication — is a core leadership responsibility in AI deployment. It requires understanding the informal power structures inside the organisation, not just the formal ones.

The Leader’s Role in Escaping Pilot Purgatory

The single most common proximate cause of AI programmes stalling in the pilot-to-production gap is the absence of a senior leader who is accountable for the programme’s operational outcome — not just its technical delivery.

This distinction matters. Technical delivery accountability sits naturally in engineering or data science teams. They can build the model, demonstrate the performance metrics, and hand it over. But the readiness gaps described above — data governance, organisational change, accountability structures, operational integration — don’t sit cleanly inside any single function. They require cross-functional decisions that only a senior leader can make and enforce.

The leader’s role is not to manage the technical work. It’s to keep the organisation honest about the difference between a working prototype and a deployable production system, to make the resourcing decisions that allow the production readiness work to happen, and to absorb the political pressure that comes with the organisational changes AI deployment requires.

One of the most useful things a senior leader can do at the pilot-to-production stage is establish what might be called a deployment threshold — a set of specific, measurable conditions that must be met before the system goes live. This threshold serves two functions. First, it provides a clear definition of done that focuses the production readiness work on specific gaps rather than a vague sense that “more work is needed.” Second, it provides political protection for the team: when stakeholders are pushing for faster deployment, the threshold gives the team something concrete to point to rather than having to defend judgement calls under pressure.

The threshold should be set by the leader, in consultation with the technical and operations teams, and should include conditions across all four readiness dimensions: stability under load, data quality standards, operational handoff completion, and governance accountability documentation. It should not be negotiable in response to schedule pressure, and it should not be declared met on the basis of optimistic projections.

Leaders who set and hold this threshold are the ones whose AI programmes actually reach production. Leaders who treat it as a formality are the ones who end up explaining, twelve months later, why the system is still running in a sandbox.

Reflection

The pilot-to-production gap is an organisational maturity problem — the gap between what an organisation can demonstrate and what it can sustain.

This distinction is important because it reframes where the work actually needs to happen. Organisations that treat the gap as a technology problem invest in more sophisticated infrastructure, more capable models, and more refined architectures. These investments are not useless, but they rarely close the gap on their own. Organisations that understand it as an organisational maturity problem invest in governance structures, operational capabilities, change management, and leadership accountability. These are harder investments to make, slower to materialise, and less immediately visible. They are also the ones that actually move a programme from a compelling demonstration to a system that runs reliably in production and compounds in value over time.

The organisations that have successfully scaled AI beyond the proof-of-concept stage share a common characteristic: they stopped measuring success by what the model could do and started measuring it by whether the organisation could sustain, govern, and evolve it. That shift in measurement — from technical capability to operational readiness — is the moment when an AI programme stops being an experiment and starts becoming infrastructure.

That transition is harder than it sounds. It requires leaders to hold a longer time horizon, teams to build less interesting but more durable systems, and organisations to invest in the invisible scaffolding that makes sophisticated technology usable by ordinary people under real conditions. It requires, in short, the same discipline that any serious engineering organisation applies to the systems it builds and maintains.

The proof-of-concept was never the point. It was the permission slip to do the real work.

*Gustavo De Felice is a digital project leader with over 1,200 managed projects, Director of Websfarm Ltd, and founder of FlowSphere. He writes about AI adoption, operational governance, and systems thinking for complex organisations.*

They weren’t unusual. They were typical.

The gap between strategic ambition and organisational readiness is the single most common reason AI initiatives stall, overspend, or quietly get shelved after six months of piloting. Leaders commit to transformation before they’ve audited whether the foundation supports it. The result isn’t failure from bad technology — it’s failure from deploying good technology into an unprepared host.

What follows is a framework I’ve refined across dozens of engagements: a structured method for assessing and building organisational readiness before committing to AI at scale.

Why “AI Readiness” Is Not the Same as “Digital Readiness”

There’s a widespread assumption that organisations that have completed digital transformation programmes — moved to cloud infrastructure, modernised their CRM, adopted SaaS workflows — are ready for AI. This is wrong, and the conflation causes expensive mistakes.

Digital transformation, broadly, is about moving existing processes onto better infrastructure. AI transformation requires something more fundamental: it requires your organisation to develop a tolerance for probabilistic outputs, to redesign decision workflows around machine-generated insight, and to build governance structures that didn’t exist in the digital-first era.

A company can be entirely cloud-native and still be structurally unprepared for AI. The reasons are rarely technical. They’re architectural — in the organisational sense. Who owns the data? Who validates model outputs? What happens when the system is confidently wrong? These aren’t questions that digital readiness programmes answer.

AI readiness is its own domain. It needs its own assessment.

The Five Dimensions of AI Readiness

Over time, I’ve landed on five dimensions that collectively determine whether an organisation can absorb AI at the pace and depth it intends. No dimension is optional. Weakness in any one of them will bottleneck everything else.

1. Data Infrastructure and Governance

This is where most assessments should begin, and where most organisations discover their first uncomfortable truth.

AI systems are not sophisticated without quality data. The capability of the model is secondary to the reliability of what feeds it. Before any meaningful AI deployment, an organisation needs honest answers to a short set of questions: Where does your operational data live? Is it accessible in a form that can be used for training or inference? Who owns it? Who can change it? Is there a documented schema? Are there anomalies, gaps, or known quality issues?

The answers to these questions define your ceiling before you’ve written a single line of an AI brief.

Data governance — distinct from data storage — means having clear policies for who can access what, how data is classified, what retention rules apply, and how changes are tracked. Most organisations have informal arrangements that work well enough for human operators but collapse the moment you introduce automated systems that act on that data at scale and speed.

The remediation work here is often substantial and always slower than expected. It is also non-negotiable.

2. Organisational Structure and Ownership

AI requires a home inside your organisation. Not just a project team, but a structural location: a function or role responsible for AI governance, model evaluation, deployment decisions, and incident response.

In smaller organisations, this might be a single person with a clear mandate. In larger ones, it’s a cross-functional function with defined relationships to Legal, IT, Operations, and the C-suite. What it cannot be is diffuse — a shared responsibility that belongs to everyone in principle and nobody in practice.

The absence of clear ownership is where AI initiatives go to die quietly. When a model produces a problematic output, or when a pilot runs out of runway, the organisation needs someone with authority and accountability to make the next decision. Without that, decisions get delayed, escalated inappropriately, or avoided entirely.

Assessing your structural readiness means asking: if something goes wrong with an AI system in production tomorrow, who is called first, and what can they actually do?

3. Talent and Capability

There is a difference between hiring AI talent and building AI capability. Most organisations try to do the former without adequate investment in the latter.

Hiring a machine learning engineer or a data scientist does not make an organisation AI-capable. It makes that individual capable. The organisation becomes capable when the people surrounding that specialist — product managers, operations leads, business analysts, customer-facing teams — develop enough literacy to brief the work intelligently, interpret outputs critically, and flag problems accurately.

The capability gap is rarely about the technical core. It’s about the connective tissue. And this is a training and onboarding problem, not a hiring problem.

When I assess talent readiness, I look at three layers: the technical core (can we build or customise?), the interpretive layer (can the business use and challenge outputs?), and the governance layer (can leadership make informed decisions about AI risk and investment?). An organisation can be strong at the first and weak at the third, which is exactly the configuration that produces the most damaging failures.

4. Process and Workflow Integration Readiness

AI doesn’t sit alongside your processes. It changes them. Every AI deployment, from a simple chatbot to a predictive operations model, requires that someone thinks carefully about how existing workflows need to adapt before and after the system is live.

This is frequently underestimated. Organisations pilot AI in isolation — in a sandboxed environment, evaluated against abstract metrics — and then discover that integrating it into live operations requires renegotiating a half-dozen adjacent workflows that nobody mapped in advance.

The diagnostic question here is: for the processes you intend to augment with AI, have you documented the current state, identified the decision points where AI output will be used, and designed the human-in-the-loop steps for when the system is uncertain or wrong?

That last part — the failure mode — is where integration planning most often breaks down. Systems don’t fail on their best day. They fail on their worst day, under load, with edge-case inputs, when the operators are busy with something else. The process design needs to account for that.

5. Governance, Ethics, and Risk Frameworks

The regulatory environment around AI is moving faster than most organisations’ governance frameworks. The EU AI Act is now in force for high-risk categories. Data protection obligations intersect with AI in ways that require active legal review rather than assumed compliance. And the reputational risks from AI systems that produce biased, incorrect, or manipulative outputs are no longer theoretical.

Governance readiness means having documented policies — or at minimum, documented decision-making processes — for a defined set of questions: What AI use cases are permitted, restricted, or prohibited? How are AI outputs reviewed before they affect customers or operational decisions? Who approves new AI deployments? How are incidents classified and escalated?

These don’t need to be elaborate. A small organisation can run effective AI governance with a one-page policy and clear role assignments. But the alternative — operating without any framework and building one reactively after something goes wrong — is significantly more expensive and more damaging.

Applying the Framework: A Readiness Audit

The five dimensions above are diagnostic categories. In practice, I run a structured audit against each one before any engagement goes into planning. The output is a readiness score — not a numerical rating, but a qualitative map of where the organisation is strong, where it has manageable gaps, and where the gaps are significant enough to sequence work before AI deployment begins.

The sequencing decision is often the most valuable output of the audit. Many organisations are ready to deploy in some dimensions and need six to twelve months of foundational work in others. The framework helps leadership make that call explicitly, rather than discovering it mid-deployment when cost and timeline commitments are already made.

The most important principle: readiness work and AI strategy work are not sequential. You do them in parallel. While the data governance remediation is underway, you’re building the ownership structure and training the interpretive layer. The audit tells you what to run in parallel and what must complete before the next phase can begin.

The Risks of Skipping the Assessment

The argument against a formal readiness assessment is almost always speed. Leadership wants to move now. Competitors are moving. The board is watching. A structured audit feels like delay.

This argument is rarely borne out in practice. Organisations that skip readiness assessment don’t move faster — they move faster initially and then stall harder. Pilots that can’t scale. Governance crises that surface months after deployment. Data quality issues that invalidate months of model training. Technical debt incurred by integrating AI into unaudited processes that then need to be redesigned.

The readiness framework doesn’t slow transformation. It front-loads the work that would otherwise surface as crisis.

There is also an underappreciated cultural risk. Organisations that deploy AI into unprepared environments tend to generate early failures — not catastrophic ones, but visible ones. And visible failures in AI have a way of hardening scepticism across the organisation in ways that take years to undo. The people who were uncertain become convinced opponents. The executive team becomes risk-averse at exactly the moment they should be building momentum.

Getting the foundation right isn’t conservatism. It’s how you preserve the political capital to go further, faster, later.

A Note on Vendor-Driven Readiness Assessments

A word of caution that belongs in any honest treatment of this topic: most “AI readiness assessments” offered by technology vendors are scoped to surface the gaps that their products fill.

This is not malicious. It’s structural. A vendor selling an AI data platform will assess your data infrastructure thoroughly and your organisational capability lightly. A vendor selling AI talent solutions will assess your skill gaps and say relatively little about governance.

If you’re using a vendor assessment as your primary diagnostic tool, you’re getting a partial picture. The five-dimension framework above is explicitly vendor-agnostic. It’s designed to tell you where you are before you’ve decided what to buy, not to validate a buying decision you’ve already made.

Strategic Reflection: Readiness as a Competitive Capability

I’ve come to think of AI readiness not as a precondition to be checked off, but as a capability to be built and maintained. The organisations that will extract the most long-term value from AI are not necessarily the ones that move earliest. They’re the ones that build the structural capacity to absorb, evaluate, and deploy AI reliably — and then do it repeatedly, across multiple functions, over multiple years.

That structural capacity — the data governance, the ownership model, the trained interpretive layer, the governance framework — doesn’t depreciate. It compounds. Each deployment makes the next one easier, faster, and lower-risk.

The manufacturing client I mentioned at the start eventually got there. Not in twelve months. In twenty-two. The additional ten months were spent doing the foundational work that the original timeline had assumed away. The outcome was a system in production, adopted by the operations team, with a governance structure that has since been applied to two further AI deployments.

They didn’t fail. They just had to build the organisation that could succeed before they could succeed.

That is, ultimately, what readiness means.

*If you’re working through an AI initiative and finding that the strategic case is clear but the execution keeps hitting friction, I’d be interested in hearing what dimension is creating the most drag. The patterns are consistent enough that the answer usually points directly to where the foundational work is incomplete.*