Somebody wrote it because they cared about it. They enforced it for a while, and enforcing it meant refusing things. Refusals cost them meetings, goodwill, and at least one working relationship. Then they moved on.

The document stayed. Nobody withdrew it. Nothing broke that anyone traced back to it. It is still on the intranet, still handed to new joiners, still quoted in a design review when somebody needs to win an argument. It simply stopped changing what anyone does, and there was no day on which that happened.

I have written one of those documents. Post 12 was about what it cost to keep it.

That is where this season ended up. It is not where it started.

The claim I opened with

Capability decides nothing on its own. The structure placed around a capability decides what it becomes.

I called that structure a harness, and Post 2 gave it its cleanest form. The model reasons. The harness decides what matters.

It is a good argument. It is also the argument a technology function reaches for when a board asks how an AI programme will be kept safe. The answer the board hears is a control framework. The answer the board is buying is that somebody will say no when it counts, on a day when saying no is expensive.

Where it came apart

The objection to my own argument was sitting in Post 3, and I did not see it for another nine posts.

A guardrail without enforcement is a wish.

I read that at the time as advice. Write good guardrails, then make sure they are enforced. Two tasks, both of them mine to design.

Read it again and it sets a limit instead. A guardrail is a rule. A rule does not apply itself. A person applies it, and that person has to be willing to apply it on the day doing so is expensive. So the thing deciding the outcome was never the guardrail. It was whoever was standing behind it.

I missed it because I was looking for the weakness in the wrong place. I expected a technical hole. This was a human one.

The same shape then turned up in four more posts, and I treated each as a separate subject.

Post 8 was about debt an institution already knows it carries. Someone has to price the delay before the market does it for them, and whoever prices it early becomes unpopular for it.

In Post 9 the subject was proof. A proof filed once stops being a proof. Someone has to keep being able to give it.

Post 10 dealt with work that prevents failure. It leaves no trace, so someone has to keep defending a budget with nothing to point at.

Then Post 11, on failures that carry on after the cause is fixed. Someone has to keep watching a thing that already looks solved.

Four subjects, one shape underneath. In every case the structure was in place. In every case it held only while a person was carrying a cost, and nothing in the system noticed the day they stopped.

Post 12 finished it. An institution never inherits a rule. It inherits the memory of what the rule cost the person who kept it.

So here is the correction. A harness is not something you install. It is a position somebody occupies. It works for as long as that person is visibly bound by it and pays something for staying bound. Take the person out and you do not get a failure. You get the document.

The obvious objection, which I have made myself

Automate the enforcement. Put the standard in the pipeline, fail the build, and the problem of the departing enforcer disappears.

It does not disappear. It moves.

An automated control still has to be kept current as the estate changes underneath it. Exceptions still have to be granted, and every exception is a refusal somebody decided not to make. In more than one organisation over the years I have seen a gate that still runs, still reports green, and carries a permanent exception list longer than the rule it enforces. The build passes. Nobody is bound by anything.

Automation gives you better evidence that a control ran and worse evidence that anyone is still standing behind it. You end up with the document either way. It just executes on a schedule.

What writing it revealed

I set out to write a season about design and finished writing one about people.

The drafts that stalled were always the same kind. I would be three quarters of the way through, reaching for the control that would make the argument close, and there would not be one. A gate. A standard that enforces itself once installed. Something I could specify and hand over. Each time, the sentence I was avoiding turned out to be about who was carrying the cost.

That is an uncomfortable finding for someone whose instinct is architectural. It is also the only one the evidence supported.

To everyone who read, replied, or disagreed in the comments. Thank you. The disagreements changed more of this season than the agreements did.

Where that leaves the governing sentence

I would not withdraw the sentence I opened with. I would add a line to it.

When the system can do anything, leadership is defined by what it chooses not to become, and by who is still paying to hold that choice in place.

Choosing is the easy half. Every institution can choose. Most have a principles page to prove it. The hard half comes after the person who made the choice has gone, and I have not seen an institution solve that part.

Three things I take as settled at the close of the season.

• Capability is no longer the constraint. Designing as though it still is puts the controls in the wrong place.

• A structure changes behaviour only while someone is bound by it and pays for staying bound.

• Control testing shows that a control ran. Whether anyone is still bound by it is a separate question, and it is rarely asked.

The question I am left with

If an institution is held together by a cost somebody is still paying, then succession is a harder question than who takes the role. The one that matters is who has paid enough to know what the role is for.

A great deal of what is being automated right now sits directly on top of that question. I have not seen it asked. It is where I am going next.

An institution never loses its standards. It loses the person who was paying for them, and from the inside those two look identical.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Share

Think of a principle your organisation still holds that predates everyone now in the room. Then ask how it got there.

Most organisations cannot answer. The principle shows up in what gets funded, in what gets refused, and eventually in what a board is asked to defend, and nobody can say who paid for it, or when. It arrived. It stayed.

The question matters because the usual answer is wrong. The usual answer is that somebody wrote it down.

Two stories, separated by two thousand years, show what actually happens.

The rope that held

Ulysses is a Greek king sailing home after ten years of war. Before the next leg he is warned about a stretch of water ahead, where two creatures called the Sirens sing.

The warning is stranger than it first sounds. The Sirens do not attack. They do not need to. Any sailor who hears the song wants to go to them, and turns the ship toward the voice himself, and the ship breaks on the rocks. The meadow where they sit is heaped with the bones of men who did exactly that.

So the danger is not the rocks. The danger is that a man will want the rocks. He will steer for them with his own hands, and he will be certain at the time that he is right.

Ulysses wants to hear the song anyway. He also knows precisely what will happen to him. He will order the ship turned. He will mean it. He will be the captain, and they will be his orders, given in his own voice.

So he arranges matters in advance, while he can still think clearly.

He tells the crew to tie him to the mast, to ignore anything he says once he is bound, and to tie him tighter if he begs to be released.

That is the half everyone remembers.

Here is the other half. He takes a round of beeswax, softens it in his hands, and plugs the ears of every man at the oars, so that they hear nothing at all.

Then the ship passes the coast and it goes exactly as he predicted. He hears the song. He strains against the ropes. He shouts at his men to turn the ship. They cannot hear him, and they row on.

Ulysses heard the song and lived. The rowers crossed in silence. They never heard it, and they were never asked whether they wanted to.

The philosopher Jon Elster built an argument on the rope. In 1979 he named the idea. Precommitment. You do not rely on resisting at the moment of temptation, because at that moment your judgement is the thing that has failed. You remove the option beforehand, while you are still the person who can see the situation clearly.

Twenty-one years later he returned to the story and changed his mind about his own earlier work. He had argued that a constitution is a nation binding itself. A colleague told him that in politics people never bind themselves, only others. Elster accepted this was closer to the truth than what he had written, and pointed at the wax.

The rope that did not

Around 261 BCE the emperor Ashoka went to war against Kalinga, the territory covering most of what is now Odisha. He won. His own inscription records what it took. A hundred and fifty thousand deported. A hundred thousand killed. Many times that number dead in the aftermath.

Then something turned in him, and the edict is unusually specific about what.

It was not the campaign he regretted. It was the suffering, and particularly the suffering of people who had no part in the fighting. The edict names them. Households broken apart. Injury falling on the devout, the old, the ordinary. Friends and relations of the dead who were nowhere near the fighting. It says the killing weighed on him, and it says so in the first person, in public, on stone.

That remorse is the reason for everything that follows. He does not record it as a feeling he had. He records it as the cause of a decision.

He gave up war as an instrument of state. In its place he declared that the only conquest worth having was conquest by dhamma, by right conduct, and that this was the measure he now wanted applied to his reign.

For a ruler of that period this was not a gesture. Conquest was how territory grew, how treasuries filled, and how a throne stayed safe. He was giving up the main thing he had, and putting a slower and far less certain thing in its place.

Then he did the harder part. He tried to make the decision outlast him.

He had it carved into rock faces across the empire, and the inscription says why. He wrote it so that his sons and his great-grandsons would not think a new conquest ought to be made. He was not binding himself. He was already convinced. He was binding people he would never meet, in an office he would no longer hold.

That is a rope, and it is more ambitious than anything Ulysses attempted. Consider what he put behind it. Multiple sites across the empire. Local languages, so it could be read by the people it governed. The reasoning written out in full rather than the instruction alone. And the most durable medium available to any ruler on earth.

Three things happened to it.

The first is where the rocks stand. There is one at Dhauli, on the bank of the river Daya, a short distance from where the killing happened, and another at Jaugada further south. Both sit inside the conquered territory. Both carry his edicts. Neither carries that one. At both sites the sequence runs through the first ten edicts, skips three, and resumes, and the three that are missing include the account of the war and the remorse. He published his confession across an empire and left it off the two rocks standing nearest the people who had survived what he was confessing to. Historians disagree about why, and limited space on the rock is among the explanations offered. Whatever the reason, the people best placed to know what the war had cost, and therefore best placed to testify that his change of course was real, were the people not shown it.

The second is what happened to the dynasty. Ashoka died around 232 BCE. Roughly fifty years later the last Mauryan ruler was assassinated by his own army commander, and the empire he had tried to bind was gone.

The third is what happened to the words. The script itself fell out of use. The inscriptions stood in the open, in plain sight, on roads people walked past, and there came a point at which not a single living person could read them. They were deciphered by James Prinsep, an official of the Calcutta mint, who published his findings between 1836 and 1838.

An emperor wrote his deepest commitment into stone so that his descendants would be held to it. They were not. And for something close to two thousand years, no one who walked past the rock could tell what it said.

What the two stories leave

Ulysses tied the rope to himself and it held for exactly as long as he was inside it. Ashoka tied the rope to his heirs, in the most permanent form available, with the reasoning included, and it did not hold at all.

You cannot precommit an institution. You can only precommit yourself.

A constraint written for other people is not a rope. It is a rule. Rules are held by whoever holds the pen, and the pen changes hands.

Which leaves the question the two stories were really asking. If a written constraint does not transmit, how does anything an institution believes survive the person who believed it?

My answer, and I offer it as a view rather than as a finding, is that it survives through cost that other people watched someone pay.

The mechanism is not mysterious. A document requires somebody to open it, and then to care about what it says, and neither of those things happens reliably once the author has gone. A story requires neither. People tell each other about the time a leader gave something up, on a specific day, when giving it up was expensive and avoidable, because that is the kind of thing human beings find worth repeating. The principle travels inside the story. It lasts precisely as long as the story does.

This is why the rule you enforce on other people has a short life and the one that visibly caught you has a long one.

The obvious objection

Some constraints plainly do survive in writing. Law does. Regulation does. Contracts do. Whole industries operate under rules that outlived everyone who drafted them, and nobody had to watch anyone suffer for it.

That is true and it does not weaken the argument. It locates it.

Written constraints persist when something outside the institution enforces them. A regulator, a court, a counterparty with a claim. What makes them durable is the external consequence. The writing only records it.

Underneath that sits a narrower distinction, and it is the one that matters here.

Writing transmits knowledge extremely well. It does not transmit obligation at all.

Ashoka’s stone did its job perfectly. When the script was finally read, nothing had been lost. His reasoning survived intact for two thousand years, in his own words, and we can read today exactly why he stopped making war. What did not survive was the bindingness. His descendants could read it and not be held by it. So can we.

He had no external enforcer. Neither does the principle you are proposing to leave behind at the end of your tenure. For anything an institution holds voluntarily, and that is most of what makes an institution what it is, writing down the obligation is the weakest available form of transmission. Writing down what the obligation produces is a different matter entirely, and it works.

Ropes and wax in an estate

Every organisation has ropes.

The change freeze that holds through the quarter regardless of who escalates. The deployment that cannot ship until a rollback has been executed rather than written down. The permission model that denies by default and cannot be waived by the person under delivery pressure. The data boundary that needs a named accountable executive to cross, and a record of who crossed it.

Look at the second of those again, because it is the same distinction in engineering form. A documented rollback is knowledge. An executed rollback is obligation, discharged, by someone, at a cost in time on a date when nobody wanted to spend it.

These are good things. They are ropes tied on a calm day, for a day that will not be calm.

Every organisation also has wax.

There is a plain way to tell them apart. Take any rule your organisation is proud of and ask one question.

Whose day does this make harder?

If the answer is never the person who wrote it, you are looking at an instruction, and it will last about as long as the person enforcing it.

The rule I wrote that caught me first

I have written before about invisible work. This is a different question. When I set a rule, who did it catch?

In the teams I have led, I made it a requirement that key design decisions are written down, that solution intent is captured and taken through review, and that architecture records live somewhere people can find them and argue with them.

That sounds like governance. It did not feel like governance, because it reached me before it reached anyone else.

It took away the thing I most wanted under delivery pressure, which is to decide fast and explain later. It put my reasoning in writing, in front of people entitled to disagree with it, at the moments when I was least sure. It cost me hours I did not have, on dates that were already fixed.

The records themselves did transmit. That is what records are for, and a team inheriting them does not have to repeat the reasoning that produced them. But the requirement to keep making them was never going to survive the way the records did. That part travelled differently.

What made it hold was not the requirement. Requirements are easy to write and easy to suspend. It held because people watched it apply to me on a date when it was expensive, and when suspending it was entirely within my gift.

I thought I was setting a standard. I was paying for one.

What I ask before I write a rule now

One question. Which of my own decisions does this take away?

If the answer is none, I have not made a commitment. I have issued an instruction, and I should expect it to leave the building with whoever is enforcing it. That is not a small matter for an institution that will one day have to explain to a regulator, or to a customer, why a boundary it published was not the boundary it kept.

Ashoka chose stone. It was the most durable thing available to him, and it carried his reasoning across two thousand years without losing a word. It carried none of the obligation, because obligation has never once survived in a medium.

An institution never inherits a rule. It inherits the memory of what the rule cost the person who kept it.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

On 18 November 2025, Cloudflare deployed a corrected configuration file across its network at 14:30. Its own published incident timeline records that all services were resolved at 17:06.

Two hours and thirty six minutes, with the cause already gone.

Every efficiency an institution buys is recorded on one side of the ledger. The load that same decision creates on the day the system is in trouble is recorded nowhere, because nobody has a unit for it.

The number that is not on the dashboard

A system has a capacity. That number is measured, reported and understood. It sits in the capacity plan and behind the sizing decision.

There is a second number.

In 2021, four engineers described a failure pattern they had observed across a decade of running systems at very large scale. Nathan Bronson, Abutalib Aghayev, Aleksey Charapko and Timothy Zhu called it metastable failure. Their model has three states.

In the first, load is low enough that the system absorbs a shock and returns to normal on its own. In the second, load is higher, the system is entirely healthy, and everything works. In the third, a shock has arrived and throughput has collapsed, and it stays collapsed after the shock has gone, because a feedback loop inside the system now sustains the overload by itself.

The middle state is where the argument lives. A system can sit there for years. It is not degraded. It is not struggling. Every metric reads normal, because everything is normal. The authors are explicit that many production systems are deliberately run in that state all the time, for the straightforward reason that it is far more efficient than the alternative.

Their worked example is a web application in front of a database. The database handles three hundred queries per second. Put a cache in front of it with a ninety per cent hit rate and the application serves three thousand. The advertised capacity is three thousand. The load below which the system would heal itself after losing that cache is three hundred.

A gap of ten times. One of those numbers is on the dashboard. The other only exists during a failure that has not happened yet.

That second number is obtainable. It is not observable. The distinction matters, because obtaining it means deliberately driving a system past the point where it can return on its own, and then watching whether it does. Almost nobody schedules that against an estate carrying customer money, which is why the number is usually absent rather than unknowable.

The efficiency and the exposure are the same purchase

The mechanism that sustains a failure is usually the thing installed to make the system better.

Retries mask transient faults, and multiply work at the moment there is no capacity to spare. Caches multiply throughput, and multiply the load arriving at the database when they empty. Detailed error handling makes an incident easier to diagnose, and consumes the resource that is already exhausted.

Cloudflare’s account of November is a clean example. Their bot management module preallocates memory for machine learning features, which is a performance optimisation. Preallocation requires a fixed ceiling. The ceiling was two hundred. Actual use was around sixty. A change to database permissions caused a query to return duplicate rows, the generated file went past two hundred, and the code path failed.

Nobody chose a two hundred feature limit. They chose preallocation. The limit arrived with it, unpriced, and sat there for years being harmless.

In the same incident, network latency rose because the debugging and observability systems consumed large amounts of processor time automatically enriching uncaught errors with additional detail. The tooling built to explain a failure was helping to sustain one.

The margin between recovering and not recovering is thinner than most capacity conversations assume. In a controlled reproduction published in 2022, the same researchers held the workload constant and varied only the shock. Ten seconds at seventy eight per cent loss of processor capacity produced a dip and a full recovery. Ten seconds at eighty per cent never recovered. Two percentage points decided it. Holding the shock at eighty per cent and shortening it by one second also produced recovery.

Four nights, many years ago

Many years ago I watched a batch estate come apart after a data migration.

The root cause was not subtle once it was found. The migration wrote a subset of records into the target in a state the downstream jobs had never been built to handle. Those jobs performed no validation at that boundary. They had never needed to, because for as long as anyone could remember the upstream had produced well-formed data, and that guarantee had never been written down. It was an assumption held in code, inherited by everyone who touched it afterwards.

So the run did not skip the bad records. It failed on them, and stopped.

That coupling had been in the estate for years. It had never mattered, because the conditions that would expose it had never arrived on an ordinary night. On paper the estate was within capacity, and on paper it always had been.

What stayed with me is not the first night. It is the second.

An overnight window is fixed. The work inside it is not. A run that does not complete leaves arrears, and the following night carries its own load and those arrears through the same window. The second night begins further behind than the first. The third begins further behind than the second.

By the second night the corrupted records had been found and corrected. The cause was gone. No new defect had been introduced. The estate kept failing because the thing driving it was no longer the bad data. It was the arithmetic of a fixed window carrying a growing debt, and the recovery runs were themselves part of the load. That is the sustaining effect, in a batch estate rather than a distributed service, with the same shape. It took several cycles, and a deliberate decision to cut back what the estate was asked to do each night, before the arrears cleared.

The migration decided when the failure started. It did not decide how long it lasted. That was decided by how much slack sat in a nightly window, settled years earlier by people making a reasonable trade between cost and headroom on days when nothing was happening.

None of them were wrong. None of them were asked the question.

The fix that became the amplifier

Resilience thinking assumes that remediation makes things better. It is not reliable.

Spotify had an incident sustained by retries. Afterwards, engineers added substantial logging to the error path, so that next time they would understand what had happened. In the following incident, that logging raised the cost of every retry, which added load, which caused more retries. The fix from the last failure was the amplifier in the next one.

The team had repaired their ability to explain the failure. The loop that produced it was untouched, and the explanation machinery was now inside it.

An engineering reader will already be reaching for the mechanism that exists for exactly this trade. Site reliability engineering uses an error budget: two teams jointly set, from a service objective, how unreliable a service is permitted to be over a quarter. It removes the politics from a negotiation previously settled by whoever argued best, and it is the most serious attempt the industry has made to put a number on this.

My reading is that it does not close the gap, and the reason is the denomination. An error budget is stated in unavailability already observed. It records how much failure has occurred. It does not say how far the system would fall, or whether it would return unaided. A service can sit comfortably inside its budget and one shock away from a state it cannot leave.

Worse, a healthy budget is evidence of a quiet period, and a quiet period is when the amplification is least visible. The budget then reads as permission to spend more of a margin nobody has measured. That is my extension, not Google’s. The same body of practice answers the problem a few chapters later, which is where this ends up.

The circular dependency

The institutional version of this argument is the one that reaches a board, and Cloudflare published it about themselves.

After two global outages inside six weeks, they declared a company-wide programme ranked above all other work. One of its three workstreams concerned neither configuration nor failure modes. It was the removal of circular dependencies.

Their account is candid. During both incidents their own security systems prevented team members from reaching the tools they needed. They are a security company, every tool sits behind authentication and fine-grained access control, and they say directly that this is right. It also slowed them down when speed mattered most.

The consequence reached customers. Turnstile, their bot verification product, sits on the login flow for the Cloudflare dashboard. When Turnstile became unavailable, customers without an active session could not log in to make changes at the moment they most needed to.

The control protecting the front door was served by the network that was down.

Nothing about that shape is specific to a technology company. A recovery path runs through incident tooling, access management, an approval workflow, a communications channel, and a small number of people who understand a system well enough to make a judgement at two in the morning. Every one of those dependencies is a sensible efficiency on an ordinary day, and invisible in a design review, because on an ordinary day it works.

The question I have taken from this is narrow, and I now ask it of any test I am shown. Did the system recover, or was it recovered? If the shock was removed by hand and the system was helped back, the test measured the shock. It did not measure the loop.

In fairness, and because a case that only flatters is not evidence: Cloudflare suffered a further outage on 20 February 2026 affecting bring-your-own-IP customers, while that programme was still running. Their assessment that the completed work would have prevented the two 2025 incidents is their own assessment of themselves.

You cannot measure it. You can bound it.

The 2022 paper states the relationship formally. The load a system can safely carry equals its normal capacity divided by the maximum amount by which work is amplified when the system is in trouble. Two terms. One is measured continuously. The other is not observable during normal operation.

It does not have to be.

The amplification factor is only an unknown if it is left to emerge. Capped by design, it stops being a discovery and becomes a decision.

The same paper puts it in one line: a retry policy with no cap leaves the system with effectively no stable region at all.

Cap the amplification, and write the cap down as a number. Google’s published practice uses two caps together. A per-request budget of three attempts, after which the failure passes to the caller. And a per-client budget, where a client retries only while retries run below ten per cent of its total requests. The first alone allows volume to grow to just under three times. The two together bring it to roughly 1.1 times. That is an amplification factor named and bounded rather than inherited. It assumes the operation is safe to repeat, which is its own design commitment.

Retry at one layer only. A rejected request is retried by the layer immediately above the one rejecting it, and by nothing higher. When a layer decides a request cannot be served, it returns an explicit instruction not to retry rather than an ordinary error. Without that rule each layer multiplies the one below it and the growth becomes combinatorial. One line of architectural standard, and it is checkable.

Decide in advance what gets shed. Google classifies every request into one of four criticality levels, from the most user-visible down to work where occasional full unavailability is expected. The classification is set as close to the customer as possible, propagates automatically down the call stack, and drives what is rejected first under pressure. The institutional translation is plain. What an institution stops doing on its worst day is either decided in advance, in daylight, by people with the authority to decide it, or it is settled at three in the morning by whoever is awake. Both are decisions. Only one is governance.

Default to the last good state rather than to nothing. Cloudflare’s answer to their own failure is that a system unable to read a new configuration should refuse it and keep the previous one, and where that is impossible, that each case is decided in advance on whether reduced functionality beats none. Had that existed in November, an unreadable file would have cost them real-time tuning of a detection model. It would not have cost them the network.

Take the recovery path out of the failure domain. They audited the tools needed for visibility, debugging and production change, and built backup authorisation pathways for eighteen services. Then they ran an engineering-wide drill on 7 April 2026 with more than two hundred people, on the reasoning that automation keeps a pathway working, but only practice builds the reflex to use it under pressure.

Making it survive the people who learned it

Every one of those is a rule somebody had to be taught by an outage.

A lesson living in the judgement of the engineers who were in the room has a decay curve. They move teams. They leave. The rule survives as folklore, then as a habit nobody can explain, then not at all. Three years later the same shape appears in a new service and nobody present recognises it.

Cloudflare took those lessons out of people’s heads and wrote them into a single internal standards repository, produced through a formal proposal process, in a fixed format: if you need this, do that, with the reasoning linked. It is mandatory across the entire codebase, and enforced automatically at code review, so a change that violates a rule is stopped there rather than found later.

One of their rules requires a service to validate that its upstream dependencies are in an expected state before it processes anything.

That is precisely the rule the batch estate did not have. It had been missing for years. No individual was ever going to be held to account for its absence, because no individual had ever decided it.

I wrote recently that the most durable work an institution does leaves no trace, and that this is exactly why it goes uncredited. The codified rule is how that work acquires a trace. The judgement stays invisible. The rule it produced does not. It has an author, a reason attached, and an enforcement point that does not get tired, does not leave, and was not in the room when the lesson was learned.

That is the difference between an institution that knows something and an institution that will still know it in a decade.

What this costs

An institution that cannot state its amplification factor is not running without risk. It is running with an unpriced liability, and the price is paid in duration.

Duration is what customers experience. Duration is what a board is asked about afterwards. And duration is not set by the size of the event. It is set by decisions taken years earlier, in ordinary conditions, by capable people optimising something sensible, none of whom were asked what the decision would cost on a day when the system was already in trouble.

Three questions are cheap to ask and uncomfortable to answer. What is the cap on how much extra work this system creates when it is already struggling, and is that cap written down anywhere. What does this system stop doing first, and who decided. And when we recovered last time, did the system come back, or did we carry it back.

None of them need a new platform. They need somebody to ask while nothing is happening, which is the only time the answers can still be changed.

Nothing is decided on the worst day. The worst day only collects.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Sources

Nathan Bronson, Abutalib Aghayev, Aleksey Charapko, Timothy Zhu. “Metastable Failures in Distributed Systems.” HotOS ‘21, ACM. https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf

Lexiang Huang, Matthew Magnusson, Abishek Bangalore Muralikrishna, Salman Estyak, Rebecca Isaacs, Abutalib Aghayev, Timothy Zhu, Aleksey Charapko. “Metastable Failures in the Wild.” OSDI ‘22, USENIX. https://www.usenix.org/conference/osdi22/presentation/huang-lexiang

Cloudflare. “Cloudflare outage on November 18, 2025.” https://blog.cloudflare.com/18-november-2025-outage/

Cloudflare. “Code Orange: Fail Small.” 19 December 2025. https://blog.cloudflare.com/fail-small-resilience-plan/

Cloudflare. “Code Orange: Fail Small is complete.” 1 May 2026. https://blog.cloudflare.com/code-orange-fail-small-complete/

Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, eds. Site Reliability Engineering. O’Reilly, 2016. Chapter 3, “Embracing Risk,” and chapter 21, “Handling Overload.” https://sre.google/sre-book/embracing-risk/https://sre.google/sre-book/handling-overload/

Your incident record is a complete list of the occasions on which prevention failed. There is no corresponding document for the occasions on which it worked.

That absence is not a gap in reporting. My argument in this piece is that it is one of the reasons technology organisations underprice the work that keeps them standing, and that the cost surfaces later in a change budget as remediation nobody planned and nobody can trace back to a decision.

The work is done at the start. The credit is handed out at the end.

Most of what decides whether a system will fail is settled early. During discovery, when someone establishes what the business rule actually is rather than what the current system happens to do. During architecture, when a boundary is placed correctly. During design, when a failure mode is anticipated and closed before any code exists.

Credit is distributed at go-live, months or years later, with different people in the room. The team that finished the last feature is present and visible. The person who removed the problem that would have made the launch impossible has moved on, and there is no artefact recording what they removed.

I have watched this play out in enough organisations to be confident it is structural rather than a failure of generosity. That distinction matters. A mechanism can be redesigned. A character flaw cannot.

There is a name for this, and it is twenty-five years old

Nelson Repenning and John Sterman, both at MIT Sloan, published a paper in California Management Review in 2001.

“Nobody Ever Gets Credit for Fixing Problems that Never Happened”

The line was not theirs. They took it from an engineer at an automotive company during fieldwork.

Their model is austere. An organisation facing a performance gap has two options. It can work harder, which raises output immediately and only while the effort continues. Or it can work smarter, raising the capability of the process so every subsequent hour produces more, with the return arriving after a delay.

Because organisations rarely hold spare capacity, pressure to work harder takes its hours from improvement. Capability erodes slowly. The gap widens. Pressure rises again. They call this the capability trap, and its defining feature is that working harder is better-before-worse, while working smarter is worse-before-better.

Why experience teaches the wrong lesson

People assume cause and effect sit close together in time and space. A defect gets attributed to the operator standing next to it rather than to a training programme whose influence is delayed and unobservable. That is the fundamental attribution error, and it explains why credit and blame both land on whoever is nearest the visible outcome.

Then it compounds. A manager applies pressure and throughput rises. They cannot see how much of that rise came from real additional effort and how much came from improvement work being quietly dropped. Repenning and Sterman work an example where a manager needs six hours per person per week, gets two from genuine effort and four from abandoned improvement, and concludes that pressure produced all six. They call this the self-confirming attribution error. The manager overstates the effect of their own approach by up to a factor of three, and receives immediate evidence that their people were not trying hard enough.

The error is not corrected by experience. It is manufactured by experience.

One consequence follows directly, and it is the least comfortable finding in the paper. Organisations dependent on firefighting reward and promote the people who rescue troubled work. Over time, senior management comes to consist of those people, who then favour others who resemble them. The trap stops being a question of resource allocation and becomes the composition of the leadership team.

None of this is an argument against firefighters. Recovering a service under pressure is genuinely difficult, and the people who can do it are good at something rare. The failure sits in the ratio and in the visibility, not in them.

Why a chemical plant is the same estate you run

The paper’s central case is Du Pont, and the finding is not the one most people expect.

In 1991 an internal benchmarking study found Du Pont was spending 10 to 30 percent more on maintenance per dollar of plant value than the best performers in its industry. Uptime ran 10 to 15 percent lower. More money, worse availability.

The problem was never the size of the budget.

The mechanism transfers exactly, so it is worth following slowly.

When critical equipment breaks in a chemical plant, it has to be fixed. That work is not optional and cannot absorb a cost reduction. So the reduction lands on planned maintenance, training, and equipment upgrades, because those are the only things that can be deferred without anyone noticing this month. Breakdowns then rise. Mechanics are reassigned from planned work to repair work. Breakdowns rise further. As uptime falls, operators become less willing to release equipment for scheduled maintenance, because they are already behind.

Now change the nouns.

Production incidents have to be resolved. That work cannot absorb a cut. So the cut lands on the design work, the discovery, the platform investment, and the upgrade nobody is asking for yet. Defects rise. Engineers move from building to supporting. Availability falls, and the appetite to take a service down for the work that would fix it properly falls with it, because the team is already behind.

Your estate is the plant. The nouns changed and the loop did not.

Du Pont’s response ran through the 1990s. At the plants that adopted it, equipment reliability improved at roughly twice the rate seen at comparable plants that did not, and direct maintenance costs fell by around a fifth while rising at the comparison sites.

A decade with nothing to show for it

There is a version of the same thing in software, described from the inside.

In April, Werner Vogels wrote about the AWS Lambda networking team, whose work over roughly a decade produced no launch, no announcement, and nothing a customer could point at. Marc Olson’s description, quoted in that piece, is of converting a propeller aircraft into a jet while it stays in the air.

When the team building Aurora DSQL later needed networking of that grade, they did not receive a document explaining how to build it. The Lambda team had packaged the whole thing as a service that DSQL installs and runs, with Lambda continuing to own it and issue new versions, so every subsequent improvement reaches DSQL without DSQL doing anything at all. Vogels reports it saved them months.

Ten years of work whose entire visible output was that another team did not lose time.

Had that same team instead spent the decade recovering from outages, every quarter would have contained something to show for it.

The decisions I argued for on the wrong grounds

Over more than two decades I have made this argument from the inside repeatedly. Looking back at it now, the pattern is not that I lost those arguments. It is that I almost never won them on the grounds that actually mattered to me.

The clearest instance was building a single credit cards capability on one platform, to be used by more than one business unit rather than each unit standing up its own.

The resistance was not architectural. It was about change cadence. A shared platform means agreeing when changes land, and a business unit that currently controls its own release schedule is being asked to surrender that control in exchange for something it cannot yet see. Their objection was rational. Mine was a promise.

That argument took years to settle, and what I had been buying only became visible when the second business unit was onboarded. By then the capability existed and the operating model was proven, so the work was onboarding rather than building. Nobody in the room at that point was thinking about a platform decision taken years earlier. They were looking at the onboarding, which is exactly where a reasonable person would look.

A second instance was building an abstraction over third party integrations. The business model depended on assembling capability from several external providers, which made provider change a permanent condition rather than an exception. The layer sat between the business capability and the providers, so one could be added, replaced or renegotiated without rewriting what sat above it. What I was buying there was a series of rewrites that never took place, and a rewrite that does not happen leaves nothing behind.

Three others follow the same shape. Domain Driven Design alongside an event driven approach, which splits an estate into areas that each own a defined part of the business and has them announce what has happened rather than reaching into each other’s data. What I wanted was the coordinated three-team release that would no longer be necessary. A genuine build and run model, where the team writing the software also operates it and is called when it breaks, set against an operating model built on separation and heavy change control. What I wanted was the defect that does not survive, because the person who wrote it now sees it fail. And choosing a cloud provider’s own managed services over tooling designed to run anywhere. What I wanted was the delivery time not spent proving that the portable option was still immature.

Not all of these took hold. The domain approach became the working model in parts of the estate and never reached others, which is its own evidence about how long this work takes and how easily it stalls.

I should be precise about what I was doing in these rooms, because there is a version of this story that sounds better than the truth. I did not conceal my reasoning. Modularity, ownership, capability, resilience. I believed all of it and all of it was real.

What I did was argue the parts that could be evidenced, and leave out the benefit I was primarily buying.

An absence cannot be put into a business case.

When each of these landed, the credit went where credit goes. To the delivery.

One concession on the last of them. The dependence argument was not wrong. Vendor concentration is a real exposure and it was raised in good faith. It was being priced at some number, while the delay on the other side of the decision was being priced at zero, because nobody had a way to write down a delay that had not occurred.

What actually changes it

Exhortation does not. Every organisation already agrees that prevention beats cure, and the agreement changes nothing, because the manager’s own evidence keeps pointing the other way.

Three mechanisms are more promising.

1. Write down the counterfactual before the outcome exists

An absence can only be credited if somebody recorded what was expected to be present. A design record that names the specific failure being closed off, in terms concrete enough to be wrong, converts prevention into something with a stated before and after.

This is the mechanism I failed to use in every decision described above. It is also the reason none of them appears in any record of achievement, including my own.

2. Ring-fence the dividend

Repenning and Sterman observe that in the programmes which held, leadership explicitly reallocated the capacity freed by improvement back into further improvement.

If prevention work frees six weeks, and those six weeks are absorbed into the next delivery target, the loop has been turned from virtuous to vicious by an act of apparently sound management.

3. Warn the board that the cost gets worse first

This is the mechanism most programmes die on, because the warning arrives after the cost does.

BP’s Lima refinery in Ohio was deep in the trap by the early 1990s, lagging other US refineries, with BP weighing sale or closure. The improvement programme started in 1994. It was not a leadership initiative. The original champions were an equipment specialist, a maintenance training supervisor, and an engineer.

Maintenance costs rose by roughly 30 percent in the first six months.

That is the point at which this work normally gets cancelled, and a board cancelling it is acting reasonably on the information in front of it. Lima’s management held, because they had already lived through that curve inside a simulation and knew it was coming.

By 1998, the average time a pump ran before failing had moved from 12 months to 58. Reported new value was around $43 million a year, against a programme cost near $320,000.

Two weeks. Five thousand dollars. Eight years.

A team at Lima eliminated butane flare-off, saving about $1.5 million a year. The work took two weeks and cost about $5,000.

They had known about the problem, and the solution, for eight years.

They had the expertise. Most of the materials were already on site. What was missing was any belief that the time existed, or that it was theirs to take.

Both cases undercut themselves

Leaving this out would make the piece an advertisement.

Du Pont’s programme produced real results and was then weakened by company-wide cost-cutting that drained the reinvestment it depended on. Winston Ledet, who led it, took early retirement.

BP announced its intention to sell Lima in 1996, then announced it could not find a buyer and would close it. Clark USA bought the refinery in 1998 for $215 million.

The work plausibly made the asset saleable. It did not make it safe.

Prevention work does not protect you from a decision taken two levels above you. It changes what that decision is choosing between.

Where the incentive cannot hold, a standard has to

There is one place where preserving work that produced no visible output has already been made non-optional.

The PRA’s supervisory statement SS1/23 on model risk management took effect in May 2024. Principle 1.2 sets out what a firm’s model inventory must contain. Alongside the models in use and the models in development, it requires the models that have been decommissioned.

A footnote gives the reason. The rationale behind a retirement may inform how future models are developed, and the retired model may later be useful as a challenger.

Read narrowly, that is a model risk provision and nothing more. My reading of it, and I am labelling this as a reading rather than a statement of the PRA’s intent, is that a supervisor has looked at work whose entire value sits in a future that has not happened, and made keeping it a condition rather than a preference.

Four questions I have started asking myself

None of these need a programme behind them.

What did I expect not to happen? For any design decision I made this year, can I state the specific failure I believed it would prevent? If I cannot state it now, I will have no way of knowing in three years whether it worked, and neither will anyone else.

Where did the freed capacity go? When prevention work gave a team time back, was that time reallocated deliberately, or absorbed into the next target? I have let it be absorbed more than once and called it pragmatism.

Whose earlier decision made this possible? When I recognise a delivery, do I trace it back past the people standing in the room? It takes about two minutes and I do not do it often enough.

What have I known how to fix for years and not funded? The Lima team held the answer to a $1.5 million problem for eight years. This is the question I find hardest, because the honest answer is usually a list rather than an item.

None of this is free. Prevention work spends delivery capacity now against a saving that lands in a later budget, often under a different leader. That is exactly why it has to be funded as a decision rather than justified as a return, because the business case cannot carry an absence and never will.

You do not notice a floor until it gives

I do not think this is only a technology problem, and I am not certain it is only an institutional one.

Good architecture is invisible. So is a culture that works, and a way of working that fits the work being done. None of them announces itself. What registers is their absence.

A team with real trust in it feels like nothing at all. People say what they think, which seems unremarkable until you spend a month somewhere nobody does. A house with sound foundations is simply a house. Nobody stands in a room admiring them. They are noticed in the one year a wall cracks, and never in the forty before it.

That is the difficulty with foundations of any kind. Their success is silence, and silence is the one signal most organisations hold no instrument for.

Every institution can name the person who saved it. Almost none can name the person who made saving it unnecessary.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

You can evidence that a control was implemented. Can it evidence that the control still does what it was built to do?

Those are two different questions. Only one of them is now being asked, and the answer increasingly shapes how much capital a supervisor requires the institution to hold.

There is an answer available. It was developed over two decades, in three industries with no connection to financial services.

Three industries that moved from testing to proving

Compilers, the software that turns human code into machine code. Every application an institution runs, from a customer-facing app to an overnight batch job, was translated by a compiler before it ran. If the compiler is wrong, every program it produces is quietly wrong too, in ways the original developer never wrote.

A group of researchers built a compiler called CompCert with a mathematical proof attached. For any legal input program, the machine code it produces will behave the way the source code says it should. Other researchers then spent years trying to break it, running a tool that generates random programs and hunts for miscompilation. In the other production compilers they tested, GCC, LLVM and others, the tool found real bugs. In the parts of CompCert covered by the proof, it found none.

Not fewer. None.

Flight-control software. In an aircraft, a runtime error means the software met a situation it did not know how to handle and stopped. On the ground that produces an error message. In the air it does not. Airbus adopted a tool called Astrée, which analyses the whole control program and produces a mathematical guarantee that a defined class of runtime errors cannot occur in any state the code can reach. It has been used across a range of Airbus aircraft, including the A380.

Cloud infrastructure at scale. When a storage system serves millions of customers at once, the number of possible interactions between concurrent operations runs far beyond what a conventional test suite can cover. AWS engineers built a lighter-weight approach for one of their storage systems, checking its behaviour against a simple reference model across an enormous space of input sequences and system states. It is a deliberate trade. Less complete than a full mathematical proof, far cheaper to build and maintain, and strong enough to surface classes of bug that ordinary testing leaves sitting there.

That trade matters, because these three are not one technique. They are a family, running from full mathematical proof at the expensive end to lightweight modelling at the practical end. The choice between them is an engineering judgement about cost and consequence, not a purity contest.

Three organisations with almost nothing in common. Each moved from testing to proving at the point where the cost of being wrong stopped being proportionate to the cost of finding out.

Why this now matters to a regulated institution

The FCA has been reshaping its supervisory approach since the Consumer Duty came into force in 2023, and 2026 has brought its clearest form yet. The regulator has moved from asking whether a firm implemented a rule to asking whether it can evidence the outcome that rule was written to produce. A firm can deliver every required disclosure on schedule and still fall short, if the data on customer understanding tells a different story.

DORA has moved through a parallel shift on a shorter timeline. It came into force in January 2025, and supervisors spent that first year testing readiness largely on paper. That phase closed in early 2026. Supervisors now examine how an institution manages a real incident, oversees an actual third party, and holds up under realistic testing.

Where those examinations raise concerns, they feed into the prudential review. That review looks at each institution and decides how much capital it must hold against its risks. Alongside the baseline requirement, supervisors can set an additional institution-specific layer, known as a Pillar 2 add-on, where they judge the risk profile warrants one. Persistent distance between what an institution has documented and how it is actually running now sits inside the picture that shapes that judgement.

So the line runs directly from how a leader answers a supervisor to how much capital the institution carries.

Both regulators are asking the same underlying question. Can you still explain why this control exists, and can you show that it is holding?

That is the proving standard, applied to leadership.

Two places to apply it

Example one. Interest calculation.

Interest calculations are typically assured through sampling. Choose a set of accounts each month, recompute what the interest should be, check the two figures agree. This works well for the cases the sample includes, and it has been the standard approach for years for sound reasons. Cost, feasibility, and a shared understanding across industry of what reasonable assurance has meant in practice.

The cases a sample tends to miss sit on the edges. An account crossing a rate-tier boundary mid-cycle. A leap-day accrual on a product that posts interest monthly. A negative-rate period on a deposit product designed before negative rates were plausible. A customer who moved between two products on a day when the calendar rule and the posting rule interact awkwardly.

Each of those is a single line in policy. Each is easy to miss in a sample of ten thousand accounts, because perhaps two hundred customers are exposed to it. Too few to surface reliably. Enough to matter when a supervisor asks.

Applying the proving standard here is narrower than it may sound. Proving that every account is correct forever would require the input data to be correct too, and data quality is a separate discipline with its own controls. What can be proved is the calculation engine itself. Given any legal input, it produces the answer the policy specifies. Every rate, every balance, every day-count convention, every combination of corner cases, considered exhaustively rather than sampled.

The value to a leader is concrete. When a supervisor asks whether the calculation holds for the customer on a product transition, in a leap year, at a negative rate, at a tier boundary, there is an answer that does not depend on whether that customer happened to fall into last month’s sample.

Example two. Access when someone leaves.

Every institution has a policy for revoking access when a person leaves. The literal question a supervisor asks is whether that policy exists. The substantive question is whether the person actually loses access to everything, on the day they go.

This is harder than it looks because access is not granted in one place. The identity system controls the front door and is usually clean. Beyond it sit the systems that cache credentials for performance, the service accounts a team created three years ago and never documented, a vendor portal a small group reaches through a shared password held in a team notebook, and a legacy application where access flows from membership of a group refreshed overnight from a source list. Remove the leaver from the identity system and the front door closes cleanly. Every other path depends on a different system doing something specific, in the right order, inside the right window.

Applying the proving standard here means building an explicit model of that whole flow. Every system that grants access, every path a credential can travel, every point where a cache might still hold a valid session. Then demonstrating that no reachable state in the model lets a leaver back in.

One caveat belongs here, and it is the same caveat that applies to CompCert and Astrée. A proof covers the model, not the world. If a system was left out of the model, the proof says nothing about it, and the discipline of building the model is often where the real value sits, because that is the point at which the forgotten vendor portal surfaces.

The value to a leader is again concrete. When a supervisor asks a DORA-style substantive question about joiner-mover-leaver control, there is a modelled answer covering every path, and a documented boundary showing what the model includes.

What a leader does with this

The full techniques behind CompCert, Airbus and AWS are formal methods, and they need specialist skill. A leader does not have to bring that. A leader brings the standard, and the discipline of applying it in miniature to the questions that carry the most consequence.

The discipline has three parts. Ask a control, periodically, why it still exists. Ask what it would fail to prevent if it stopped working tomorrow. Ask what would show up first if that had already happened. A control that can answer all three in language a board member follows is a control the institution still understands.

Applied over time, that discipline builds something specific. A stock of substantive answers, held live across the controls that carry the most weight, ready without preparation because they were never allowed to go quiet.

It is also what supervisors are now inviting us to bring. The FCA’s outcome test and DORA’s substantive review are both, at heart, requests for that stock of live answers. Where they are already in place, the prudential review that sets any Pillar 2 add-on has one less reason to reach for one. The leader gains clearer running command of their own estate. The supervisor gains the evidence they were looking for, in the form they were looking for it in.

A proof is not something you file once. It is something you have to keep being able to give.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

There is a decision every technology leader makes more than once. A dependency sits underneath something important. Nobody fully understands why it behaves the way it does. The safest looking choice is to leave it alone and build carefully around it instead.

That decision is never free. The budget for it is never approved by anyone. It shows up later, in an audit finding, a vendor invoice nobody expected, a customer complaint that takes three teams to trace back to a system nobody had touched in years. The cost does not disappear because the decision was never written down. It just waits for someone else to find it.

What Changes While You Wait

Three forces reshape a system while its owner hesitates, and none of them ask permission first.

The first is the workaround. Every quarter a system stays untouched, someone builds around it instead of through it. A spreadsheet becomes the reconciliation. A vendor tool becomes the record for a class of work the original system was meant to handle. Nobody calls it architecture at the time. However, when the next transformation gets scoped, the spreadsheet is in the critical path, and the vendor tool cannot be removed without a project of its own.

The second is memory. The people who understood why a system looks the way it looks are retiring, moving on, or simply forgetting. What one generation held as tacit knowledge becomes what the next generation cannot recover at any price.

The third is newer, and harder to see coming. AI is being embedded into systems whether their owners sanctioned it or not. Vendors ship it as a feature update. A workflow tool starts making decisions nobody in compliance was asked about. Most institutions, asked today which of their vendors use AI, on what data, and who is accountable for the outcome, cannot answer with confidence.

Immobility does not protect a system. It reshapes it, without you in the room.

What Deliberate Change Looks Like

Two of Amazon’s own 2025 decisions are worth examining closely, not simply admired.

The company rebuilt the inference engine behind Bedrock, a system it named Mantle, using a small team working to a bounded scope rather than a large one working to an open brief. Amazon says the original estimate was forty engineers over a year, and that six delivered it in seventy six days. I take a number like that with real caution, especially arriving in the same season as headlines about reduced corporate headcount. What holds up under closer reading is not the multiple. It is the design choice sitting underneath it. Mantle was built with zero operator access, meaning there is no technical path for an Amazon engineer to reach the customer data running through it. That is a governance decision built into the architecture itself, not a policy written down and hoped for.

That same year, Amazon rearchitected Alexa, a decade old system serving six hundred million devices, moving it from scripted commands to something able to plan and act across tens of thousands of services using large language models. The hard constraint was never the model. It was doing this without breaking a single existing partner integration, and without missing the two second response window a voice assistant needs to feel instant rather than sluggish. Bedrock and Alexa+ share the same shape. Decide what must not break. Bound the scope around that decision. Then move.

Banking has its own version of this story.

In 2014, Piyush Gupta watched Alibaba issue loans and move money for millions of customers with no branches at all. He chose not to build an innovation lab beside DBS and leave the rest of the bank untouched. He chose to change how the whole institution worked, starting with culture, not with a system.

The clearest evidence of that choice was not a piece of technology. It was a format DBS called Process Improvement Events. Two hundred and fifty of them were run over the following years. Each one pulled the people who actually did the work, across functions, into a room for three days. Day one was spent mapping the process as it actually ran, not as anyone assumed it ran. By day three, the redesigned process had the sign off of whoever could actually approve it, sitting at the same table, rather than waiting on a steering committee that met once a quarter. Outsourced development gave way to an in-house engineering organisation over the same period, growing from fifteen percent of technology staff to eighty five percent within a decade. Both changes point to the same underlying decision. The transformation ran through ownership and authority long before it ran through any platform.

By 2019, Harvard Business Review had named DBS one of the ten most transformative organisations of the decade. Euromoney named it World’s Best Bank more than once.

A separate finding about DBS deserves space of its own, not as a rebuttal to the story above. Between 2021 and 2023, DBS suffered a run of digital banking outages. Singapore’s regulator raised the bank’s additional capital requirement for operational risk to 1.8 times risk weighted assets, roughly one point six billion Singapore dollars by MAS’s own account, and paused non essential IT change for six months while DBS rebuilt its recovery capability. Further disruptions followed in 2025 and into 2026.

I am not claiming the transformation caused this. I have found no evidence that it did, and no one else appears to have found any either. The finding says something narrower. Operational resilience is its own discipline, built and renewed on its own timeline, never a by-product of cultural change or a well-earned award.

Reinventing an institution and keeping it resilient are two different disciplines. Progress in one does not finish the other.

That discipline holds whether an institution transforms or stays still. The real choice was never between risk and no risk. It is between the risk of standing still and the risk of moving, and resilience has to be built for either one.

The Pattern I Know From the Inside

I have made the safe looking choice myself, more than once, in different roles, on different systems. The shape is always the same. A dependency looks too fragile to open. The blast radius feels unclear enough to justify waiting. So I waited.

The system never waited with me. An unrelated event, a vendor decision outside my control, a platform consolidation nobody had scheduled around my caution, forced the change anyway. What I believed I had protected by waiting turned out to be a problem I had only postponed and made more expensive in the meantime. The risk I thought I was avoiding did not disappear. It went underground, and it grew there, quietly, until something else finally forced it into the open.

Therefore the honest question is not whether a system is too risky to touch. It is who gets to decide when it changes, and on what terms.

Someone always pays for the years you waited. It is rarely the person who chose to wait.

The system you are afraid to change is not standing still while you decide. It is already choosing, without you.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Every technology leader inherits an estate. The real cost of that estate is never what it does today. It is what nobody has re-examined since the day it was built.

A rule starts as a decision. Someone weighs a trade-off, writes it down, and moves on. Over time the decision stops being a decision. It becomes a fact of the system, repeated by people who were not in the room when it was made, defended by people who never had to justify it, and eventually treated as something closer to physics than to policy.

Once that shift happens, ownership disappears with it. A decision can be revisited by whoever made it. A fact of the system belongs to no one, and that gap does not stay abstract for long. It sits on the balance sheet as unpriced risk, and on the other side of the counter as a limit a customer cannot get anyone to explain.

When a Decision Becomes a Fact

I have watched this play out in two directions, more than once, across more than one organisation.

In the first direction, a business chose a limit. A transfer ceiling, a threshold on a transaction type, a rule written for a genuine reason at the time. The reason mattered less as the years passed than the label attached to it. Somewhere along the way, in conversation after conversation, the limit stopped being described as a business decision and started being described as a system limitation.

Language did it quietly, on its own.

A business decision sits with a business owner who can change it on a Tuesday. A system limitation sits with an engineering programme, a business case, and a queue. Nobody voted to make the rule harder to change.

In the second direction, the limitation was real when it was set. Interface specifications built for mainframe systems, where every byte in a message carried a real cost in storage and transmission, and every field length was a negotiation nobody would need to have on today’s infrastructure. Those specifications shaped how much a customer could type, how a name was stored, how a value was represented.

The infrastructure that justified those choices has been replaced twice over. The specification has not. Nobody revisits it, because revisiting it requires asking a question that sounds almost naive in a room full of experienced people: is this still true. Naive questions are the ones institutions are worst at tolerating, and the ones they can least afford to stop asking.

The Cost Nobody Sees Coming

Both directions cost the same thing, even though they look opposite. A customer today still meets a limit calibrated for a threat model, or a hardware constraint, from a decade that no longer exists. A board approves an investment case built to work around a limitation, without anyone asking whether the limitation was ever actually load bearing.

The exposure does not show up as an incident. It shows up as a ceiling nobody remembers building.

This is the same trap that shows up at a larger scale in mergers and acquisitions, where research spanning decades puts the failure rate to deliver promised value somewhere between seven and nine in ten. Rarely because the deal logic was wrong. Usually because someone assumed the acquired estate would behave the way the data room said it would, and nobody revisited that assumption once integration actually began.

The Discipline Already Exists

Large organisations already know how to build the discipline this problem needs. It already exists, just pointed somewhere else.

Access recertification exists for exactly this reason, to stop entitlement from rolling forward by default and to force someone to re-approve what a person can touch, on a schedule, whether they asked for it again or not. Yet auditors have learned to distrust a recertification cycle that shows full completion and zero revocations over twelve months. That pattern is not evidence of a clean estate. It is evidence that nobody actually looked.

The review happened. The scrutiny did not.

Multiply that gap across a large estate for long enough, and it stops being a control question. It becomes a capital one.

Some systems are now built to refuse this failure by design. In Claude Code’s architecture, resuming a paused session, or handing work to a subagent, does not carry the original permissions forward. Trust is rebuilt from the current context every time, not inherited from the last one. It is a narrow, technical form of trust, permission to touch a file, run a command, call a network address. However, the principle behind it scales far beyond that narrow case.

The paper does not put it this way. I do, because that is what the choice means once you take it out of engineering and put it in front of a leadership team: not a security feature, but a leadership position, written into the design before anyone had the chance to argue with it in a meeting.

What This Is Not Asking For

None of this is an argument for re-litigating every rule in the estate. Most of them are still true, and re-opening all of them is its own way of getting nothing done.

It is an argument, therefore, for re-examining the ones a leader is about to defend, extend, or build a five-year roadmap around, at the exact moment authority for them changes hands. Not constant scrutiny. Scrutiny at the point where someone is about to inherit the consequence without inheriting the reasoning.

An institution does not get that discipline by accident. Someone has to build it in on purpose, the way those designers did, and then hold it on the day a team asks to skip the review because the deadline is tight and the answer has always been yes before.

The most expensive thing an institution inherits is the question nobody asked when the decision was first made.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

The productivity gain from AI tools is the easiest number in the building to measure. The judgment your organisation lost while gaining that productivity has no dashboard, no metric, and no owner.

Every quarter, the gap between what an institution produces with AI assistance and what it can genuinely evaluate widens. That gap surfaces when a regulatory review demands an explanation the organisation cannot give, when an architectural decision proves wrong and nobody can explain why it was made, or when an incident reveals that the people responding no longer understand the system deeply enough to diagnose it.

Two modes. One tool. Two outcomes.

In January 2026, researchers at Anthropic published a randomized controlled trial. Fifty-two junior software engineers were asked to learn a new programming library. Half used AI assistance. Half coded manually. The AI-assisted group scored 17% lower on comprehension tests. Nearly two letter grades. They did not finish meaningfully faster.

The finding has been widely covered. The detail that changes the argument has not.

The researchers found that how someone engaged with the tool determined what they retained. Engineers who used AI to ask conceptual questions, to understand why the code worked the way it did, scored 65% or higher on comprehension. Engineers who delegated code generation to the tool scored below 40%.

Same tool. Same task. Two modes of engagement. Two very different outcomes for the organisation that employs them.

In the previous post, I described two modes of thinking that appear wherever technology decisions are made. The System SME iterates on what exists. They know the current system, they can extend it, they can make it do more of what it already does. The Architect questions whether the work belongs where it is being placed. They evaluate the output against the problem space, not the immediate requirement.

The Shen and Tamkin study did not use those terms. However, the parallel is direct enough to be worth drawing. Delegation mode is System SME mode applied to a tool. Accept the output. Iterate. Move on. Conceptual inquiry mode is Architect mode applied to a tool. Interrogate the output. Understand the reasoning. Develop the capacity to evaluate whether what the tool produced is correct.

The institutional question is which mode the organisation is designing its AI deployment to amplify.

Almost every deployment I observe amplifies System SME mode. Engineers are given tools to produce faster. Architects are not given tools to evaluate better, to test assumptions at speed, to model consequences before they compound. The investment goes entirely into acceleration. The judgment that makes the acceleration trustworthy receives no equivalent investment.

The supervision loop

The reasonable challenge is that we have accepted comparable trade-offs before. Calculators replaced mental arithmetic. Satellite navigation replaced knowledge of routes. In each case, the skill loss was absorbed and the world carried on.

The difference is the supervision loop.

A calculator removes arithmetic. You do not need arithmetic to verify the calculator’s output. You check the number. Satellite navigation removes route memory. You do not need to remember the route to verify you have arrived.

AI-assisted engineering and architecture remove comprehension and judgment. You do need comprehension to evaluate whether AI-generated architecture is sound. You do need engineering judgment to supervise AI-generated code at scale. The skill being displaced is the same skill required to verify the output.

When the supervision loop is broken, the organisation has no reliable way to distinguish good output from output that merely looks good.

The speed continues. The quality signal degrades. The people who would have noticed are the ones whose judgment was never developed.

The trajectory

The speed is accelerating faster than the judgment.

In June 2026, Anthropic’s research arm published data showing that more than 80% of the code merged into their own production codebase is now authored by their AI tool, Claude. The typical engineer merges eight times as much code per day as in 2024. The same paper noted that large performance gaps persist when it comes to the AI exercising judgment in choosing goals. This is vendor self-reporting. However, the pattern it describes is visible across the industry.

Anthropic named the underlying dynamic in an earlier internal study of 132 of their own engineers and researchers, conducted in August 2025. They called it the paradox of supervision. Effectively using AI requires supervision. Supervising AI requires the very skills that may atrophy from AI overuse. A senior engineer in the study observed that they use AI primarily in cases where they already know what the answer should look like, a capacity they developed by doing engineering without AI assistance. Their concern was for those earlier in their careers who may never build that capacity at all.

At the 2026 MIT Sloan CIO Symposium, the term “AI atrophy” entered the vocabulary of senior technology leaders. The conversation is happening. However, it is framed as an individual concern. How do we keep our people sharp? How do we encourage critical thinking?

The structural question sits one level above. How does the organisation design its AI deployment so that judgment is accelerated alongside execution?

The pattern I have seen before

I have been inside this pattern before AI tools arrived.

When I proposed Domain Driven Design for a significant new platform build, there was substantial resistance. Various parts of the organisation had attempted DDD in the past without success. The resistance was earned. The understanding of what a domain model required, and the readiness to work within one, was not where it needed to be.

The earlier attempts had adopted the “what” without investing in the “why.” Teams could draw domain boundaries. They could not explain the reasoning behind them. They operated in System SME mode on the domain model itself. They inherited the structure without developing the judgment to question it or adapt it when the context changed.

The work that made the difference was years of deliberate investment in helping people understand why a boundary sat where it sat, why a capability belonged in one domain and not another, why the reasoning mattered as much as the result. That is Architect mode applied to an organisational transformation. Building the capacity to evaluate the model, challenge it, and carry it independently.

After multiple years, the platform build succeeded. More importantly, the organisation started adopting the approach more widely without me carrying it.

That independent adoption was the proof. The judgment had transferred.

The organisation could hold the model, question it, and adapt it without the person who introduced it in the room.

AI tools are following the same path at higher velocity. Organisations are adopting the “what.” They are deploying tools, measuring output, celebrating speed. Very few are investing in the “why.” Very few are designing their deployment so that the people using the tools develop the judgment to evaluate what the tools produce. The failure mode is the same. The velocity makes it harder to catch.

Both. Not one at the expense of the other.

The answer is not slower adoption.

The Shen and Tamkin data shows the path. The tool supports both modes of engagement. Conceptual inquiry, Architect mode, retains comprehension and develops judgment. Delegation, System SME mode, erodes comprehension and accumulates dependence.

What does designing for Architect mode look like in practice? It means requiring teams to articulate the reasoning behind AI-generated output before accepting it. It means using AI to generate multiple architectural options and having the team evaluate trade-offs rather than taking the first output. It means treating AI deployment as a transformational programme that invests in the “why” alongside the “what,” the same investment that determines whether any major change, DDD, platform migration, operating model shift, succeeds or calcifies into something nobody can explain.

The organisation that designs its AI deployment to accelerate Architect mode alongside System SME mode gets both speed and judgment. Engineers who use the tool to interrogate, to understand, to question retain the capacity to evaluate what the tool produces. Architects who use the tool to test assumptions, model consequences, and pressure-test designs gain speed without losing the judgment that makes the speed safe.

The organisation that designs only for System SME mode gets speed. And an invisible deficit that widens until it becomes visible in the worst possible way.

Every technology leader deploying AI tools is making this choice. The question is whether they are making it deliberately.

Speed without comprehension is a debt the organisation repays under pressure.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Who drew the boundaries? And what motivated them?

Melvin Conway observed in 1968 that systems mirror the structures of the organisations that build them. That observation describes what happens. This post examines why.

In most large institutions, the cost of boundary decisions drawn for the wrong reason does not appear on any balance sheet. It surfaces years later as remediation programmes, integration rework, and platform consolidation that consume change capacity for years. The institution calls it complexity. In my experience, it is more often a structural liability created by boundaries that were never questioned.

Two modes of thinking

There are two modes of thinking that determine how boundaries get drawn in any technology organisation.

The first is the System SME. Deep knowledge of a specific system, its constraints, its history, its behaviour under load. A System SME inherits the system and iterates on it. They know where it breaks, what it tolerates, and how far it can bend. This knowledge is essential. It is hard-earned. And it is, by definition, scoped to the system they know.

The second is architectural thinking. The wider view. Why does this boundary exist? Does it serve the domain’s need or the org chart’s convenience? What will the downstream consequence be in three years if the boundary stays where it is?

Both modes are necessary. An architect without System SME depth builds abstractions that do not survive contact with reality. A System SME without architectural challenge optimises within boundaries that may be serving the wrong master. The problem surfaces when an organisation defaults to System SME-led boundary decisions without ever applying the second mode.

Three kinds of boundary

Not all boundaries carry the same risk. But three types appear consistently in large technology estates, and each has a distinct failure pattern when drawn by the wrong hand.

Team boundaries define who builds and who runs. When drawn by function rather than accountability, complexity accumulates at the handoff between them. The team building the system has no stake in its behaviour in production. The team running it has no authority over its design. The seam between them becomes the most expensive point in the architecture.

System boundaries define what a system owns. When a System SME draws this boundary, it will expand to include whatever the system can technically support and contract to exclude whatever requires unfamiliar skills. The system boundary ends up reflecting the team’s comfort zone rather than the domain’s need.

Domain boundaries define which business capabilities belong together. When drawn by the people whose scope is determined by them, the boundary serves the leader’s position rather than the architecture. Proposals for domain mergers that collapse under architectural scrutiny but would expand the proposer’s territory are the clearest symptom.

In each case, the boundary was a decision. Someone made it. The question is whether they made it for the domain or for themselves.

The patterns I keep seeing

I have seen these boundary failures play out more than once, and they follow recognisable shapes.

A System SME in an ETL platform begins embedding business logic into the data movement layer. The ETL layer exists to extract, transform, and move data between systems. It was never designed to own business decisions. But the data is already there, and the transformation is easier to build in the pipeline than in a separate business service. Over time, business rules proliferate across a layer that has no domain authority over them. The business domain loses visibility into its own logic. The ETL system becomes the de facto owner of rules it was never designed to govern.

A System SME responsible for a core system adds non-core capabilities under the argument that one system is simpler. Fewer systems, fewer integration points, less operational overhead. The logic sounds right in principle. But the capabilities do not belong in the core system’s domain. Every additional capability increases coupling, cognitive load, and change risk. The system becomes simple to describe and complex to change.

And the pattern that is hardest to name, because it presents itself as technical reasoning. Proposals surface for merging domains. The arguments are presented with architectural language: shared data models, overlapping functionality, reduced duplication. When you apply genuine architectural scrutiny, the reasoning does not hold. The merger does not simplify the domain model. It expands the scope of the lead proposing it. The argument is circular. It begins with the conclusion.

The pragmatic case, and its cost

There is a pragmatic case for System SME-led boundaries. They are faster to draw. They require less organisational negotiation. They match what the team can deliver today rather than what an architect believes the organisation should deliver in three years. In environments where delivery pressure is constant, the pragmatic boundary wins because the alternative, a target-state boundary that requires organisational change before it can be implemented, often does not get built at all.

The cost appears later. The boundary that was pragmatic in year one becomes the structural liability in year five. The institution discovers that what looked like a fast decision was actually a deferred one. And the deferral has been compounding.

What happens when boundaries are redrawn

When a boundary is placed correctly, complexity does not need to be managed. It collapses.

Team boundary: Amazon.

Amazon encountered this two decades ago. Development teams built systems. Operations teams ran them. The boundary between the two was drawn by function. Complexity accumulated at the handoff. Werner Vogels compressed the fix into six words. You build it, you run it. The boundary was redrawn around accountability rather than function. The team that wrote the code carried the full lifecycle. The handoff disappeared. The complexity at the seam disappeared with it.

Domain boundary: EBSCO.

EBSCO Information Services restructured seven years of component-based teams around value streams. The technology was the same. Feature delivery was 26% faster. Dependency blockers dropped by 45%.

System boundary: AWS Lambda networking.

AWS Lambda’s networking team encountered it at the system level, and their case is worth examining because the mechanism is the clearest.

The platform’s firewall configuration had grown to over 125,000 rules in a single central checkpoint. Every virtual machine slot required roughly 30 rules for its own traffic management. At 4,000 slots, all 125,000 rules sat in one place, evaluated in sequence.

Think of it as a building with 4,000 apartments and one security desk in the lobby. Every visitor is checked against the full list: the rules for apartment 1, apartment 2, apartment 3, all the way through to apartment 4,000. A visitor for apartment 1 is cleared almost immediately. A visitor for apartment 3,500 waits while the desk works through 105,000 rules that have nothing to do with them, before reaching the 30 rules that do.

The Lambda networking team did not remove rules. They did not add technology. They moved each apartment’s 30 rules to its own door. The lobby kept 144 building-wide rules that apply to everyone. Now any visitor passes through the same 174 checks: 144 at the lobby, 30 at their apartment. No one waits behind another apartment’s security. No performance gap between slot zero and slot 4,000.

The cost nobody budgets for

The standard I hold is this. Before accepting any boundary, whether team, system, or domain, ask whether it was drawn by the architecture or by the person whose career scope depends on it.

The structural liability created by misplaced boundaries is invisible until it becomes the dominant line in the change budget. Platform restructuring. Domain separation. Integration rework. These programmes exist because a boundary was drawn to serve someone’s scope rather than the institution’s need. The institution pays to redraw it, often more than once, often years after the original decision.

Complexity accumulates where responsibility was never settled. Someone preferred it that way.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Share

Further reference material for Lambda example

If every architectural guardrail in your organisation were removed tomorrow, which decisions would actually change?

That question is worth sitting with, because the answer is rarely flattering. Most technology leaders can name their governance frameworks, their review boards, their architectural principles. Far fewer can name a single delivery that was stopped, or a single decision reversed, because a guardrail held firm against someone who wanted to cross it. A guardrail that has never changed an outcome is not protecting the institution. It is decorating it. And decoration mistaken for protection is how regulatory exposure accumulates at the speed of every delivery that accelerates past it.

I have spent enough years inside large technology organisations to know this is not an accident. It is the predictable result of a confusion that sits at the centre of how institutions govern themselves.

What a guardrail actually is

Picture a mountain road with a steep drop on one side.

A painted line near the edge tells you where the danger begins. It informs. It assumes you are paying attention, that conditions are good, that you will respond in time. A steel barrier assumes none of that. It stops the car going over the edge whether you saw the line or not, whether you were paying attention or not, whether the road was dry or covered in ice.

Both run along the same stretch of road. Only one is a guardrail. The other is a suggestion with paint.

Every governance system contains both, and most institutions cannot tell them apart. A principle, a policy, a cultural commitment, an architectural standard. Many of these are painted lines. They hold when conditions are calm, when there is no deadline bearing down, no senior sponsor pushing a preferred outcome, no career riding on the result. Under those conditions people stay inside the line because crossing it costs them nothing.

A real guardrail holds regardless of conditions, because crossing it carries a consequence the institution will actually impose. Not a consequence written in a document. A consequence that lands. Under pressure, a painted line bends toward whoever has the most to gain from bending it. A barrier does not bend. The gap between the two is where institutions fail. Not because they lacked a guardrail. Because what they had was paint, and they mistook it for steel.

A barrier replaced with a painted line

Consider one of the most examined engineering failures in modern aviation.

Aviation holds one of the oldest enforced principles in the discipline. No critical system should depend on a single point of failure. Build in redundancy. That principle is a steel barrier, and it is enforced precisely because the cost of crossing it is measured in lives.

When Boeing built the 737 MAX, its MCAS flight control system relied on a single sensor with no redundancy. The barrier was removed. In its place, the safety argument offered a substitute. If the system malfunctioned, the flight crew would recognise it and recover the aircraft. The crew was now the guardrail.

The crew had not been told MCAS existed. It was absent from their training. There were no procedures for an MCAS malfunction in the handbook. The institution had taken out a steel barrier, painted a line where it used to be, and called the line a backup. The people expected to hold that line did not know it was theirs to hold.

When a single sensor fed a false reading, the line did what painted lines do under load. It failed. Two aircraft went down. 346 people died. A board had signed off on a design whose safety rested on a guardrail that existed in the documentation and nowhere in the cockpit.

This is the pattern in its purest form. Not the absence of a guardrail. The quiet replacement of a barrier with a suggestion, and the institutional confidence that the suggestion would hold.

The same architecture, in software you may trust more than you should

The same distinction now sits inside the AI systems institutions are deploying at scale, and the stakes are moving from the cockpit to the back office.

Researchers at MBZUAI published an analysis of the Claude Code architecture in April 2026. The detail that matters is not a number. It is a shape. The core of the system is a small loop that calls the AI model and runs its tools. Almost everything else is the infrastructure built around that loop. A permission system with multiple enforcement modes and a classifier. A pipeline that manages what the model is allowed to see. By the researchers’ own line count, the model’s own decision logic was a low single-digit percentage of the codebase. They are careful to say that figure is illustrative rather than audited. The stronger evidence is what happened when other teams built the same kind of tool. Four competing systems, built by different companies with different incentives, converged on the same structure. A capable model wrapped in a far larger harness of constraint.

Two kinds of control sit inside that architecture. The configuration files that guide the model’s behaviour are a painted line. The model usually follows them. Sometimes it does not. The permission system is the barrier. Every action the model attempts passes through a deterministic check before it runs. The model cannot argue its way past it. It cannot cite urgency. The check holds whatever the guidance says.

Here is the part worth holding onto.

The most capable component in that architecture is given the least unsupervised authority.

The capability is trusted precisely because the enforcement around it does not depend on the capability behaving well. Most institutions do the reverse. They hand their most capable and most senior people the widest latitude and the fewest enforced constraints, on the assumption that capability and seniority make the barrier unnecessary. The Boeing design was approved by capable, senior engineers. Capability is not the safeguard. The enforced boundary is.

The discipline is knowing which is which

It would be the wrong lesson to conclude that everything should be steel.

An institution that tries to make every principle deterministic builds a different kind of failure. Brittle processes that cannot accommodate a legitimate exception. Approval chains so rigid that people route around them in the dark, which is worse than the gap they were meant to close. Over-enforcement does not produce safety. It produces shadow systems, and shadow systems are invisible until they fail.

The skill is not converting every painted line into steel. It is judgement about which line is load-bearing. Which constraint, if crossed, ends in a consequence the institution cannot absorb, and which is a sensible default that should bend when the situation genuinely calls for it. The Claude Code architecture makes exactly this distinction. The constraints that protect the filesystem, the shell, and the network are deterministic, because the cost of crossing them is unbounded. The guidance on tone and approach stays probabilistic, because the cost of getting it slightly wrong is small and recoverable.

Most institutions never make this distinction deliberately. They enforce what is easy to enforce and leave the load-bearing constraints as guidance, because the load-bearing constraints are usually the ones that someone powerful finds inconvenient. The judgement is not technical. It is the willingness to put steel where it will be resented.

Where I have watched the barrier quietly disappear

I have observed two patterns of guardrail erosion across large technology programmes, and neither announced itself as a failure while it was happening.

The first is substitution. A capability that needed an asynchronous integration to stay resilient was wired synchronously instead, because synchronous was faster to build and the deadline was close. The result was a brittle coupling that worked in the demonstration and strained the moment real volume arrived. In another case, a capability that the technology direction said should be externalised as its own service was instead shoehorned into an existing platform, in the name of simplicity. The simplicity was real for the team that made the choice. The cost landed later, on everyone who then had to untangle a capability that was sitting in the wrong place. In both cases the guardrail was clear. In both cases it was crossed, and nothing happened.

The cause is rarely the timeline. The timeline is the cover. Underneath it sits a preference, or a personal agenda, that the alternative serves better than the principle does. The barrier was inconvenient to an outcome someone wanted. Because crossing it carried no consequence, the inconvenience became optional, and an optional barrier is paint.

The second pattern is quieter. The guardrail is not crossed. It is redefined. Someone with enough influence narrows its meaning, widens its exceptions, adjusts its scope, until the words remain in the governance pack but no longer constrain the behaviour they were written to prevent. The institution believes it still has a barrier. What it has is the memory of one.

Both patterns trace to the same root. The boundary was never enforceable. Nothing paused. Nothing reversed. Nothing changed because a principle was crossed. Over time the institution selected for the people who treated the guardrail as negotiable, because they delivered faster and made less noise than the people who tried to hold the line and were told they were rigid.

A culture with nothing standing behind it

A blameless postmortem culture is a guardrail too, even if it does not look like one. Its job is to keep the conversation on the failure in the system and away from the failure in a person. The moment people fear blame, they stop telling the truth, and an institution that cannot hear the truth cannot fix what broke.

I have been part of leadership teams that stated that principle clearly. Examine the system, not the person. Find the cause. Prevent the recurrence. What we rarely built was anything that would hold the line when it was tested. No facilitator with the authority to stop the room. No separation between what was said in a postmortem and what surfaced later in a performance conversation. The principle was painted on. Nothing steel stood behind it.

This is a pattern I have seen play out more than once, and it follows the same shape each time. A serious incident lands under executive visibility. The blameless framing is stated at the top of the meeting. Within minutes the questions turn. Who did the design. Who tested it. The design was often a sound one when it was made, built for conditions that have since changed. But the person who could have explained the context, the trade-off, the constraints it was built for, is frequently not in the room. With no one to defend the reasoning behind a decision, a system failure quietly becomes a personal one. The absent name absorbs the blame, because an absent name cannot push back.

The culture holds when incidents are small and no one is exposed. It collapses the first time the stakes are high, because nothing structural stands between the stated principle and the fear that overrides it. The corrective action, predictably, is another process step. A new checklist. More paint. The same class of incident returns months later.

Where the regulators have already arrived

This is no longer only a leadership question. The regulators have made it a legal one.

DORA, the EU’s Digital Operational Resilience Act, took the operational resilience principles that financial institutions had treated as best practice for years and turned them into enforceable obligation. Best practice was the painted line. DORA is the barrier.

The mechanism that matters most is accountability. DORA places ICT risk management ownership directly with the management body. The board signs it, owns it, and is personally accountable for failures.

I have seen what changes inside an institution when accountability stops being documented and becomes personal. The decisions get sharper. Prioritisation gets clearer. When it is unambiguous who is accountable for a specific outcome, that a payment is processed, that an account is opened and ready to transact, that ownership drives the rest. It forces the design to be deliberate. It forces the engineering to carry the right instrumentation. It forces someone to be able to measure and monitor the thing they are answerable for, because they can no longer point to a policy and call it someone else’s concern. Personal accountability does not add a document. It changes what people choose to build.

DORA adds a second barrier in the form of a clock. An initial incident notification within four hours, an intermediate report within seventy-two, a final report within a month. An institution that cannot report inside four hours has failed, and the quality of its documentation will not save it. The deadline is the enforcement, not the policy describing the deadline. According to Deloitte research, nearly half of all regulated entities entered the DORA enforcement phase with known compliance gaps. They are now learning, from the regulator’s side of the table, the difference between a guardrail that is written and one that is enforced.

From barrier to test suite

There is a more constructive way to see where this is heading, and it changes the work of the technology leader.

A growing argument in AI engineering reframes regulation not as a bottleneck but as a test suite. An automated set of conditions the work must satisfy before it ships. Seen that way, a guardrail stops being a document someone might consult and becomes a gate the work cannot pass through until it complies. The human role shifts with it. Less time producing the work, more time standing behind it, accountable for whether what was built is safe to release.

The question worth answering honestly

A capable system, or a capable person, given a weak boundary, is not a reduced risk. It is an accelerated one.

So the real question is not whether your institution has guardrails. It is which of them would hold. Across your review boards, your principles, your cultural commitments, how many are backed by a consequence the institution will actually impose, and the willingness to absorb the friction of holding firm when someone senior pushes? And how many are lines drawn with care, honoured when convenient, and silent at the exact moment they were built to speak?

The honest answer is your real governance architecture. Not the one in the framework document. The one your institution enforces every day, through what it stops, what it permits, and what it lets pass because no one was prepared to pay the cost of holding the line.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

What is built around the model?

For most institutions, the harness, the permission infrastructure, the boundary enforcement, the session governance, and the recovery architecture, is simply not part of the deployment conversation. The investment went into the reasoning layer. The governance layer followed later, partially, or not at all. A system deployed that way carries a governance gap that senior leadership has not priced.

What a harness is and why it matters

In architecture, a harness is the infrastructure of constraint surrounding a capable component. It determines what that component is permitted to do, under what conditions, and what happens when it exceeds its boundary. The harness does not replace the component’s capability. It governs the conditions under which that capability is trusted to operate.

This concept is not new. Regulated industries have applied it for decades. A payments authorisation system has a capable decision engine at its core. Around it sits the fraud detection layer, the velocity checks, the decline rules, and the exception handling. That surrounding infrastructure is the harness. Remove it and the decision engine still works. It just cannot be trusted to work safely, at scale, under pressure.

The same design philosophy governs the AWS Nitro System, where even the hypervisor cannot initiate outbound network connections, and nuclear reactor control systems, where the default state of the control rods is shutdown and sustained operation requires continuous active permission.

The principle applies directly to AI systems. A model can reason. It can generate code, produce analysis, and operate tools. The question that determines whether it can be deployed responsibly has less to do with how well it reasons and more to do with what surrounds it: what it is permitted to do, what it is prevented from doing alone, and what the system does when the model’s judgement is wrong.

Most current AI governance conversations focus on model selection and tool selection. The harness, the constraint architecture that determines whether the deployment is trustworthy, receives a fraction of the attention and a fraction of the investment. That is the gap this post examines.

The Claude Code Architecture

Researchers at MBZUAI published a source-level analysis of Claude Code in April 2026, examining every line of its TypeScript codebase. Their finding is structural, not evaluative.

The core of the system is a while-loop. It assembles context, calls the model, dispatches tools, evaluates results, and repeats. That loop, the reasoning engine, accounts for 1.6% of the codebase.

The remaining 98.4% is the harness.

Not supporting features. Not configuration files. First-class runtime infrastructure, designed before the model loop that sits inside it. Five subsystems, each a deliberate architectural commitment.

The permission system. Seven operating modes. The default state is deny. Every tool call routes through a permission gate before execution. The strictest rule in the evaluation chain wins. An ML-based classifier handles ambiguous cases. A four-stage authorisation pipeline, pre-filter, PreToolUse hook, rule evaluation, and permission handler, processes every action before the model can execute it. The model never directly touches the filesystem, the shell, or the network. It reasons and proposes. The harness decides what it is permitted to do.

Context management. A five-stage compaction pipeline treats the token budget as a hard infrastructure constraint. Budget reduction, snip, microcompact, context collapse, and auto-compact run continuously. Context is managed as a scarce resource with engineering discipline comparable to memory management in an operating system.

Subagent delegation and isolation. When delegated work spins up a subagent, it does not inherit the trust established in the parent session. It receives its own context window and its own permission context, rebuilt from scratch. The architecture treats inherited trust as a risk. Session permissions are not restored on resume for the same reason. The cost of re-establishing trust is accepted deliberately, because stale trust decisions are more dangerous than the friction of replacing them.

Extensibility with risk boundaries. Four mechanisms: MCP servers, plugins, skills, and hooks. Each carries different context and risk budgets. The extensibility is graduated, with PreToolUse and PostToolUse hooks wrapping every external call.

Session persistence. An append-only transcript model designed for auditability from the first write. Every action, every tool call, every subagent sidechain is recorded in a separate, replayable transcript. The storage model was designed as the foundation for institutional trust: what the system did is always recoverable.

Source: arXiv:2604.14228v1. MBZUAI. April 2026.

The researchers describe this design in precise terms: model judgement operating within a deterministic harness. The model reasons. The harness enforces. Probabilistic guidance, what the system is asked to do, lives in configuration files. Deterministic enforcement, what the system is actually permitted to do at execution time, lives in the permission architecture. Conflating these two layers is the governance mistake most institutions are currently making.

Why this architecture decision produced a different outcome

It is worth pausing on what this architecture made possible, because it reveals why the harness question matters beyond governance.

Claude, the model, existed first. Anthropic built the reasoning engine over several years. When they then built Claude Code, a product designed to operate autonomously on a developer’s codebase, writing code, running commands, and modifying files, they faced a decision that every institution deploying AI faces. How much authority to give the model. And how to make that authority governable.

They chose to encode the governance within the architecture itself. Not as a policy document alongside the product. Not as a review committee that approves deployments. As the structure of the product. Deny-first defaults. Seven permission modes. Independent enforcement layers. Trust rebuilt from scratch every session. The model’s capability was not reduced. The conditions under which that capability could execute were made explicit, deterministic, and auditable.

The result is instructive for any technology leader considering what trustworthy AI deployment looks like. Claude Code reached a billion dollars in annualised revenue within six months of its public launch in May 2025. By February 2026, that figure had reached two and a half billion. It now accounts for approximately four percent of all public GitHub commits worldwide. The Pragmatic Engineer survey of fifteen thousand developers in February 2026 found it was the most-used AI coding tool, with a 46% “most loved” rating. Enterprise subscriptions quadrupled since the start of 2026. Seventy percent of Fortune 100 companies now use Claude.

That adoption was driven by trust, not benchmark supremacy. Consumers trusted it to operate on their personal codebases. Enterprises trusted it to operate within regulated environments. The architecture earned that trust. The deny-first permission system, the subagent isolation, the append-only auditability, the session-scoped trust that is never inherited. These governance structures are the reason the product could be deployed at all in environments where the consequence of failure is real.

The lesson for institutions is simpler than the architecture: recognise the sequencing. The harness was not added after the product succeeded. The harness is why the product succeeded. That is a fundamentally different investment thesis from the one most organisations are operating under, where capability is deployed first and governance is funded from whatever budget remains.

What fills the space when the harness is absent

Early in my career, I saw the consequences of a platform where multiple channel applications shared a single database.

The boundary existed in the architecture diagram. Every domain had a defined scope. Every team understood, in principle, where their ownership ended. What had never been built was any infrastructure to enforce that boundary at runtime. No permission model specifying what each application could read, write, or modify under what conditions. No governance over what crossed the seam between domains. No recovery path when behaviour leaked from one channel into another domain’s data.

What I observed was predictable in hindsight. Behaviour filled the space where governance had not been built. Teams optimised for the shared resource, not for their domain. Changes in one channel produced unexpected results in another. The coupling traced back to a foundation design failure. No boundary enforcement. No guardrails. No constraint architecture governing what each part of the system was permitted to do alone.

The applications were capable. That was never the problem. Capability had been deployed without the infrastructure that determines what capability is allowed to do. Ownership existed on paper. Trust was inherited by default. The boundary declared in the diagram and the boundary enforced at runtime were two different things, and the gap between them is where every failure I witnessed originated.

The Claude Code architecture is the structural answer to exactly this failure mode. Replace the channel applications with AI agents. Replace the shared database with a developer’s codebase. The deny-first permission system, the subagent isolation, the session-scoped trust: these are precisely the harness components that were absent in the shared database system. The foundation design failure I saw play out in a pre-AI world is now being repeated at AI speed, in organisations deploying capable models without the constraint infrastructure to govern them.

The question that has not been asked

The AI governance conversation in most institutions is running well behind the deployment conversation. Frameworks exist. Committees meet. Policies are drafted. The question largely absent from those conversations is whether any of it translates into deterministic enforcement at the point of execution.

A governance document tells the model what it should do. A permission architecture tells the system what the model is allowed to do, regardless of what the model decides. One is probabilistic guidance. The other is structural constraint. Most organisations have built the first and described it as the second.

The MBZUAI researchers identified this as a recurring design choice, not an implementation detail. The harness is what makes the model trustworthy at all.

For CIOs, CTOs, and the executives who approve AI investment, the question worth asking goes beyond which model the organisation deployed. The question is what surrounds it. What the model is permitted to do. What happens when an agent carries permissions beyond its scope. Whether the recovery architecture exists before it is needed. Most institutions cannot answer those questions with precision today. Governance architecture gaps do not stay invisible. They surface at the moment the system is most under pressure, and someone is asking what happened.

The decision that precedes deployment

Claude, the model, was built first. When Anthropic then built a product around it for consumers and enterprises, they made the governance architecture the product’s structural foundation, not its compliance layer. The model loop sits inside the harness. The decision about what the system is not permitted to do alone preceded the decision about what it could be trusted to do. That sequencing is the investment decision, not the model selection.

Most institutions have the sequencing reversed. Capability is deployed first. Governance follows later, partially, and under pressure. Retrofitting a deny-first permission architecture onto a system already running in allow-first mode becomes a risk event, with a timeline determined by when the gap becomes visible, not by when the organisation chooses to close it.

Capability stopped being the scarce resource some time ago. The question worth asking is whether your institution has built the infrastructure that determines what its AI is trusted to do, before it is trusted to do it.

Trust in what a system can do begins with what it cannot do alone.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

The organisation you give to AI is the organisation it accelerates.

That is the only sentence that matters before procurement begins. Capability is no longer the constraint. Process clarity is. The board does not yet see this. Some of the technology leadership team does, and most of them are not saying it out loud.

Remediation now happens at AI speed. Whatever debt the organisation chose to defer last year, it will pay for at several times the rate. Whatever boundary it chose not to draw, it will need to draw under load, in front of an auditor, with a customer impact already underway. The institutions adopting AI before bounding their own processes are not investing in capability. They are pre-funding a remediation programme they have not yet named.

The proof.

Andy Jassy’s 2025 letter to shareholders carries the cleanest external evidence we have. The Amazon Bedrock team rebuilt the inference engine in seventy-six days with six engineers. The original estimate was forty engineers and roughly a year. The new engine, Mantle, became the backbone of a service that nearly doubled month-over-month in March. It processed more tokens in a single quarter than in all prior years combined.

That compression ratio is the headline. What is underneath it is more interesting.

The engineers did not work faster because the tool was faster. They worked faster because the scope was bounded correctly. A separable group. A clear architectural decision, not a tweak, a different architecture (a complete rebuild, not a refactor). A defined outcome. Six very skilled engineers. The AI did not produce the discipline. The discipline produced the AI outcome.

The amplification is not selective.

AI is being framed as a capability investment across the industry. It is not. It is an amplifier of whatever clarity, ownership, and discipline already exist inside the organisation that adopts it.

Where clarity exists, the amplification is real. Where clarity does not, the amplification is also real.

The amplification does not pick.

The IBM Institute for Business Value’s 2025 survey of 1,300 senior AI decision-makers reported what most of us already suspect. Organisations that ignored their technical debt before adopting AI saw project returns drop by close to a third. Timelines stretched by more than a fifth. The population-level numbers from MIT’s 2025 study sit alongside it. Ninety-five percent of AI projects fail to reach production or deliver value. None of these figures measure the model. They measure the organisation around the model.

The honest question for the board, therefore, is not how much AI to adopt. It is what condition the organisation is in before the adoption begins. That question is harder to ask because the answer is uncomfortable. It is easier to fund a tool than to fund a process audit. Easier to declare an AI roadmap than to admit what the organisation does not currently know about its own estate.

Where the new model meets the old.

I have lived this in a different form already.

Some years ago, in a team I was leading, we adopted Domain Driven Design and event-driven architecture as the direction. The decision was correct. We had the mandate to stand up separate teams in the new domain space. We did, and the new model worked. The bounded contexts held. The events flowed cleanly. By any internal measure, the architecture was a success.

The failure mode was elsewhere. It surfaced at the seams.

Wherever the new domain touched the existing landscape, the old patterns tried to leak in. Legacy data models brought their assumptions with them. Legacy interfaces brought their semantics. Legacy teams brought their habits.

The new model was not under attack. It was being slowly translated back into the old one at every boundary.

We resolved it the way DDD anticipates this exact problem. Anti-Corruption Layers. Explicit translation between the new domain and the legacy estate. The ACLs did the work the architecture alone could not. They protected the new model from being absorbed by the old one.

The lesson was not that DDD was wrong. The lesson was that the architecture is never the only design decision. The boundary is. Where you do not draw it, the old pattern leaks into the new.

AI is the same problem at a different scale.

The model is not the question. What you build around it is.

Process clarity, ownership, audit, and the discipline to refuse scope creep are the institutional equivalent of an Anti-Corruption Layer.

Without them, the old organisation leaks into the new capability. Faster than before. Louder than before. With more board-level visibility than before.

What this means for large institutions.

In a large institution, the worst habit is rarely the obvious one. It is not the cost of change. It is not the duration of programmes. It is the compounding organisational liability that no balance sheet has yet been willing to recognise. The quiet rhythm by which decisions are deferred to preserve scope. The pattern by which urgent beats important on a schedule the institution refuses to name.

AI does not change that pattern. It runs it faster.

The institutions that prepare for AI by examining their own readiness, drawing their boundaries, and protecting their new capability from their old habits will spend less and finish more. The institutions that prepare for AI by signing procurement contracts will pay twice. Once for the tool. A second time, larger and less visible on the budget line, for the remediation the tool makes inevitable.

The tool does not change what you are. It changes how fast you become it.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Leave a comment

Twelve posts.

Reading them as a set, what I see is one argument that I did not fully see when I began.

Season Two of Systems and Sutras started as a question about what leadership is for when execution becomes abundant. The work of twelve posts produced an answer that, in retrospect, holds together as one sentence.

When execution becomes abundant, leadership is defined by restraint, proof, and consequence.

That sentence is the season in one line. Everything else was the work of finding out what it actually means.

The Four Chapters.

The first chapter, looking back, was the one I had to start with. Acceleration has not changed consequence. Execution is cheap, but commitment is not. Speed without proof is speculation. Decisions made under pressure become the architecture everyone else inherits. What does AI accelerated leadership require? Slower thinking about the decisions that cannot be unmade.

The second chapter, I see more clearly now, moved from acceleration to capital. Architecture is capital allocation. Resilience is a customer commitment, not a technology standard. Accountability does not distribute itself when systems do. Every architectural decision is a financial decision wearing technical clothes, and the organisations that navigate this well make that visible at the point of decision rather than at the point of consequence.

The third chapter is where the argument turned. From capital to executive liability. Failure is always funded, the question being whether the funding goes to containment before or remediation after. Organisations carry forward, in the system itself, what they were never designed to hold. And every leader manages two inheritances simultaneously, what they receive and what they will leave. What survives the leader and behaves correctly without supervision is the measure.

The fourth chapter, in retrospect, was the one that closed the structure. From liability to practical translation. How leaders are read by audiences that read through their own filters. What legacy systems actually are when the word is used precisely. What the work of leadership produces that outlives the seat. The season closes on what endures.

The Spine.

The twelve sutras, taken as a set, are the season’s argument at its most compressed. Each one closed a post. Together they trace a sequence from the moment of commitment, through the capital and the customer at the centre of the architecture, into the leader’s stewardship of what they inherit and what they leave.

The closing sutra names what the work was for. The seat is left behind. The judgement is carried forward. That is the only legacy that lasts.

The Questions I Keep Coming Back To.

The season’s disciplines are a way of seeing. But a way of seeing arrives in the form of questions a leader asks themselves before the commitment is made. These are the ones I keep coming back to.

When did I last refuse to make a decision because it was not yet reversible? When did I last ask the team not what they have tested, but what they can prove? Where is the metric in the organisation that is shaping behaviour in a direction nobody has explicitly chosen?

Where is the inherited liability in the estate that nobody has named yet, because naming it would create an obligation to act on it? Whose reading of me am I treating as diagnosis when it is actually projection, and whose am I dismissing as projection when it is actually diagnosis?

And the one I sit with most often. What in my current tenure will still be operating after I have left the seat, and would I be content with what it carries forward?

These are not questions a framework answers. They are questions a leader lives with.

What The Season Was.

The season was an argument that leadership in technology, when execution becomes abundant, becomes a discipline of restraint, proof, and consequence. The technical decisions remain technical. But the leader is now aware of what they actually are. Capital allocations. Inheritance decisions. Acts of stewardship. Material that will outlive the moment in which it was committed.

That is what I came to see across twelve posts. The recognition is now yours to carry too.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Leave a comment

Walk into any organisation and look at what the last technology leader built.

Most of it is already being revised.

The platforms are being replaced. The strategies are being rewritten. The teams are being reorganised. The roadmap that defined the previous tenure has been quietly retired. Within two or three years of a leader leaving the seat, the visible work of their tenure is largely gone.

This is the uncomfortable truth about technology leadership. The work that is most visible during a tenure is rarely the work that endures. The leader who measures their legacy by what they built is measuring the thing most likely to be replaced.

Something else endures. It is harder to see and harder to build. But it is the only thing that lasts.

What Does Not Endure.

The instinct of most technology leaders is to build. A new platform. A new capability. A new operating structure. A new strategy. The tenure is measured by what was delivered. The recognition system rewards the visible artefact.

But artefacts are replaced. Every platform is eventually superseded. Every strategy is eventually revised by a successor who sees the landscape differently. Every team structure is eventually reorganised. The half-life of a visible technology artefact is short. A leader who measures their legacy by these things is measuring a depreciating asset.

This is not a criticism of building. Building is the work of the tenure. The platforms and capabilities matter while they are in service. The error is in the measurement. The leader who believes the platform is the legacy has confused the work of the tenure with what the tenure leaves behind.

What Actually Endures.

What endures is not what the leader built. It is the judgement the leader embedded in how the organisation works.

Embedded judgement is the operating model that keeps producing good decisions after the leader has left. It is the disciplines that have become part of how the technology function operates rather than part of what the leader personally enforced. It is the institutional memory that holds the reasoning behind decisions so the next leader inherits understanding rather than only outcomes.

Embedded judgement does not depreciate the way artefacts do. A platform is replaced. The discipline of how the organisation decides what to build next is not replaced when the platform is. It carries forward. It shapes the next platform and the one after that. The leader who embedded the judgement is no longer in the seat, but the judgement is still operating.

This is the difference between what a leader builds and what a leader leaves. What they build is the artefact. What they leave is the judgement that produced the artefact and will produce the next one.

What I Have Witnessed.

I encountered embedded judgement first in my own early career, at Kanbay, the first company I worked for.

Two things from that organisation stayed with me long after I left it.

The first was a culture of genuine openness. In the early 2000s, before open plan offices were common, Kanbay had built one deliberately. As a fresh graduate I could walk to the chief executive’s desk and have a discussion. And everyone, from the chief executive to the person cleaning the floor, was addressed by their first name. That choice ran directly against the local professional culture of the time, where seniority and grade were marked with Sir and Ma’am. Kanbay chose the opposite deliberately. Designation did not determine whether your thinking was heard, and it did not determine how you were addressed. That culture was not a policy document. It was embedded in how the organisation actually worked. It shaped how I have thought about leadership ever since.

The second was an emphasis on building solid domain knowledge alongside systems knowledge and technical depth, all of it in service of delivering real value to the client. Kanbay did not treat technical skill as sufficient on its own. It insisted that technical skill without domain understanding produced the wrong outcomes. That conviction became part of how I work.

Neither of these was a platform or a system. Both were embedded judgement. And I am still carrying both of them, decades later, into organisations that have no connection to Kanbay at all.

What I Have Seen Endure From My Own Work.

The same recognition applies to my own tenure. The work of mine that has endured is not the work that was most visible while I was doing it.

Four disciplines have outlasted my direct involvement.

The rigour of systems thinking applied to problem solving. Not the solution to any particular problem. The discipline of approaching problems as systems with interacting parts rather than as isolated faults.

The discipline of capturing the problem statement, the reasoning behind a decision, and the trade-off that was accepted. Not the decisions themselves. The practice of recording why a decision was made so that whoever inherits it can evaluate it in its original context.

The decision to commit to Domain Driven Design when others opposed it on the basis of past failures. The position was not popular when I held it. What endured was not the architecture itself. It was the demonstration that a well reasoned position, held against resistance, can reshape how an organisation designs.

And making the platform the centre of the decision rather than personal ambition or who happened to be right. This is the one I value most. When the platform is the centre, the decision outlives whoever made it, because the decision was never about them.

None of these four was a built artefact. All of them were embedded judgement.

The Judgement That People Carry Forward.

The most durable carrier of embedded judgement is not a system. It is a person.

I have watched my own work carried forward in two directions.

Within the organisations I have worked in, people who were inspired by a way of working, or who worked directly alongside it, carried it forward after I had moved on from the role. The judgement stayed because the people stayed and carried it. The discipline did not need me present to continue. It had been absorbed by people who made it their own.

And beyond those organisations. People who absorbed a way of thinking carried it into other organisations entirely. When they moved on, the judgement moved with them.

I have watched several pieces of my own work travel this way. The discipline of capturing key decisions, the problem statement and reasoning and trade-off recorded together. An approach to governance that was open and adaptive rather than rigid. A simple model for structuring accountability, copied many times, sometimes directly in front of me, by people who no longer associated it with me at all.

The Domain Driven Design position from that programme has travelled furthest. It has since been quietly adopted across the wider organisation as the core operating model. A specific architectural position that went with it, taken against the prevailing strategic view of the time, has been quietly adopted in other areas too.

I have taken all of this as a quiet compliment. A piece of work that has to carry your name to travel has not really become embedded judgement. A piece of work that travels without your name has. It has stopped being yours and become something people simply use.

This is the deepest form of the legacy. Embedded judgement carried by people is not bounded by the organisation where it was formed. It propagates. It moves through careers into organisations the original leader will never work for and may never hear about.

My own experience is the proof of this from the receiving end. Kanbay embedded judgement in me. I have carried it for decades, into every organisation I have worked for since. Kanbay’s legacy is operating, through me, in places Kanbay has no connection to. Every leader who embeds judgement well is doing the same thing. They are not leaving a legacy contained within one organisation. They are setting something in motion that travels.

Decisions Others No Longer Have to Revisit.

Embedded judgement has a visible signature. You can recognise it when you see it.

It looks like decisions others no longer have to revisit. The leader whose judgement was embedded well leaves an organisation where certain questions are settled. The architecture principles do not have to be re-argued every time a new platform is proposed. The discipline of capturing reasoning is automatic rather than imposed. The mistakes that the judgement prevents are no longer made, because the judgement that prevents them has become structural.

An organisation carrying well embedded judgement moves differently. It does not relitigate settled questions. It does not rediscover the same lessons every few years. It does not depend on any individual being in the room for good decisions to be made.

This is the practical test of a leader’s legacy. Not what they built. What the organisation no longer has to revisit because the leader settled it well enough that it stayed settled.

The Leader Becoming Unnecessary.

This leads to the conclusion the season has been building toward.

**The true legacy of a technology leader is to become unnecessary. The work continuing correctly without them. The judgement operating after they have left the seat.

This runs against the instinct of most leaders. The instinct is to be essential. To be the person without whom the function does not work. But the leader who is essential has built nothing that endures. The moment they leave, the thing that depended on them degrades. Being needed is not the same as being effective. The leader who is genuinely effective is building toward their own redundancy.

The leader who makes the platform the centre rather than themselves is already practising this discipline. They are embedding judgement that does not depend on them. They are settling questions that stay settled. They are building an organisation that will not need them. That is not a loss of importance. It is the only form of importance that lasts.

What the Season Has Been For.

This is where the season’s argument has been leading from the first post.

The season opened with a question. When execution becomes abundant, what is leadership actually for. Twelve posts have built the answer. When execution becomes abundant, leadership is defined by restraint, proof, and consequence. Restraint, because the constraint is no longer capability but judgement. Proof, because confidence is not a sufficient standard. Consequence, because the decisions a leader makes outlive the moment in which they are made.

The consequence, finally named, is this. What a leader leaves behind is the judgement they embedded in how the organisation works and in the people who carry it forward. The platforms will be replaced. The strategies will be revised. The visible work of the tenure will be quietly retired. What endures is the judgement. The decisions others no longer have to revisit. The discipline that operates without the leader who established it. The way of thinking that people carry into rooms the leader will never enter.

If you have followed this season from the first post, you have been building toward this recognition across all twelve. The recognition is now yours to carry. That is how it was always going to work. The judgement does not endure in the writing. It endures in what you do with it.

That is the work that outlives the seat. It is the only work that does.

The Sutra

The seat is left behind. The judgement is carried forward. That is the only legacy that lasts.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Leave a comment

Legacy systems are not old.

They are inherited.

The difference is who decided what to do with them.

The Word Legacy Is Doing Two Different Jobs.

In technology conversations the word legacy means old systems. Outdated platforms. The estate that should have been replaced and was not. The condition is treated as a property of the technology itself.

In leadership conversations the same word means something different. The legacy of a tenure. What endures after the leader is no longer in the seat. The contribution that lasts.

Most discussions treat these as separate meanings. They are not separate. They are connected.

The legacy systems in your estate are the leadership legacy of every leader who held the seat before you. Your leadership legacy will include the systems you allow to compound or actively evolve. The two meanings are the same compound seen from different positions in time.

Why Systems Become Legacy.

A system does not become legacy because it is old. A system becomes legacy because nobody evolved it.

Stranded water becomes spoiled. The water itself does not change at first. It just sits. Sediment accumulates. Conditions shift. The water that was fresh on the day it was stored becomes something different through the simple act of not moving. The longer it sits, the more spoiled it becomes. Eventually it cannot be used at all, even though nothing was ever added to it. The spoilage is the consequence of stillness.

Flowing water stays fresh. It is constantly moving. It carries away what would otherwise accumulate. It encounters new conditions and adapts. The water that flows through a system today is not the same water that flowed yesterday, but the system itself remains alive. It is not the water that is fresh. It is the flow.

The same principle applies to technology systems. A system that is evolved continuously, refactored against changing requirements, and tended for boundary clarity stays current even when it is technically old. A platform built three years ago and frozen since release is more legacy than a platform built fifteen years ago that has been continuously evolved.

The legacy condition is not a property of how old the system is. It is a property of whether the work has been flowing or not.

But systems do not exist alone. They sit in a landscape. The landscape is the work of multiple hands across multiple seasons. Each gardener tends what they planted and what was inherited from previous gardeners. A garden left untended for one season can be recovered with concentrated effort. A garden left untended for several seasons becomes a different kind of work. Conditions compound. Soil degrades. What was planted intentionally is crowded out by what arrived without invitation. The next gardener inherits not a garden but the consequence of multiple seasons of neglect.

Each individual gardener’s choice to defer the tending was defensible against the constraints of their season. The cumulative effect across multiple seasons is the unmaintained garden the next gardener now has to work with.

This is what happens to technology landscapes across multiple tenures. Each previous leader made an individually defensible decision to defer evolution. The cumulative effect produced the legacy estate the current leader has inherited.

The Shapes of Legacy.

Legacy is not one phenomenon. It has multiple shapes. Each shape is the visible architectural consequence of a different leadership decision pattern. Across the programmes I have been directly involved in, four shapes appear repeatedly.

The bloated platform.

A platform that has accumulated scope beyond its intended boundary. Multiple domains in one place. Repeated attempts to simplify that have not produced simplification. Stakeholders treating colocation as an advantage because change is easier when everything is in one place.

The fallacy. Confusing a true monolith with a modular design with a distributed system. People believe the platform is simple because it is colocated. They mistake colocation for coherence. Most have stopped knowing what the platform does. They think they know what it does. The understanding has been lost while the colocation has remained.

The legacy condition. A platform whose physical and logical architectures have diverged so far that nobody can confidently predict the impact of any non-trivial change. Integration capabilities never evolved because every change was routed through the existing pattern. The decoupling that would have allowed evolution was never funded because colocation made everything appear easier than it was.

The over-guarded platform.

A platform whose boundary has been protected so aggressively that core functions which belong inside it have been pushed to the periphery. Risk framing used to prevent integration. New capabilities forced to live elsewhere because the platform that should hold them refuses to absorb them.

The pattern. Risk-aversion at the platform level treated as virtue rather than as a trade-off. The leader of the platform protecting their own scope at the cost of the wider landscape.

The legacy condition. A patchwork of capabilities scattered across systems that should not have been carrying them. The complexity is in the topology of where capabilities ended up. Nobody designed this topology. It emerged from the cumulative pattern of refusal.

The vendor guarded platform.

A platform managed by a vendor whose contractual or operational arrangement has prevented core change. Peripheral changes have happened. Core changes have not. The platform is now unable to scale to higher order customer journeys.

The pattern. Sourcing arrangements treated as commercial decisions rather than as architectural decisions. Each tenure inherited the vendor relationship and made the rational decision to operate within its constraints rather than renegotiate it.

The legacy condition. A platform whose limitations are now structural to the organisation’s commercial trajectory. The capability gaps are not technical. They are contractual. But the contract is itself a leadership artefact that previous tenures chose not to revisit.

The capability in the wrong layer.

Capabilities built in the periphery of the architecture rather than in the right layer. Whole systems living in the ETL layer. Other systems living in the channel layer. Each placement justified at the time by available skill, time pressure, or political reality.

The pattern. Architectural layer violations treated as expedient compromises in the moment. Each individual decision was defensible. The cumulative effect is an architecture where critical business logic and data live in layers that were never designed to hold them.

The legacy condition. A landscape where the documented architecture and the actual architecture have diverged. The complexity of change compounds because every change has to navigate both architectures simultaneously.

These four shapes do not exhaust the legacy condition. They appear repeatedly enough to constitute a working typology. A senior estate is likely operating with at least two of them simultaneously. Many carry all four.

The Mapping.

The first work of any senior tenure with significant inherited landscape is the mapping. Not what the systems do. What they are carrying.

The mapping begins with conversations with the people who have been tending the systems for years. Reading the texture of how the work is being done. The diagrams tell you what the systems are supposed to do. The conversations tell you what they actually carry.

The four shapes named above rarely appear in isolation. The bloated platform sits next to the over-guarded one. The vendor frozen platform sits next to the capability in the wrong layer. Each shape requires its own form of remediation. Each shape carries its own history of leadership decisions.

The mapping is not optional. The leader who skips it makes decisions about an inheritance they do not yet understand. Most of those decisions have to be remade later, after the inheritance has been understood.

The Cumulative Legacy.

Each previous deferral became the inheritance of the next tenure. The current leader inherits both the systems and the pattern of decisions that produced them. Their own pressures continue the pattern unless they actively refuse it.

This is the harder work. Refusing the pattern is not a technical decision. It is a decision to refuse the structural pressure that produced the legacy in the first place. The pressure is real. The recognition system is calibrated to reward continuing the pattern. The deferral that produced the legacy is rewarded again in the current moment as the same defensible response to the same kind of pressure.

Breaking the pattern means making a different decision under the same pressure that produced the legacy.

The Dual Defensive Pattern.

Refusing the structural pressure is the harder work. Most leaders do not get there because the moment of naming the legacy produces a response that closes off the conversation before the refusal can happen.

Two patterns of response tend to follow. Both are forms of defensive avoidance. Both compound the legacy further.

The first pattern. Explicit defensive avoidance. When the legacy is surfaced to senior stakeholders, the response is often defensive. They are unwilling to take the risk of making a long-term decision because the long-term decision exposes them to consequences during their tenure that the short-term approach does not. They fall into the short-term approach. The legacy compounds.

This pattern is rational from the individual stakeholder position. The recognition system rewards short-term outcomes. Long-term decisions produce visible cost during the tenure that funds them. The natural response to having the legacy condition surfaced is defensive avoidance because acknowledging the condition implies an obligation to act on it.

The second pattern is more subtle. Structural defensive avoidance. The leadership team has reached agreement on the direction of travel. Simplification is endorsed. Everyone agrees on where the estate needs to go.

But each individual change decision tends to gravitate back toward the existing estate. The short-term focus of each delivery cycle produces decisions that extend the legacy rather than move toward the future. Each decision is individually defensible. The cumulative effect across hundreds of small decisions is minimal investment in the agreed strategic direction.

This is the pattern that catches even careful leaders. There is no single moment of refusal. There is only the cumulative consequence of many small defaults to the existing estate. The strategic agreement is correct. The execution is gravity-bound to the legacy.

What Breaks the Patterns.

The mapping work shifts the conversation. Investment that had been framed as cost becomes investment that is buying down inherited liability. The conversation shifts from features delivered to legacy compound bought down. This shift is necessary. The shift alone does not break the patterns. It only makes them visible.

What breaks the patterns is harder. Each individual investment decision has to actively resist the gravity of the existing estate. Each one has to be evaluated not only against immediate delivery pressure but against the cumulative direction it produces over time. The leader has to absorb the personal risk of holding the line on the long-term direction across hundreds of small decisions where the short-term option would be defensible.

The bet the leader makes against the recognition system is the bet that determines what kind of legacy they leave.

The Two Legacies Are the Same Legacy.

The legacy systems in your estate are the leadership legacy of every leader who held the seat before you.

This is not metaphor. It is description. The bloated platform is the legacy of leaders who allowed scope to accumulate without funding decoupling. The over-guarded platform is the legacy of leaders who allowed boundary protection to take precedence over capability placement. The vendor frozen platform is the legacy of leaders who treated the contract as fixed rather than as evolvable. The capability in the wrong layer is the legacy of leaders who allowed expedient compromises to compound.

None of these were single decisions. All were patterns of decision across years and tenures. The leadership legacy is what those patterns produced.

Your leadership legacy will include the systems you allow to compound or the systems you actively evolve. The legacy you leave is being created now, in the daily decisions about whether each individual change extends the existing estate or moves toward the future architecture.

The Leader’s Choice.

Every leader inheriting a landscape with significant legacy faces the same choice.

Defer further. Manage around the legacy. Hand it forward to the next leader with the same defensible justifications previous leaders gave themselves. Continue the pattern.

Or invest in evolution that may not produce visible value during the current tenure but reduces the legacy compound for whoever inherits next. Break the pattern.

The recognition system rewards the first option. The landscape requires the second.

The leader who chooses the second is paying capital the recognition system will not see. They are doing it knowing the political pressure that produced the legacy will continue to operate against them throughout their tenure. They are doing it knowing the visible cost of their decision will land during their tenure while the visible benefit will land during their successor’s. They are doing it knowing the credit for the future they are building may go to the leader who inherits the seat after them.

This is the harder thing. It is also the truer measure of the seat. The leader who breaks the pattern is doing the work that does not look like leadership while it is being done. It looks like cost without offsetting benefit. It looks like investment without justification under the current quarter’s metrics.

Most leaders do not do this work. The recognition system is calibrated against it. The few leaders who do it are choosing what kind of legacy they leave behind through what they actively tend now. They are doing it for the greater good, knowing that doing the right thing rarely produces the right reward in the moment it is being done.

The pattern continues until someone breaks it. The seat decides whether the pattern continues here or stops here.

The Sutra

The legacy you inherit and the legacy you leave are the same compound seen from different positions in time.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Throughout your career you have been reading other senior leaders for signals. Their decisions told you how they thought. Their priorities told you what they would do under pressure. Their absences told you what they would not engage with.

You have also been read. By colleagues. By peers. By senior stakeholders. By the team you lead. By the next leader who will inherit the seat you currently hold.

The signal you have been transmitting may not match the one you believe you have sent. And the signal that is being received is being filtered through the priorities and interests of the people doing the reading.

This is the condition every senior technology leader is operating inside. Always.

What the Signal Actually Is.

The signal is not what the leader says. Not the stated priorities. Not the strategic vision. Not the town hall communication. Not the strategy deck.

The signal is what the operating model produces every day. The decisions that get made. The decisions that get deferred. The investments that get funded. The conversations that happen at the right altitude. The conversations that get pushed down or avoided entirely.

The organisation is closer to the operating model than the leader is. The teams in the work see what the operating model produces. The leader at the top often sees what the operating model is supposed to produce. The gap between the two is where the signal actually lives.

The team reads action over speech.

The most consequential audience for any leader is the team they lead. Senior stakeholders read leaders for evaluation. The team reads leaders to understand what is actually being asked of them and what they will be supported in doing.

The team reads action and disregards speech when the two diverge. A leader who says architectural quality matters but funds only delivery is read as not actually valuing architectural quality. A leader who says long-term investment is essential but defers it under every quarterly pressure is read as treating long-term investment as discretionary. The team adjusts their behaviour to what is funded, not to what is said.

The team’s reading determines the daily reality of the technology function. The team’s daily behaviour mirrors the signal the operating model transmits. An inconsistent signal produces inconsistent execution. A consistent signal produces aligned execution. The signal the team reads is the one that actually operates.

The Filter.

The signal is produced by the leader. The reading is produced by the audience. Different audiences read the same signal differently.

A leader pushing for long-term landscape investment is read by some senior stakeholders as governance excellence and by others as commercial weakness. The senior stakeholder operating under quarterly pressure reads investment in containment design as cost. A senior stakeholder with a longer horizon reads the same investment as essential infrastructure for the strategic options the company will need in three years.

The stakeholder pushing for rapid feature delivery reads architectural review forums as bottlenecks. A stakeholder who has lived through significant production failures reads the same forums as the discipline that prevents catastrophe.

The peer competing for the same budget reads your investment in long-term institutional memory as misallocation. A peer who has inherited an undocumented landscape reads the same investment as wisdom.

Same signal. Different filters. Different conclusions.

This is the political reality of senior technology leadership. The reader’s frame produces the reading. The leader who pushes for long-term landscape health while the surrounding senior stakeholders push for short-term delivery will be read by some of those stakeholders as a blocker. The reading is sincere from the reader’s position. It is also a projection of the reader’s priorities onto the leader’s behaviour.

The leader cannot eliminate this. The filters exist because the readers exist. What the leader can do is recognise that the filter is operating, distinguish between readings that contain genuine diagnostic signal and readings that are projections of misaligned priorities, and respond to each appropriately.

The Operating Model Is the Source.

The signal is the surface. The operating model is the source. The leader who wants to change the signal must change the operating model that produces it.

The operating model is the set of mechanisms that produce the daily reality of how the technology work happens. It is the structure that operates whether or not the leader is present. The patterns of how decisions, investments, conversations, and accountabilities actually flow. Not the org chart. Not the process documentation. The operating reality that emerges from how those structures are actually used.

Several elements compose it. Each transmits a signal. Each can be designed deliberately or allowed to emerge.

Decision altitude. Who makes which decisions and where the architecture is genuinely shaped versus where it is ratified after decisions have been made elsewhere. The team knows which forums are substantive within their first two meetings.

Funding patterns. What gets funded continuously. What gets funded reactively after an incident. The ratio between visible delivery and long-term landscape health. This is one of the most read signals in any technology organisation.

Postmortem governance. Whether postmortems produce documents or design responses. Whether the action items reach the funding decision or sit in a backlog.

Institutional memory mechanisms. How knowledge survives leadership transitions. Whether the reasoning behind decisions is documented in a form the next leader can read.

Each of these is an operating model choice. Each transmits a signal whether the leader has designed it consciously or not.

The second discipline is communication. The leader who has designed the operating model deliberately communicates it explicitly. Naming it. Explaining how decisions are made. Showing why specific forums exist and what they are designed to produce. This does not eliminate filtered reading. But it gives audiences the leader’s own frame for the operating model alongside their own. The surface area for projection reduces. The surface area for diagnostic engagement expands.

Reading and Being Read.

Across the leaders I have worked alongside, I have read them through specific patterns. What they funded told me what they prioritised. What they refused to surface in governance forums told me what they were avoiding. What they delegated told me what they did not understand or did not want to engage with personally. What conversations they routinely shortened told me where they were uncomfortable.

The reading was almost always accurate at the level of the operating model itself. But the conclusions I drew were filtered through my own priorities. A leader I read as cautious from one position I might have read as wise from another. The signal was constant. My reading was filtered.

I have also been read. There were moments in tenures where I became aware that the organisation was receiving signals from my operating decisions that I had not consciously designed. The signal they were reading was accurate. Some senior stakeholders read my long-term landscape investment as the discipline they had hired me for. Others read the same investment as evidence that I did not understand the commercial pressure they were under. The same operating model produced both readings.

The recognition that stayed with me. I had designed the architecture review forum to shape architectural choices for long-term outcomes. The forum was working as designed at the architectural level. But the signal it transmitted to senior stakeholders was that delivery realities were not being attended to. Architecture was reading as long-term focused but commercially detached.

I redesigned the forum to hold both realities together. The long-term architectural perspective and the short-term delivery reality in the same conversation. This addressed what was diagnostic in the stakeholder reading. The forum should not have been blind to delivery pressure. The redesign was the right move.

What emerged from the redesigned forum was the more interesting observation. With both perspectives now in the room, the decisions consistently came down on the short-term side. Every time. The forum was holding both views but the stakeholder filter was producing a consistent short-term outcome regardless of the architectural arguments being made.

This told me something diagnostic about the operating model and something projective about the filter. The original signal had genuinely missed delivery reality. That part of the stakeholder reading was diagnosis and it deserved the redesign. The structural preference for short-term outcomes that the redesigned forum revealed was projection. It was a filter operating beneath the reading rather than an assessment of the operating model itself. The redesign surfaced the distinction. The diagnostic part of the reading produced a real change. The projective part required different work.

The Judgement.

The discipline of designing and communicating the operating model is the foundation. The discipline of distinguishing between filtered readings is what completes the leader.

Some filtered readings contain genuine diagnostic signal. The senior stakeholder who reads your investment ratio as wrong for the commercial moment may be filtering through their priorities. They may also be reading something the leader has missed. The reader’s position is filtered. The reading may still contain truth the leader needs to hear.

Some filtered readings are projections. The stakeholder who reads architectural review forums as bottlenecks because they want feature delivery faster is reading through a frame that does not engage with what the forum actually does. The reading is sincere. It is also a projection.

Distinguishing between these two is one of the hardest disciplines of senior leadership. Treat all readings as projections and the leader becomes deaf to legitimate diagnostic signal. Treat all readings as diagnostic and the leader becomes responsive to projections that should not change behaviour. Either failure mode corrupts the operating model.

The judgement is built through three practices.

Test the reading against the substance. When a reader’s interpretation does not match your understanding of what the operating model is producing, sit with it honestly. Could they be seeing something you have missed. If the reading survives examination, it is diagnostic. If it does not, it is a projection.

Test the reading against the reader’s frame. Ask what the reader is rewarded for. The senior stakeholder compensated on quarterly performance has a structural incentive to read long-term investment as cost. If the reading is consistent with the reader’s incentives in a way that runs against what the operating model is actually producing, it is more likely projection. If the reading runs against their incentives, it is more likely diagnostic. The reader who has the most to lose from telling you what they have seen is usually giving you the most diagnostic signal.

Test the reading against the cumulative pattern. Single readings are noisy. The same reading repeated across multiple audiences with different incentives becomes signal. Diagnostic readings converge across readers. Projections diverge. When three different stakeholder groups arrive at the same reading, it is almost certainly diagnostic. When one group reaches a reading no other audience confirms, it is almost certainly projection.

This judgement cannot be substituted by process. It cannot be delegated. It is the work of the seat itself.

The Two Disciplines Together.

The leader who has done this work is recognisable. The operating model produces a consistent signal. The communication of the operating model gives audiences the leader’s own frame alongside their own. The filtered readings are engaged with discrimination rather than capitulation or denial.

The leader who only designs the operating model retreats into it. The leader who only navigates politics survives but does not lead. The leader who does both is doing the actual work.

The Leadership Directive.

Audit your operating model honestly. Redesign the elements producing signals you did not intend. Communicate the operating model explicitly to the audiences whose readings matter.

Then learn to distinguish. Diagnosis deserves response. Projection deserves navigation. Refuse to confuse one work for the other.

Continue. The work is not finished in any quarter. It is the work itself.

The Sutra.

Every reading you receive is partly diagnosis and partly projection. The discipline is to know which is which.

Leave a comment

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Share

Every decision your predecessors made is currently in the system you govern.

Every decision you make now will be in the system your successor inherits.

The question is whether you are leading for your tenure or for the full arc of decisions that shape the landscape.

Most technology leadership writing addresses only the present. The decisions being made now. The work being delivered now. The systems being run now. This framing is incomplete. Every system a leader operates inside was shaped by predecessors whose names may not be known and whose reasoning may not be documented. Every system a leader shapes during their tenure will be operated by successors whose judgments on current decisions will be made without the context that informs those decisions today.

The true measure of technology leadership is what is inherited on both sides of the current seat. Not what is visible during the tenure. What is inherited from the tenure. And what was inherited into it.

What Leaders Actually Inherit.

The inheritance is rarely itemised. But it is always specific.

Compounding liability accumulated under delivery pressure years ago, now manifesting as the delivery delay the current leader is absorbing quarter after quarter. Uncontained failure modes that have been surfacing across the landscape without being recognised as the same pattern. Capital commitments embedded in architectural choices made for reasons no longer documented. Boundary gaps where accountability was negotiated rather than designed.

The inheritance also includes what was done well. The bounded contexts that were correctly drawn years ago that still serve the landscape. The containment design that was funded before an incident made it urgent. The observability infrastructure that was built at the right level rather than only at the engineering level. These are the quiet assets inherited alongside the liabilities.

Every leader inheriting a seat is receiving both. Neither is immediately visible. The liabilities only surface when something goes wrong. The assets only become visible when the leader tries to do something the landscape supports because of them.

What I Inherited.

The first time I walked into a senior technology seat with significant inherited landscape, I did what most leaders do. I asked for the system diagrams. I asked for the architecture documentation. I asked for the strategy. I read everything I was given. None of it told me what I actually needed to know.

What I needed to know was what the landscape was carrying. Not what it was supposed to be doing. What it was actually holding. The coupling that nobody could explain. The fragility that was being managed silently by people who had been there long enough to know which integrations to handle carefully. The trade-offs that had been made under pressure years earlier and were still shaping every release.

The diagrams did not show this. The architecture documentation did not show this. The strategy assumed it did not exist.

What showed it was conversations. Sitting with engineers and architects who had been there for years. Listening to what they said about the system without asking them to characterise it. Watching where they moved carefully and where they did not. The landscape was being communicated by the people who had been tending it. The communication was not in the documents. It was in the texture of how the work was being done.

I spent the first six months listening rather than changing. The expectation in any new senior seat is to demonstrate value through visible change in the first quarter. I made that choice differently because the landscape had not yet revealed itself, and decisions made before the landscape reveals itself are usually the ones that have to be remade later.

What I learned in those six months stayed with me. The landscape I had inherited was carrying decisions made by leaders I would never meet. Some of those decisions had served the landscape well. Some had not. Most had been made for reasons that were rational at the time and were no longer relevant. Almost none had been documented in a form that explained the reasoning rather than the outcome.

That is the most common condition of an inherited technology landscape. Not absence of documentation. Absence of reasoning.

The Balance.

The most consequential decision in any tenure is rarely about what to do next. It is about how to hold short-term and long-term simultaneously.

The pressure on a technology leader is almost entirely short-term. Quarterly outcomes. Visible delivery. Immediate stakeholder satisfaction. The recognition system rewards short-term wins. Long-term landscape health does not produce visible value during the tenure that funds it.

The default response is to optimise for what is rewarded. Loads of short-term fixes. Sticky plasters that keep things moving. Each fix individually defensible. Cumulatively, a landscape that has been patched rather than tended.

This is the most common failure of technology stewardship. Not bad decisions. Not insufficient capability. The wrong balance.

A stagnant landscape rots quickly. An evolving landscape delivers long-term value. The choice is not between change and stability. It is between the right kind of change and the wrong kind.

The right kind. Short-term action that keeps things moving while serving the long-term direction. Each fix evaluated not only for its immediate effect but for whether it leaves the landscape healthier or weaker. Long-term investment that does not produce visible value during the current tenure but accumulates value across tenures.

The wrong kind. Short-term action that solves the immediate problem at the cost of long-term integrity. Long-term investment that has lost contact with the operational reality and is no longer serving the people inside the landscape.

Holding the balance is the work. Not choosing one. Holding both. Making short-term moves that serve the long-term direction. Making long-term investments that respect the short-term reality. The leader who only delivers short-term claims victory at the cost of the landscape. The leader who only invests long-term loses the organisation’s confidence and the political capital required to continue.

Most leaders default to short-term. Genuine stewardship requires sustained attention to both at once.

What I Will Leave.

Every decision being made during the current tenure is constructing what the next leader will receive. The architectural choices. The capital commitments. The institutional memory system. Whether the containment design is funded. Whether the compounding liability register is held visibly. Whether the postmortem process produces funded design responses.

The harder question is not what the successor will think of these decisions. They will not be there to think in abstraction. They will be there to operate the consequences. The harder question is what condition the landscape will be in when they arrive.

I do not know the name of the leader who will inherit the current landscape. I know they will judge what I am doing now without the context that informs it today. I know the work I am doing now is being done for two audiences. The current tenure’s stakeholders. And the successor who will live inside the consequences of what is being built.

The balance between these two audiences is the same balance that runs through the work itself. Honour the current tenure’s reality. Honour the future tenure’s inheritance. Hold both at once.

Most leaders address only the first audience. The second audience determines whether the tenure accumulates value or transfers liability.

Compounding Stewardship and Compounding Liability.

Every technology landscape is compounding in one direction or the other.

A landscape that has been receiving sustained stewardship across multiple tenures is compounding. The bounded contexts get clearer over time. The containment design gets stronger with each incident that surfaces a new failure mode. The institutional memory deepens. The reasoning behind decisions accumulates rather than disappearing with each leadership transition. The leader who inherits this landscape arrives with capacity. They can move strategically because the landscape supports it.

A landscape that has been receiving sticky plasters across multiple tenures is also compounding. In the opposite direction. The coupling thickens. The fragility accumulates. The undocumented decisions multiply. The reasoning behind earlier choices is lost with each transition. The leader who inherits this landscape arrives with consumption. Their first years are spent absorbing the deferred remediation that previous tenures did not fund.

The compounding direction is the leadership inheritance more consequential than any single decision the leader will make during their tenure.

Most evaluation frameworks measure tenure performance only. Outcomes delivered within the seat. Decisions made during the seat. The compounding direction across tenures is the truer measure. It is also the more difficult to capture, because it requires looking at the seat from outside the tenure that currently holds it.

This is the gap in how technology leadership is evaluated at board, investor, and executive level. The tenure is measured. The compounding direction is not. The full commercial truth of a technology leader’s work is not captured without both.

What Stewardship Actually Requires of You.

The practices of stewardship are not difficult to describe. They are difficult to do. The reason has nothing to do with capability and everything to do with disposition.

I have learned this over multiple tenures and I am still learning it.

Stewardship requires humility about what was inherited. Some of what I inherited was the work of leaders better than I was. The bounded contexts that were correctly drawn. The integrations that have held up under conditions nobody anticipated. The constraints that turned out to be wisdom in disguise. Recognising what predecessors did right requires me to set aside the instinct that anything I did not build is somehow inferior. That instinct is hard to set aside. It is also wrong.

Stewardship requires honesty about what no longer works. Some of what I inherited was rational at the time and is no longer serving the landscape. Acknowledging this is not a criticism of the predecessors who created it. It is a description of how landscapes evolve. What was right then can be wrong now without anyone having failed. Saying this in the organisation requires care. People who are still inside the landscape may have been part of those original decisions. Treating their work with respect while honestly naming what no longer serves is one of the harder disciplines of the seat.

Stewardship requires courage to surface what is uncomfortable. The compounding liabilities I have inherited are uncomfortable to surface because surfacing them implies criticism of the people who let them accumulate. The investments I propose for long-term landscape health are uncomfortable to surface because they will not produce visible value during the tenure that funds them. The decisions I am consciously deferring to my successor are uncomfortable to surface because they expose what I am choosing not to do.

Stewardship requires empathy for the people inside the landscape. The architects and engineers who have been tending the systems for years know more about what is actually happening than any leader walking in. They have been managing the inherited reality without the authority to change it. Treating them as colleagues whose knowledge is essential to the stewardship reframes the work. The landscape cannot be tended without them.

Stewardship requires leadership that takes people on the journey. Sustainable change requires the consent and participation of the people who will live inside the changed landscape. Imposing change from above produces resistance even when the change is correct. Taking people on the journey requires explaining the inheritance, naming the balance, surfacing the trade-offs, and inviting people to shape the response. It is slower. It is also the only kind of change that holds.

These are not techniques. They are dispositions. They show up in how a leader actually conducts the work day to day.

Four Stewardship Practices.

The disposition becomes visible through specific practices.

Walk the landscape before changing it.

The first six to twelve months in a senior seat are spent understanding what was inherited before any significant change is initiated. Sitting with the people who have been tending the systems. Listening to what the landscape is signalling. Forming an honest map before deciding what to do with it. The instinct to demonstrate value through visible change in the first quarter is the instinct that prevents this practice. Setting it aside is the first stewardship discipline.

Document the reasoning while it is still present.

The decisions made during the tenure are documented as reasoning, not only as outcomes. The constraints that were present. The trade-offs considered. The pressures that were active. The alternatives rejected and why. A successor inheriting documented reasoning can evaluate decisions in their original context. A successor inheriting only outcomes is forced to either accept them blindly or rebuild from scratch.

Hold the short-term and long-term simultaneously.

Each tenure makes investments in the landscape’s long-term health alongside the short-term delivery the organisation expects. The ratio is consciously chosen rather than defaulted to. Short-term wins are evaluated for whether they leave the landscape healthier or weaker. Long-term investments are evaluated for whether they remain connected to operational reality. The balance is the work.

Name what you are leaving without apology or evasion.

The exit from the seat, planned or otherwise, includes an explicit handover of what is being left. What was inherited. What was remediated. What was deferred and why. What patterns the next leader should be alert to. A handover that names what is being left clearly transfers value. A handover that obscures or deflects transfers ambiguity.

These four practices form a temporal arc across a tenure. Beginning, by walking the landscape. Across, by documenting the reasoning and holding the balance. End, by naming what is being left.

The Leadership Directive.

The seat is never held alone. It is held between the leader who left it and the leader who will inherit it. Across that span, the landscape either evolves or it rots. There is no third condition.

Every leader currently in a senior technology seat is making this choice now.

The choice is not whether to lead. It is whether to lead for the tenure or for the landscape.

The Sutra.

Inherit honestly. Tend deliberately. Leave better than you received. The seat carries no other measure that lasts.

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Leave a comment

Share

Every delivery delay, every scaling constraint, every incident, every regulatory response that went too slowly had a predecessor that recorded the same signal in the system.

The question is whether your governance was designed to read it. Or whether each new surface had to translate it again.

Every architectural choice is present in the integration. Every coupling introduced under delivery pressure is embedded in the code. Every trade-off deferred during a programme that has since closed is carried forward in the behaviour of the system under load. The system does not forget. It cannot forget. Every decision is structural.

The gap is not what the system remembers. The gap is what the organisation has been designed to hold from what the system has recorded.

The Term Is Misdirecting the Governance Response.

The term most organisations use for what accumulates in a system over time is technical debt. It is imprecise in the way that matters most.

The word technical places the liability in the architects and engineers. It implies the debt was created by the people deferring work they should have done. This is rarely the accurate account. The debt was more often created by decisions made above the technology team. Delivery pressure. Underfunded timelines. Prioritisation calls that treated architectural investment as secondary to feature delivery. The architects and engineers were the executors of these decisions. Not the authors of them.

The word debt implies deferred work rather than accumulated consequence. It produces a governance response that treats the accumulation as a backlog of things to be cleaned up when there is time. Backlogs are engineering artefacts. They compete with feature delivery. They almost always lose.

Both elements of the term misdirect the governance response. The architects and engineers are held accountable for a liability they did not create. The backlog framing produces competition it cannot win. The liability grows.

What It Actually Is.

The more precise term is compounding organisational liability. It has three layers.

Layer 1. Organisational decisions.

The decisions made across the business and technology boundary under delivery pressure, misaligned incentives, and underfunded timelines. These are the decisions that created the conditions within which the architects and engineers did their work. The liability is organisational in origin and ownership.

Layer 2. Architecture & Engineering manifestation.

The physical expression of the Layer 1 decisions in the system. Coupling that was not resolved. Fragility that accumulated incrementally. Trade-offs made under pressure and never revisited. This is where the liability becomes visible. But it did not originate here.

Layer 3. The surfaces where the liability manifests.

The compounding liability does not only surface as incidents. It surfaces as a constraint on the organisation’s ability to act. Four manifestations appear consistently.

1. The incident. The catastrophic surface. The principal arriving after years of interest payments.

2. The delayed functional delivery. The organisation wants to launch a new product, capability, or feature. The existing architecture cannot absorb it. What should have been a three-month delivery becomes a twelve-month remediation programme. The competitive window closes.

3. The non-functional scaling constraint. The system cannot carry increased load, new geographic regions, or new volumetric demands. The organisation can sell the capability but cannot deliver it at scale.

4. The regulatory or market response failure. Regulations evolve. Markets shift. The organisation needs to change something structural to respond. The existing architecture makes the change economically or technically infeasible within the required timeline. The organisation absorbs penalties or loses commercial position because the compounding liability has removed its optionality.

All four are the same liability manifesting differently. The incident is the most dramatic surface. For most organisations most of the time, the other three are the more common and more commercially consequential.

Between Layer 1 and Layer 3, the liability compounds. Each delivery cycle that defers the governance response adds to the accumulation. The interest is paid in engineering effort absorbed, in workarounds maintained, in institutional fragility carried forward. The principal arrives when the cumulative weight breaks through to one of the Layer 3 surfaces.

This distinction determines who is accountable for governing it. Compounding organisational liability is not an engineering backlog item. It is an organisational exposure that requires governance at the same level as the decisions that created it.

What the Liability Looks Like From the Inside.

Across programmes I have been directly involved in, a specific pattern appears in postmortems. A previous postmortem had identified the same failure mode. The design response was recommended. The funding was not committed. The next incident is not a surprise from the system’s perspective. The system had been signalling the same compounding liability since the first incident. The organisation’s institutional memory had recorded the signal. The governance system had not acted on it.

In one programme I was directly involved in, this was the moment that changed how I think about governance of technology liabilities. The cascade that produced the incident had two roots at the Layer 2 manifestation level. Coupling that had been introduced under delivery pressure eighteen months earlier and never decoupled. And accumulated data model changes that had made a downstream integration fragile in ways that no single change review would have caught. Both were engineering and design manifestations of organisational decisions made under delivery pressure. The postmortem that followed identified both. Then the team found the previous postmortem. The same coupling had been identified eighteen months earlier. The design response had been recommended. The funding had not been committed. The system had remembered. The organisation had not been designed to hold the memory long enough to act on it.

The same liability had been manifesting at the other Layer 3 surfaces for months before the incident. A functional capability launch had been delayed. A scaling initiative had been quietly scoped down. These were not recognised as the same pattern. They were treated as separate delivery problems. The incident was the moment the pattern became undeniable.

Had the liability been framed correctly from the first postmortem, the design response would have been on the governance agenda as a funded capital exposure rather than as an engineering backlog item. The coupling would have been decoupled. The cascade would not have occurred. The functional launch would have been on time. The scaling initiative would not have been scoped down.

The failure was not that the organisation did not know. The failure was that the knowledge was held in a form the governance system was not designed to read, because the term that should have framed it as a governance exposure had instead framed it as an engineering problem.

The Governance Gap.

Most organisations have not addressed compounding organisational liability for three reasons. Each is a governance design failure that the misframing produces.

The first. The liability register is held as an engineering backlog rather than as a capital exposure. The items on it are described in engineering terms. They are prioritised against engineering work. They never reach the governance level where the decisions that created them were made. The liability accumulates unseen by the only people with the authority to fund the response.

The second. The postmortem is treated as a cultural exercise rather than a governance event. The blameless conversation produces a document. The document produces action items. The action items enter the backlog. The urgency dissipates within days of the incident closing. The knowledge the system generated is not made durable. The measure of a postmortem’s integrity is not whether the conversation was blameless. It is whether the conversation produced a funded design response within a defined governance timeline. Most do not.

The third. The observability design is held at the technology team level rather than the governance level. The Layer 2 manifestations are visible to the architects and engineers through logs, metrics, and traces. They are not visible to governance through a framing that connects them to the Layer 1 decisions that created them or the Layer 3 surfaces they are compounding toward. Governance is operating against a partial view of the liability it is accountable for.

All three failures are produced by the same misframing. The liability is treated as technical when it is organisational. It is treated as debt when it is compounding exposure. The governance response is calibrated to the wrong problem.

What Governance Must Do.

The constructive move. Three disciplines that make compounding organisational liability governable. Each addresses one of the three gaps above.

The register of compounding organisational liability is a governance instrument. Its items are capital exposures expressed in terms the board can price. Each item carries three dimensions. The Layer 1 organisational decision that created it. The Layer 2 manifestation currently visible in the system. The projected Layer 3 surface profile if the liability is not funded, covering potential incident exposure, delivery constraint, scaling constraint, and regulatory response constraint. The register is reviewed at governance cadence alongside other capital exposures.

Measure postmortem integrity by funded design response.

The postmortem is a governance event, not a cultural one. Its measure is what percentage of postmortems in the last twelve months produced a funded design change within a defined timeline. If the number is close to zero, the organisation is generating knowledge that the governance system is not acting on. The blameless cultural achievement is preserved. The governance accountability for what the conversation produces is added.

Design observability at governance level.

The observability design should be reviewed at the same governance level as the system design. Its purpose is not engineering telemetry. It is governance visibility. Can the organisation measure what matters to customers and regulators in real time. Can it measure the compounding liability accumulating at Layer 2 before it surfaces at Layer 3. If not, governance is accountable for a system it cannot see.

Together these three disciplines make the full three-layer framework governable. The register holds the liability. The postmortem translates surfaces into design responses that reduce it. The observability makes the accumulation visible before any of the Layer 3 surfaces makes it visible catastrophically.

An estate evaluated against these three disciplines is a fundamentally different asset from one evaluated only on its current systems.

The Leadership Decision.

The misframing of compounding organisational liability as technical debt is not an engineering mistake. It is a governance one.

The organisation that accepts the technical debt framing has accepted that its most consequential accumulating liability will be held as an engineering backlog. The organisation that accepts the register at the engineering level has accepted that the liability will not be priced at the level where the decisions that created it were made. The organisation that accepts postmortems as cultural exercises has accepted that the knowledge its systems generate will not be made durable.

All three are leadership decisions dressed as engineering practices.

The system remembers every decision. The question is whether the governance system has been designed to hold what the system has recorded, price what it has held, and fund the response before the next surface, whether that is an incident, a delayed launch, a scaling constraint, or a regulatory response failure, makes the cost of not funding it unavoidable.

The Sutra

If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.

Share

How much of your engineering investment last year went to containing failure versus preventing it.

Most programmes cannot answer that question precisely because they have never framed it that way. And what is not named in a budget is not a priority. It is a risk.

Containment design is the discipline of bounding failure so that it cannot propagate beyond the capability where it originates. The unit of that discipline is the fault domain. A fault domain is an explicit boundary drawn around a capability or component. Within that boundary isolation governs what stays inside when something goes wrong. Failure within a well-isolated fault domain cannot reach the capabilities beside it. A circuit breaker enforces that isolation operationally. When a component begins behaving outside its designed parameters the circuit breaker stops propagation before the blast radius expands. The blast radius is the scope of customer and business impact when a failure occurs. Containment design does not prevent failure. It determines how much of the system and how many customers are affected when it arrives.

A card payment authorisation system with well-designed containment will degrade to stand-in processing, a reduced but functional alternative, when the primary authorisation engine fails. The customer continues to transact. The failure is isolated. It does not cascade into account management, statement generation, or any adjacent capability.

A system without containment design will execute four million erroneous orders in 45 minutes when a single misconfigured server activates dormant code. There is no circuit breaker. The blast radius is the entire operation.

The difference between those two outcomes is not the quality of the engineering. It is the presence or absence of a deliberate containment design.

Most organisations understand this in principle. Almost none fund it in practice. The reason is cultural before it is financial.

The Prevention Illusion.

When something fails, two things happen simultaneously. The technical response begins. And the cultural response begins.

The technical response is about what failed. The cultural response is almost always about who failed. And in organisations where the cultural response dominates, the technical response is shaped by it. The postmortem becomes a performance. The action items become a record of accountability rather than a plan for design improvement. The fault domain gap that would require investment to address is noted and deferred.

This is not cynicism. It is organisational physics. In a blame culture, naming anticipated failure is indistinguishable from accepting personal responsibility for it. No engineer or architect will voluntarily design a fault domain that explicitly anticipates the failure of the capability they own. The political cost is too high. The immediate reward is invisible.

The result is a programme optimised for prevention. Zero downtime targets. Ambitious reliability standards. All built on the assumption that careful enough design can avoid failure. The assumption is wrong in the general case. And it produces a specific consequence. Systems that have not been designed for the failures they will inevitably experience.

Earlier in this series we established that commitment is irreversible and architectural consequence is permanent. If both are true then the question for any system is not whether it will fail. It is what the consequence of that failure will be when it does. Containment is the engineering discipline that governs that consequence. The funding gap is the leadership failure that prevents it from being built.

The Funding Gap.

Two patterns appear consistently across organisations. Together they explain why the gap between knowing failure is inevitable and designing for it persists.

Pattern one. The postmortem that produced a document but not a design change.

An incident occurs. A blameless postmortem is held. The root cause is identified. Action items are written. The urgency dissipates. The next sprint is committed to feature delivery. The containment improvement sits in the backlog. It is never prioritised. The same fault domain fails again under different conditions six months later.

This is a framing failure before it is a prioritisation failure. The postmortem is framed as a learning exercise rather than a design review. Learning is cultural. Design is funded. What is not funded is not built.

Pattern two. The incident review that identified the fault domain gap but never funded the containment work.

The gap reaches a governance conversation. The fault domain risk is named. A containment investment recommendation is made. The recommendation is declined. The business case for feature delivery is more visible than the business case for containment. Customer outcomes are legible. Blast radius reduction is not.

This is where the framing failure becomes a leadership failure.

The containment work was framed as competing with customer delivery. That framing is precisely backwards. Every failure that was not contained ultimately destroyed the customer outcomes the feature delivery was building toward. The customer who cannot complete a card payment because a fault domain failure propagated across an uncontained boundary has not received a customer outcome. Containment design is customer outcome delivery. It is simply the part of customer outcome delivery that is invisible until it fails.

This is what that invisibility looks like from the inside.

The Boundary That Was Not Designed For.

As Engineering Lead for Card Payment Authorisation and Clearing, following a Visa compliance release, I encountered the containment design gap in its most instructive form.

Every internal measure showed the system as healthy. Metrics nominal. Alerts silent. Scheme partners were experiencing timeouts.

The fault domain failure was at the boundary. The observability had been designed to measure health from inside the domain. It had not been designed to measure the blast radius of a failure as experienced from outside it. The system appeared contained because we were measuring from the wrong position.

The containment question the incident revealed was this. What is the failure mode at this service boundary and has it been explicitly anticipated. The answer was no. The failure mode had not been designed for. The blast radius was discovered rather than bounded.

This is the pattern I have observed consistently across programmes. The fault domain is technically defined. The failure mode at the boundary of that fault domain is not. The containment design exists within the domain. The boundary between domains is where the most consequential failures find their home.

What Uncontained Failure Actually Costs.

On August 1 2012, Knight Capital Group, then responsible for approximately 10% of all trading in US equity securities, experienced what the absence of containment design produces at scale.

A deployment error left one of eight trading servers running deprecated code. When the market opened, orders triggered the dormant code. No circuit breaker. No isolation infrastructure to bound the blast radius of a single misconfigured server. In 45 minutes the system executed 4 million orders across 154 stocks. Ninety-seven automated error emails were generated and went unaddressed. The loss was 440 million dollars. A company built over 17 years effectively ceased to exist before lunch.

The failure was not the deployment error. Human errors in deployment are foreseeable. The failure was the absence of containment design that would have bounded what a single misconfigured server could do before the blast radius became irreversible.

The SEC enforcement action that followed named the most important detail for this argument. The firm reacted to prior events too narrowly and did not adequately consider the root causes of previous incidents. Knight Capital had experienced prior incidents. They produced postmortems. They responded. The responses were too narrow. The root cause was not funded. The fault domain that destroyed the firm was the predictable consequence of a pattern of learning from failure rhetorically without designing for it structurally.

Knight Capital did not fail to fund failure. It funded the remediation after each prior incident. It simply never funded the containment before the incident that ended it.

What Designing for Failure Looks Like.

If we assume this will fail, what must we build before it does.

That question governs the organisations that design for failure rather than against it.

Netflix built Chaos Engineering as an institutional response. Their approach of deliberately injecting failure into production systems rests on one insight. If you do not test your containment design you do not know whether it works. And if you do not know whether it works your reliability targets are aspirations rather than guarantees.

Amazon’s cell-based architecture applies the same philosophy structurally. The system is divided into isolated cells such that a failure within one cell cannot propagate to adjacent cells. The blast radius of any failure is bounded by design before deployment rather than discovered during an incident.

Both approaches rest on the same foundation. Failure is not a risk to be managed. It is a certainty to be contained. That acceptance requires an investment decision before an incident makes it urgent.

The following questions make that investment decision practical rather than philosophical.

The Containment Design Framework.

Five questions. Designed to work at two levels simultaneously.

For engineers and architects.

What are the fault domains in this architecture. If they are not explicitly designed their blast radius is undefined.

What is the failure mode at each service boundary. If it has not been anticipated it will be discovered during an incident. The boundary between domains is where the most consequential failures find their home.

What is the circuit breaker. If a component begins behaving outside its designed parameters what is the mechanism that stops propagation before human intervention is possible. Knight Capital’s 97 unaddressed error emails are the illustration of its absence.

For boards and CTOs.

What is the blast radius of the organisation’s highest risk failure scenario calculated from a customer harm perspective. Has the board seen that number. If not the board has accepted an exposure it has not priced.

If the regulator reviewed the organisation’s response to prior incidents tomorrow would they find root causes addressed or responses too narrow. The SEC found the latter at Knight Capital. The question is whether they would find the former at yours.

The Leadership Decision.

Containment design is not an engineering decision. It is a leadership decision about what kind of relationship the organisation has with failure.

The leader who frames all investment as customer outcome delivery and containment work as engineering overhead has not made a customer-centric decision. They have accepted a framing that will eventually destroy the customer outcomes they are protecting by not funding it.

The customer outcomes are visible. The blast radius of their absence is not. Until it is.

The containment work that has not been funded is a capital allocation decision that has already been made. The postmortem that did not produce a design change is a governance decision that has already been made. The blast radius that has not been calculated is an exposure that has already been accepted.

Failure is coming. The blast radius is a choice. And the funding decision is a leadership one.

The Sutra

Failure is always funded. The question is whether you fund the containment before it or the remediation after it.

Leave a comment

Share