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

How many architectural models is your organisation running simultaneously.

And how many accountability models have been explicitly designed to match them.

If the second number is smaller than the first, that gap is not an oversight. It is the governance risk the architecture diagram will never show.

The Perception Problem.

Two contradictory perceptions govern most architectural conversations in financial services.

The first. The monolith is legacy. Every mature organisation should be moving toward microservices and distributed architecture. The future is decentralised.

The second. Distributed systems are too complex. The monolith was simpler and the move away from it was a mistake.

Both perceptions are wrong in the general case. Both produce expensive decisions.

The perception precedes the analysis in both cases. The architecture is chosen before the domain is understood. The accountability model is designed, if it is designed at all, after both.

Domain Driven Design as the Governing Framework.

The intellectual framework that makes the right architectural choice possible is Domain Driven Design. Not as a methodology for distributed systems specifically. As a way of thinking about domain boundaries that applies equally to modular monoliths, distributed services, and hybrid estates.

Eric Evans introduced the bounded context as the unit of domain analysis. Within a bounded context the language is precise, the ownership is clear, and the rules of the domain govern every decision. Across the boundary an explicit contract governs the interaction.

The critical insight for the architectural conversation is this. Bounded contexts apply to both models.

In a well-designed modular monolith, bounded contexts are module boundaries. The domain logic is separated. The coupling is managed through internal interfaces. The context is independently modifiable within the monolith even though it is not independently deployable.

In a distributed system, bounded contexts are service boundaries. The domain logic is independently deployed. The coupling is managed through external contracts. The context is independently modifiable and independently deployable.

The shift from modular monolith to distributed is not a shift in domain thinking. It is a decision to make the bounded context independently deployable rather than independently modular. That distinction determines which model serves the domain rather than which model the organisation prefers.

This means the modular monolith deserves recognition as a legitimate architectural destination in its own right. Not a stepping stone to microservices. For many organisations and many domains it is the right answer.

When the Modular Monolith Is Right.

The modular monolith is right when the domain characteristics favour strong consistency, stable boundaries, and contained complexity.

The general ledger is the canonical financial services example. A ledger entry that must update multiple accounts atomically, maintaining double-entry integrity across a complete set of books, requires strong transactional consistency. Distributing that capability introduces complexity that is expensive to manage and risky to get wrong. The consistency requirement is not a technical preference. It is a regulatory and commercial obligation. The domain characteristic governs the architectural choice.

The modular monolith is also right when domain boundaries are not yet well understood. Distributing a domain whose boundaries are still being discovered produces services that will need to be redesigned as understanding develops. The cost of reorganising incorrectly drawn service boundaries is significantly higher than reorganising module boundaries within a modular monolith.

The honest trade-off. The modular monolith’s strength is consistency and simplicity at the boundary. Its hidden cost is the complexity that accumulates internally when bounded context discipline is not maintained. The coupling grows. The regression surface expands. The cost arrives when the organisation needs to change at a rate the internal complexity cannot support.

When Distribution Is Right.

Distribution is right when the domain characteristics favour independent evolvability, differential scalability, and clear bounded context ownership.

Payment instruction initiation illustrates this well. The capability that initiates a payment instruction has different scalability requirements, different release cadence needs, and different ownership characteristics from the capability that settles it. These are distinct bounded contexts with different consistency requirements and different rates of change. Distributing them enables each to evolve at its own pace without the coordination overhead a shared deployment boundary would impose.

The honest trade-off. Distribution’s strength is independent evolvability and fault isolation. Its cost is operational complexity, observability requirements, and the accountability discipline required to maintain genuine independence across service boundaries. The coordination a modular monolith handles internally through shared transactions must be handled externally through contracts, messaging, and distributed consistency mechanisms.

A distributed system without explicit ownership at every service boundary has not achieved the independence it was designed for. It has achieved technical decentralisation while remaining organisationally coupled. Responsibility does not follow the architecture. It must be designed alongside it.

The Financial Services Hybrid Reality.

Understanding the hybrid requires capability-level analysis rather than domain-area-level labels.

Most financial services organisations are running a hybrid estate. Not by design. By history, regulatory constraint, and strategic evolution. And the hybrid is not simply modular monolith here and microservices there. It is a collection of capabilities each with its own domain characteristics, each requiring the model that best serves its consistency requirements, scalability needs, and ownership characteristics.

The general ledger may suit modular monolith characteristics. Product configuration management may have different evolvability needs that suit distributed characteristics. Payment instruction initiation may have different characteristics again. These are not all the same model because they sit within the same broad domain area. They are distinct capabilities that should be evaluated individually before an architectural model is assigned.

What is often called the digital channel adds a further nuance. A mobile banking application or internet banking platform is not a domain in its own right from a DDD perspective. It is a presentation and orchestration layer that consumes domain services. Its architectural characteristics are driven by its role as a consumer and orchestrator rather than by domain ownership. Treating it as a domain produces bounded context boundaries determined by channel rather than by business capability.

DBS Bank’s transformation, recognised by Harvard Business Review as one of the top ten strategic transformations of the decade, offers one of the most instructive publicly documented examples of accountability designed alongside architecture at scale. Rather than assuming accountability would follow architectural decisions, DBS created 33 platforms each aligned to a business segment or product domain, and each jointly led by a business leader and a technology leader through a two-in-a-box model. A structured approach to classifying capabilities as decommission, invest, or retain preceded the architectural decisions. The accountability model was not an afterthought to the architectural model. It was designed with the same deliberateness.

The Three Accountability Models a Hybrid Requires.

Most organisations design one accountability model for their entire estate. A hybrid estate needs three simultaneously.

Modular monolith accountability requires clear ownership of the whole, clear governance of the internal change process, and active maintenance of the bounded context discipline within the modular monolith. Without this discipline the modular monolith degrades into an unstructured one and the hidden complexity cost accelerates.

But explicit modular monolith accountability alone is insufficient in a hybrid estate.

Distributed accountability requires clear ownership of each service boundary aligned to a bounded context and explicit governance of inter-service contracts. The ownership must be assigned before the service is deployed. Not discovered during the first incident that crosses its boundary.

But explicit distributed accountability alone leaves the most consequential surface unaddressed.

Boundary accountability is the most frequently absent. It is the ownership of the API contracts, the consistency guarantees, and the failure behaviour at the points where the modular monolith and the distributed services meet. This accountability surface is created by the hybrid itself. It requires explicit design and explicit ownership. Without it the hybrid estate has two accountability models and one accountability gap. The gap is where the most consequential failures will find their home.

In one programme I was directly involved in, the loyalty domain owned value calculation based on transaction behaviour rather than passing responsibility downstream through flags. The boundary was drawn with accountability in mind from the outset. The domain owned its outcome. When something went wrong there was no ambiguity about who was responsible for understanding and resolving it. The ownership clarity produced the response clarity. The blast radius of every failure within that domain was contained because the accountability was explicit before the incident rather than negotiated during it.

That clarity does not emerge from the architecture diagram. It is a leadership decision made before the diagram is drawn.

The Leadership Decision.

The accountability model is not a technical design decision. It is a leadership decision about how responsibility is structured across the organisation.

Technology can enable distributed accountability. Only leadership can require it.

The organisations that navigate hybrid estates well are not the ones with the most sophisticated architecture. They are the ones where the domain thinking preceded the architectural decision, where the architectural decision preceded the accountability design, and where leadership treated all three as governance responsibilities rather than technical ones.

The domain model and the accountability model are the two most important signals about a technology estate that the architecture diagram does not show. An estate with clear bounded context thinking and explicit accountability at every boundary is a fundamentally different proposition from one with technically sophisticated services and implicit ownership. The difference is not visible in the diagram. It is visible in the governance conversation and in the incident response.

The architecture diagram shows what was built.

It does not show whether anyone is responsible for it.

The Sutra

A system can be distributed by design. Accountability never distributes itself.

Share

Leave a comment

If that conversation has not happened, the resilience architecture built in its absence is protecting assumptions rather than commitments.

The Wrong Starting Question.

Most resilience conversations begin with technology.

How much redundancy is needed? What is the failover capability? What availability target should the platform be designed to meet? These are reasonable questions. They are also the second questions. Not the first.

The first question is this. What does the customer actually need this system to do, and what is their tolerance when it cannot do it fully?

Without that answer the technology conversation has no anchor. It optimises for technical perfection rather than customer commitment. The result is a resilience architecture that is simultaneously over-engineered in some places and wrong-engineered in others.

Over-engineered because without customer criticality definitions the default is to protect everything at the highest level. Every component receives maximum resilience treatment regardless of its position in the customer journey or the customer’s actual tolerance for its unavailability. The cost is significant. The commercial justification is weak.

Wrong-engineered because the application-layer resilience that would have protected the customer journey during a partial failure was never built. The graceful degradation. The throttling. The stand-in patterns. Nobody translated the customer journey into the application-layer requirement it implied. Infrastructure was hardened. The customer experience remained fragile.

Both failure modes emerge from the same absence. The customer lens was not present when the resilience conversation began.

What I Observed Directly.

During a major platform build I was part of, the resilience architecture was designed before customer criticality had been defined.

The team was technically capable. The intent was genuine. But without knowing which parts of the customer journey were genuinely critical, which could tolerate degradation, and which needed full protection, the architecture defaulted to the most demanding scenario across the entire platform.

Every component was treated as if its unavailability were equally catastrophic. Infrastructure redundancy was sized accordingly. The investment was significant.

What the investment did not produce was application-layer resilience connected to specific customer journeys. The question of which journeys could degrade gracefully, which could be throttled under load, and which required a stand-in capability to maintain the customer experience during a primary system failure was never asked in the architecture conversation. It was a technology conversation designing to a technical standard rather than a business and technology conversation defining a customer commitment.

The platform was delivered. It worked. But the resilience investment was disproportionate to what the customer actually needed, and the specific protections the customer most needed were the ones that had not been built.

Customer Criticality as the Governing Frame.

Not all parts of a customer journey carry the same criticality. This is the insight that changes the resilience conversation from a technical exercise to a joint business and technology responsibility.

A card payment authorisation journey has different criticality from a statement view journey. A real-time balance enquiry has different criticality from a historical transaction search.

The customer’s tolerance for unavailability, degradation, or delay varies significantly across these journeys. In some cases any failure is unacceptable. In others a degraded service, a delayed response, a reduced feature set, is entirely acceptable provided the core customer need is met.

Defining customer criticality is the joint responsibility that governs everything that follows in the resilience conversation. Business defines what the customer needs and their tolerance when it is unavailable. Technology derives the architecture from those definitions.

This reframes RPO and RTO as customer commitment expressions rather than technical parameters. Recovery Point Objective and Recovery Time Objective are not numbers to be set by the infrastructure team against a technical standard. They are commitments to be derived from the business’s understanding of customer tolerance. The question is not what the infrastructure can support. It is what the customer journey requires, and what does that demand of the infrastructure.

Had this framing been present in the platform build described above, three things would have changed. The infrastructure investment would have been tiered to customer criticality rather than uniform across the platform. The application-layer resilience requirements would have been defined before the architecture conversation began. The commercial justification for the resilience investment would have been connected to customer outcomes rather than technical standards.

The Three Layers of Customer-Connected Resilience.

With customer criticality as the governing frame, the three dimensions of resilience become customer protection expressions rather than technical specifications.

Headroom and redundancy connect to RTO. The recovery time the customer journey requires determines the redundancy investment needed. A card payment authorisation journey that requires near-instant recovery demands a different redundancy architecture from a reporting capability the customer can wait minutes or hours to access. Sizing headroom and redundancy from the customer’s RTO requirement rather than from a uniform technical standard produces an investment that is both appropriate and defensible.

Graceful degradation connects to customer journey criticality. Not every failure needs to be total. For many customer journeys a degraded service is significantly better than no service. Throttling as a specific mechanism reduces request volumes to protect core capability rather than allowing the full system to fail under load. The customer who receives a slower response is better served than the customer who receives no response at all. This is where the application-layer resilience conversation lives. Infrastructure redundancy protects against the system going down. Graceful degradation protects the customer experience when parts of the system are under stress. Both are necessary. The second is consistently under-invested in because it requires the customer journey to have been defined before the architecture conversation begins.

Blast radius containment connects to customer segmentation. When a component fails the question is not just whether the system recovers. It is which customers are affected and how the impact is bounded by design. A failure affecting a specific product type should not affect customers on other product types. A failure in a non-critical service should not prevent access to a critical one. Containing the blast radius is a customer protection decision as much as a technical one.

The Stand-In Architecture Pattern.

The stand-in architecture pattern is the most concrete expression of application-layer resilience and one of the most underutilised outside the domains where it has been established for decades.

In card payment authorisation, stand-in processing has been a standard resilience mechanism in financial services for a long time. When the primary authorisation system is unavailable, the stand-in processes transactions against a local authorisation table, applying predefined risk parameters to approve or decline transactions without real-time access to the primary system. The customer payment journey continues. The risk is managed within defined parameters. The primary system outage is invisible to the cardholder at the point of payment.

This is application-layer resilience in its most mature form. The customer commitment, card payment authorisation will be available, is maintained even when the primary infrastructure is unavailable. The stand-in does not replicate the primary system. It provides a defined, bounded, acceptable alternative that keeps the customer journey moving.

The same pattern is applicable across other domains where the cost of complete unavailability significantly exceeds the cost of operating with reduced capability. In digital banking, a stand-in for balance enquiry could serve cached balances during a core banking outage, maintaining the customer’s ability to check their position while the primary system recovers.

In each case the stand-in is not a technical fallback. It is a customer commitment fulfilment mechanism. Its design starts with the question. What does the customer minimally need this system to do, and what is the acceptable risk of providing that minimum outside the primary system.

That is a business question before it is a technology question.

The Commercial Defensibility of Customer-Framed Resilience.

Resilience investment framed as infrastructure redundancy always faces the same commercial challenge. The cost is visible and present. The benefit is hypothetical and future. The CFO who questions whether the organisation needs two of everything is asking a reasonable commercial question. The technology leader who cannot answer it in customer terms is having the wrong conversation.

Resilience investment framed as customer commitment protection is a different conversation entirely.

The cost is still visible and present. But the benefit is now expressed in terms the board and the CFO can evaluate. What is the cost of a card payment authorisation outage to a customer who cannot complete a transaction at point of sale. What is the cost of a digital banking outage to a customer who cannot access their account during a critical moment. What is the trust cost of a failure that was preventable with an investment the organisation chose not to make.

The joint business and technology ownership of the resilience conversation is what makes this framing possible. Business defines the customer commitment. Technology prices the investment required to honour it. The CFO and the board evaluate a commitment and its cost rather than a technical standard and its price.

That is a conversation that can be won before a failure occurs.

What Becomes Possible.

The organisations that get resilience right do not have better infrastructure than those that do not.

They have a better conversation. One that starts with the customer journey, defines the commitment, and derives the architecture from what the customer actually needs rather than what the technology function assumes they need.

Resilience is not a technology problem that occasionally affects customers. It is a customer commitment that technology is responsible for honouring alongside the business that defined it.

The Sutra

Resilience begins with a question only the customer can answer. Most architectures are built before anyone asks it.

Leave a comment

Most architectural decisions do not feel like capital decisions at the moment they are made. They feel like technical choices. Platform selections. Build versus buy evaluations. Boundary definitions. The language is architectural. The participants are technical. The capital consequence is present but invisible until it surfaces as a budget problem, a vendor negotiation, or a transformation programme that costs three times what anyone expected.

Architecture and capital allocation are not adjacent disciplines. They are the same discipline, practised in different rooms by people who rarely talk to each other before the commitment is made.

The Conversation That Is Missing.

Two conversations happen in most technology organisations that should be one.

The architecture conversation evaluates technical fit, boundary design, and capability ownership. The capital conversation evaluates cost, contract terms, and budget impact. Both are necessary. Neither is sufficient alone.

The gap between those two partial views is where the most expensive technology decisions live. Not because anyone made a poor decision. Because each conversation was solving its own part of the problem without seeing the whole.

Deferred Complexity as Capital.

Every architectural decision has a capital expression.

Some decisions deploy capital now and reduce future cost. A clean domain boundary that makes future change cheaper. A build decision that owns a strategic capability rather than depending on a vendor to evolve it.

Some decisions defer complexity into the future where it accumulates interest. A vendor dependency that looks attractive at the point of signing and expensive at the point of change. A boundary decision that moves a problem downstream rather than solving it.

Deferred complexity is a precise financial concept. When an architectural decision moves complexity into the future it creates a liability. The organisation will pay the cost eventually. The question is whether it understood it was taking on the liability at the point of decision.

This is what I observed directly in an analytics platform decision. The vendor was eager to secure a multiyear contract. The headline terms were attractive. The architecture and commercial conversations happened in sequence rather than together. The architecture team evaluated technical capability. The commercial team negotiated the contract. Both reached reasonable conclusions given the information each had.

What neither conversation fully surfaced was the total cost of ownership over the contract term.
The licensing structure was tiered in a way that made initial costs manageable and renewal costs significantly higher. The cost of change was tied to vendor professional services rates that were not capped in the contract. The cost of integration maintenance as the surrounding architecture evolved was carried entirely by the internal engineering team. The cost of exit was not evaluated at all.

Over five years the total cost of ownership was significantly higher than the headline deal had suggested. Not because anyone had been dishonest. Because the capital consequence of the architectural decision and the architectural consequence of the capital decision had been evaluated separately.

The analytics capability was genuinely a commodity. The buy decision was correct. The capital discipline around it was insufficient.

The capital discipline question changes depending on what kind of capability is being decided upon.

The Commodity Versus Strategic Differentiator Distinction.

Not all capabilities carry the same strategic weight. The most important question in the build versus buy conversation is not what is cheaper to acquire. It is what kind of capability is being decided upon.

A commodity capability is necessary but not differentiating. Every organisation in your sector needs it. None compete on it. Buying it is correct provided the TCO analysis is rigorous across the full term of the decision.

• Licensing structure.

• Cost of change.

• Cost of exit.

• Cost of dependency.

These are architectural numbers that belong in the commercial room.

A strategic differentiator is a capability that defines how the organisation competes. Buying it from a vendor creates a dependency in the thing that matters most. The organisation’s ability to evolve its differentiator is now subject to a vendor’s product roadmap, commercial model, and strategic priorities. Building is more strategically correct when the organisation’s ability to evolve the capability determines its competitive position.

Two organisations illustrate this distinction at a scale that makes the principle unmistakable.

• Apple’s transition from Intel processors to its own silicon, beginning with the M1 chip in 2020, was a build decision on a strategic differentiator. Apple competes on the integration of hardware and software experience. Depending on Intel meant Apple’s most important competitive capability was partially governed by a vendor whose strategic priorities were not aligned with Apple’s. Building its own silicon removed that dependency entirely. The benefits were immediate and compounding. Significant performance per watt improvement. Tighter hardware and software integration enabling capabilities impossible on third party chips. Removal of Intel’s product roadmap from Apple’s strategic timeline. Gross margin improvement across hardware products. Control of the full customer experience from chip to operating system to application.

• Amazon built its fulfilment infrastructure rather than depending on third party logistics providers for the same reason. Amazon competes on delivery speed, reliability, and customer experience. Depending on external logistics meant Amazon’s most important customer promise was governed by vendors whose cost structures and service levels were not aligned with Amazon’s strategic ambitions. Building the capability removed that dependency. The fulfilment network became a competitive advantage, then a cost reduction engine at scale, then a revenue generating service through Fulfilment by Amazon offered to third party sellers. A build decision on a strategic differentiator produced compounding returns that a buy decision would never have made possible.

Question to ask - Is this capability the thing we compete on or the thing we need to compete. If the former, build. If the latter, buy with rigour.

What Changes When the Conversations Join.

When architecture and finance come into the same room against the same decision, the quality of the decision changes.

The TCO calculation becomes holistic. Finance brings the full cost lens across the contract term. Architects bring the cost of change, dependency, and exit. Together they surface numbers that neither sees in isolation.

The commodity versus strategic distinction is made earlier and more rigorously. Architects challenge whether capabilities being bought should be owned. Finance challenges whether capabilities being built should be bought. The distinction is pressure tested against both technical and commercial criteria before commitment is made.

The quality of commitment improves. Not because decisions are slower. Because they are more informed. The organisation commits to what it actually understands rather than what it hopes the numbers will support.

This is not a process change. It is a capital discipline. Available to any organisation willing to put the right people in the same room before the contract is signed.

The Portfolio Consequence.

Individual architectural decisions carry individual capital consequences. The portfolio problem surfaces when the accumulated cost of past decisions consumes the capacity for future ones.
Licensing commitments are the most visible form of this saturation. They are contractually locked. They appear in the budget before any discretionary spend is allocated. An organisation carrying a heavy licensing burden from past vendor decisions has less capacity for new architectural investment than its headline technology budget suggests. The discretionary budget, the capital available for transformation and differentiation, is what remains after the licensing obligations have been met.

When licensing commitments are high and growing, the remainder shrinks. High spend. Low transformation output. The gap between what the organisation is investing in technology and what it is receiving in strategic return is the portfolio saturation problem made financially visible.
Technical debt compounds this. The engineering time required to manage and work around past architectural decisions is capacity that cannot be directed toward new capability. The interest payment on past decisions is being made in the currency of future delivery capacity.

An organisation whose technology budget is predominantly committed to licensing obligations and technical debt remediation is not investing in technology. It is servicing the consequence of past architectural decisions that were made without adequate capital discipline.

The capital consequence of an architectural decision does not resolve at contract end. It compounds across the decade that follows.

Architecture Is How Capital Thinks About the Future.

The organisations that make the best architectural decisions are not the ones with the best architects or the best commercial teams.

They are the ones where the architectural conversation and the capital conversation happen in the same room, with the same people, against the same decision, before the commitment is made.

Architecture is not a technical discipline that occasionally has financial implications. It is a capital allocation discipline that requires technical knowledge to practise well.
The technology leaders who understand that are not just better architects. They are better stewards of the institutions they serve.

Sutra

The vendor signed the contract. The architecture signed the decade.

Leave a comment

Sprint velocity is up. Check-in frequency is high. Story completion rates are on target.
And the customer outcomes are not following.

Features are being built. Releases are shipping. But the capability customers actually need, stable, coherent, outcome-connected, is arriving more slowly than the delivery pace suggests. Sometimes it is not arriving at all.

When you look closely at what is happening beneath the metrics, the answer is almost never that the engineers and architects are performing poorly. It is that the system they are operating within is performing exactly as designed.

The problem is the design.

What Goodhart Knew

Goodhart’s Law is simple and reliably applicable.

When a measure becomes a target, it ceases to be a good measure.
The moment an organisation elevates a proxy metric to the status of objective, behaviour reorganises around the proxy. Not because people are dishonest. Because they are rational. They optimise for what is being measured, because that is what the system rewards.

In engineering organisations, this dynamic is so common it has become invisible.
Number of check-ins as a measure of productivity. Deployment frequency as a measure of delivery health. Velocity points as a measure of output. Each captures something real. Each distorts the moment it becomes the target.
A team measured on check-in frequency will check in more frequently. The check-ins become smaller, more frequent, less considered. The metric improves. The codebase does not.

The organisation asked for activity and received activity.

From Metric to Architecture to Quality Degradation.

The check-in metric is the visible layer of a deeper problem.
Beneath it sits a delivery culture shaped by artificial deadlines rather than sustainable target states. Engineers and architects making daily decisions about what to build, where to place it, and how to connect it, under the constraint of a date that does not move.

Those daily decisions accumulate into consequences that are subtle, durable, and compounding.

Capability duplication appears first. When teams are moving fast toward a deadline, discovery feels more expensive than building. It is faster to implement what you need, where you need it, than to find out whether it already exists elsewhere. The result is the same capability appearing in multiple places, each carrying slightly different assumptions, each creating its own maintenance surface.

Wrong architectural placement follows. Capabilities get placed where they are convenient, not where they belong. The correct placement would have required a design conversation that nobody had time for. The capability lands where the team had access and appetite, not where the domain logic dictates.

Compounding dependencies emerge from both. Each duplicated capability creates a dependency surface. Each wrongly placed component creates an unintended coupling. The system becomes a structural record of every deadline that was hit rather than a reflection of the domain it was built to serve.

Now layer in quality degradation.

Quality in this context means two things working together. Architectural quality, building on the right foundations, maintaining clean boundaries, iterating toward a coherent target state. And engineering build quality, testing that genuinely verifies behaviour, code review that engages with design intent, design conversations deep enough to catch the coupling that will cost three times as much to untangle later.

When both degrade simultaneously under deadline pressure, the effect is multiplicative.

Poor architectural foundations mean changes touch more of the system than they should. Poor engineering build quality means those changes introduce defects the test suite does not catch. Each increment of poor architectural quality creates more surface for poor engineering build quality to damage. Each increment of poor engineering build quality makes the architectural problems harder to detect and more expensive to address.

The system becomes progressively resistant to change. Not because the technology is old. Because the quality of the foundations and the practices that built on them were both sacrificed incrementally under the pressure of metrics that measured neither.

At a certain point the cost of a change becomes disconnected from the size of the change. A small feature request requires modifying three systems never designed to be changed together. A one-line fix requires a regression cycle that takes days because the boundaries are not clean enough to test in isolation.

The engineers and architects are not slow. They are navigating accumulated consequence.

For a board member or investor, this is what technical debt actually looks like. Not a list of things to rewrite. A system whose architecture encodes the delivery pressure of decisions made years ago by people who are no longer in the organisation.

The Customer Outcome Gap.

The consequence that makes this pattern commercially legible is not the complexity itself. It is what the complexity does to delivery.

High check-in volumes. Green delivery dashboards. Artificial deadlines hit. Customer outcomes arriving more slowly than the delivery pace should allow.

The teams that optimised for speed created a system that is now slower to change than a system built with more discipline would have been.

The shortcut consumed the very resource it was trying to protect.
This is a capital observation. The investment made in hitting artificial deadlines produced a negative return on the organisation’s most important long term capability. The ability to respond to customers and markets quickly. The original justification for the deadline pressure has been undermined by the decisions made in its name.

This is how deadline-driven delivery cultures purchase slowness with the investment they made in speed.

What AI Changes About This Pattern.

AI does not introduce misaligned incentives. It amplifies them along three dimensions.
The first is velocity. More code is being written faster. If the incentive structure is misaligned, duplication compounds more quickly. Wrong architectural placements accumulate in days rather than weeks. Quality compromises accumulate faster than any review process designed for human-paced delivery can catch.

The second is invisibility. AI-generated code that integrates cleanly does not announce its architectural misfit. It looks correct locally. It passes review. It ships. Wrong placement, duplicated capability, unnecessary dependency, these are systemic properties requiring a view above the code level to detect. An experienced architect can often feel when something is wrong in human-written code before articulating why. AI-generated code does not carry those signals.

The third is auditability. When AI-assisted development operates inside a misaligned incentive structure at pace, the resulting architecture is not just fragile. It is often harder to trace. The decisions embedded in AI-generated code are not always recoverable as conscious human choices. Nobody chose to duplicate that capability. The AI generated it because the incentive structure rewarded the output it was part of.

For an investor or board asking why the system was built this way, that question may not have a recoverable answer. That is a governance concern, not a technical one.

Leadership Accountability.

If the system behaves badly, examine the incentives before examining the engineers and architects.

The check-in metric was not chosen by engineers. The artificial deadline pressure was not created by architects. The absence of outcome-level observability was not an engineering decision. Each was a leadership decision, made at the level where incentive structures are designed, whether consciously or by default.

Default incentive structures are still incentive structures. The organisation that has never explicitly designed its engineering and delivery incentives has implicitly designed them through the metrics it tracks, the deadlines it sets, and the outcomes it celebrates.

Here is the capital argument stated plainly.

The organisation invested in speed and purchased slowness. That is not a metaphor. It is a return on investment calculation. Every delivery cycle that sacrificed architectural quality and engineering build quality to hit a deadline was an investment that produced a compounding liability against future delivery capacity. The organisation is now paying interest on that liability with every feature it tries to build.

AI makes this leadership responsibility more urgent. Because AI is obedient. It will execute whatever the incentive structure rewards, faster and more completely than any human team. An organisation that hands AI a misaligned incentive structure has not accelerated its delivery.
It has accelerated its misalignment.

The question is not whether your engineering and architecture teams are performing well against their metrics.

It is whether those metrics are connected to the outcomes that actually matter.

Sutra

Decisions made under pressure become the architecture everyone else inherits.

Leave a comment

How do you know?

Not. did you test it. Not. has it worked so far. But genuinely. how do you know this system does what you believe it does, across every condition, at the scale you are running it.

Most engineering teams answer this question with confidence. We have test coverage. We have monitoring. We have not seen this fail.

Confidence is not a guarantee. And at scale, in regulated environments, in systems that carry financial obligations across millions of accounts, the distance between those two things is where institutional risk lives.

The Difference Between Testing and Proving

Testing and proof are not the same discipline. They feel similar from the inside. Both involve running your system and examining the results. But they answer fundamentally different questions.

Testing asks. did this work in the cases we tried.

Proof asks. can this fail in ways we have not tried.

A test suite, however comprehensive, is a sample. It covers the scenarios the team thought to write. It reflects the edge cases someone anticipated. It is bounded by the imagination and the time of the people who built it.

Proof operates differently. Formal verification and automated reasoning work by defining what a system must always do and what it must never do, and then systematically establishing whether those properties hold across all possible states, not just the ones you tested.

This is not an academic distinction. In environments where consequence is asymmetric, where a single class of failure can affect every customer simultaneously, the difference between a system that has been tested and a system whose critical properties have been proved is the difference between organisational confidence and institutional guarantee.

Those are not the same thing. And boards, regulators, and investors are increasingly aware of the gap.

What I Experienced

The first time I encountered this gap clearly, it was not through a formal methods textbook. It was through a production incident.

As Engineering Lead for Authorisation and Clearing, following a Visa compliance release, our system appeared healthy by every internal measure we had. Metrics were nominal. Alerts were silent. The team had confidence in what had been delivered.

Scheme partners were experiencing timeouts.

The gap between what our observability told us and what our partners were experiencing was not a monitoring failure in the simple sense. It was a proof failure. We had defined system health from our own observation point. We had not proved what the system looked like from the outside, under the specific load and latency conditions our partners were operating under.

We had tested our system. We had not proved our integration.

The distinction cost us time, credibility, and a significant incident review. More importantly, it revealed something structural. Our confidence had outrun our verification.

A second incident reinforced the same lesson from a different angle. An external API certificate expiry triggered disruption across a partner integration. The certificate itself was a known risk category. What had never been explicitly proved was the failure behaviour when it expired. No team had formally owned that scenario. No invariant had been defined for it.

The system had been tested under normal conditions. It had never been proved against that specific boundary condition. When the boundary arrived, the system had no defined behaviour to fall back on.

Both incidents shared the same root. Confidence without structural guarantee.

The Question That Keeps Me Up at Scale

But the example I return to most, the one that represents the deepest version of this problem, does not come from a failure.

It comes from a question I have never been fully satisfied with the answer to.

How do you prove that your system is calculating interest accurately across your entire book of accounts.

Not on a sample. Not in a test environment. Across every account, under every combination of product type, rate tier, promotional period, balance threshold, and regulatory requirement, simultaneously, continuously, at production scale.

Think about what that actually means at the account level.

A customer takes out a product with a promotional rate that steps down after ninety days. Their balance changes multiple times within that window. A payment is applied on the same day a rate change is processed. The sequence of operations matters. The order in which those calculations run matters. The rounding convention applied at each step matters.

Now multiply that by one combination of product configuration. Then multiply it across every product configuration in your portfolio. Then multiply it across every account in your book.

You can test representative cases. You can run reconciliation processes that compare aggregate totals against expected ranges. You can build monitoring that alerts when something looks wrong at the portfolio level.

But a reconciliation process tells you the totals appear correct. It does not tell you the calculation was right for every individual account that contributed to that total. A test suite tells you the interest engine behaved correctly for the scenarios you defined. It does not tell you there is no combination of product configuration and account state that produces an incorrect result you have not yet encountered.

Here is what makes this example genuinely unsettling.

A systematic error in interest calculation at account level can be invisible for months. The aggregate numbers reconcile. The monitoring is silent. The team has confidence. Meanwhile, across a subset of accounts sharing a specific combination of product configuration and balance behaviour, customers are being charged incorrectly. Or underpaid. Or both, depending on the scenario.

The error does not announce itself. It accumulates.

When a regulator finds it before you do, the conversation changes entirely. You are no longer presenting a post-incident review of something you caught and corrected. You are explaining why your quality assurance process was insufficient to detect a systematic error affecting customers at scale. That is a different kind of accountability. It carries a different kind of consequence for the institution and for the leadership team responsible.

The question “how do you prove it” is not theoretical. At the scale of a regulated financial institution, it is one of the most consequential engineering questions on the table. And it is asked far less often than it should be.

Proof as a Leadership Instrument

This is where the discipline of proof becomes a leadership instrument, not just an engineering one.

The organisations that navigate this well share one discipline in common. They define what the system must always do before they build it, not after it fails. They do not wait for the incident to reveal the gap between confidence and guarantee. They make that gap explicit, deliberately, as part of how they build.

In practice, this means defining invariants. Properties the system must always satisfy, regardless of load, configuration, or edge case. For a system calculating interest, an invariant might be. the sum of individual account calculations must equal the portfolio total within a defined tolerance. Or. no rate change may be applied to an account mid-period without a defined recalculation sequence. Or. no calculation may produce a result that violates the contractual terms of the product configuration active on that account.

For non-technical readers, the practical meaning is this. An invariant is a written commitment about what the system will always do. Not a test that checks whether it did. A structural guarantee that it cannot do otherwise without being detected.

These are not test cases. They are guarantees. They hold not because you ran them in a test environment, but because the system has been structured so they cannot be violated without detection.

Formal verification and automated reasoning are the tools that make this discipline systematic at scale. Amazon has invested significantly here. Their use of TLA+, a mathematical specification language, to verify distributed system behaviour before production is one of the better documented examples of this approach applied commercially. But the insight behind it is not Amazon’s alone.

In practice, the institutions I have seen navigate this well do not treat formal methods as a specialised engineering discipline. They treat proof as an organisational standard for systems where the cost of being wrong is asymmetric. Where one class of failure, silent, systematic, invisible at the aggregate level, can affect every customer simultaneously.

The value is not elegance. It is risk reduction at the level that matters. Not reducing the probability of a failure you have already imagined. Reducing the probability of a failure you have not.

What This Means for the Decisions Being Made Right Now

When an engineering team tells you a system has been thoroughly tested, the more useful question is this.

What are the properties this system is guaranteed to satisfy. Not in testing. In production. Under load. Under the edge cases nobody has yet anticipated. What are the invariants and how are they enforced.

A team that answers that question clearly has moved beyond confidence. A team that cannot answer it is not necessarily doing poor engineering. But they are carrying risk they may not have fully priced.

That question applies whether you are the engineer designing the system, the CTO making the investment case, the scaling organisation asking whether its architecture can carry the obligations it is accumulating, or the investor and board member asking whether the institution’s quality assurance is proportionate to the scale of its customer commitments.

The vocabulary changes. The question does not.

When did you last ask your engineering team not what they have tested, but what they can prove. If you cannot remember, that is already an answer.

At scale, in regulated environments, carrying financial obligations across millions of customers, confidence is not a sufficient standard.

Proof is not perfectionism. It is proportionate governance.

Speed without proof is not bold. It is deferred exposure.

Sutra

Confidence scales. So does the cost of misplacing it.

A Short Note Before We Begin

Season 1 of this series explored how invisible forces shape systems. How urgency hardens into structure. How decisions outlive the people who made them.

Season 2 asks what happens when the pace of those decisions accelerates beyond what most organisations are designed to absorb.

The question is not whether AI changes how we build systems. It does. The question is whether the people leading those systems are thinking clearly about what that change actually costs.

That is what this season is about.

Execution Is Cheap. Commitment Is Not.

The title of this post is not quite accurate. And that inaccuracy is deliberate.

AI-assisted development is not cheap. The infrastructure costs are real. The tooling, the licensing, the compute. In enterprise environments, these are material and growing. The governance overhead is real. The engineering time required to review, validate, and own AI-generated output is consistently underestimated. Any CFO who has seen the bill knows this.

What has changed is the speed of execution. More output, faster, with fewer people. The unit economics of a line of code have shifted dramatically.

But speed creates something more dangerous than cost. It creates a perception. That decisions made quickly are also lighter, more flexible, more reversible than they actually are.

That perception is where the risk lives.

The Distinction That Gets Lost

Execution speed and decision consequence are not the same thing.

We have accelerated one. We have not touched the other. In fact, we may have made it harder to see clearly, because when everything moves fast, the weight of individual decisions becomes harder to feel in the moment.

In low-consequence environments, that is manageable. In regulated industries, in financial infrastructure, in systems that carry customer obligations and downstream dependencies, it is one of the most expensive blind spots an organisation can develop.

A system that goes live is not just code. It is a commitment. To partners who integrate against it. To regulators who supervise it. To customers who depend on it. To the engineers who will inherit it.

Speed does not change that. It just arrives there faster, with less time spent asking whether you are ready for what commitment means.

What I Inherited

Early in my career, I joined a programme mid-flight and encountered an integration decision already made and already live.

A partner integration had been built synchronously. The business scenario it served had a long SLA window, one that would have accommodated an asynchronous design comfortably. Asynchronous would have been the correct architectural choice. It would have decoupled the systems, absorbed failure gracefully, and left room for the integration to evolve independently on both sides.

But the decision had been made under delivery pressure. The team needed to ship. The synchronous pattern was faster to implement. It worked in testing. It went live.

By the time I arrived, that integration was not just a design choice. It was structural reality. Downstream systems had been built around its behaviour. Partner contracts referenced its response characteristics. Changing it would have required coordinated releases across multiple teams, partner negotiation, and a migration window that no one had appetite to fund.

A temporary decision had become permanent architecture.

The original team had not been careless. They had been fast. And in that environment, fast had felt like the right thing to be.

What nobody had named clearly enough was the moment execution ended and commitment began.

AI Does Not Change This. It Accelerates It.

Here is where the current conversation about AI-assisted development requires more precision.

There are two distinct risks that often get conflated, and conflating them leads to the wrong response.

The first is that speed surfaces existing weaknesses faster. Bottlenecks that a slower delivery cycle would have absorbed become visible earlier. Architectural fragility that would have emerged gradually now appears under the first real load. Poor discovery, insufficient design thinking, unclear ownership. These were always present. AI removes the buffer that used to obscure them.

I saw a version of this before AI made it a widespread concern. An external API certificate expiry triggered disruption across a partner integration. The certificate was not the problem. Unclear ownership was. No single team had accepted responsibility for that failure domain. The expiry simply made the gap undeniable. A slower environment might have caught it during a routine review. The faster the system moves, the less tolerance it has for ownership ambiguity.

The second risk is specific to AI-assisted development itself, and it is less visible precisely because the output looks correct.

In 2023, a widely discussed incident at a major software organisation involved AI-generated code that passed automated testing and initial review. The code was syntactically clean. It performed correctly under standard conditions. What it carried, invisibly, were assumptions about execution order and shared state that only surfaced under concurrent load at scale. By the time the failure mode appeared in production, the code had propagated across several services. Untangling it required understanding decisions that no engineer had consciously made.

This is the specific shape of AI-assisted risk. Not bad code in the traditional sense. Code that is locally coherent and systemically fragile, written faster than the organisational immune system can respond.

Both risks matter. But they require different responses.

The first requires organisations to treat speed as a diagnostic instrument. If AI is exposing your bottlenecks and ownership gaps faster, that is useful signal. The answer is not to slow down AI. It is to fix what it is revealing.

The second requires governance to operate at execution speed. Review frameworks, architectural guardrails, ownership clarity. These cannot remain quarterly conversations if the delivery cycle is now measured in hours. Governance that cannot keep pace with execution does not disappear. It just stops working.

Reversibility Is a Governance Discipline

Not all decisions carry equal consequence. That has always been true.

What changes in an AI-accelerated environment is the rate at which decisions get made, and the risk that a decision with high consequence gets treated as low consequence, simply because it was made just as quickly.

The most important distinction a technology leader makes is between reversible and irreversible decisions. Which doors can you walk back through, and which ones close behind you.

In practice, holding that distinction requires deliberate friction. Not bureaucracy. Not slowdown for its own sake. But a moment, a question, a checkpoint. If this decision hardens into structure, are we comfortable with what it becomes.

That question costs almost nothing to ask. The absence of it compounds quietly, until someone inherits the answer.

Restraint Is Not Hesitation

There is a version of this argument that reads as anti-speed, anti-AI, anti-progress. That is not what is being said here.

Speed is genuinely valuable. AI-assisted development, governed well, extends what engineering teams can accomplish. The organisations that figure out how to harness it responsibly will move faster and more safely than those who either resist it or adopt it without thinking.

But the leaders who will define this era are not the ones who move fastest.

They are the ones who know which decisions to slow down, and why.

That is not caution. That is not hesitation.

That is judgement. And in an environment where execution is abundant, judgement is the scarcest resource in the room.

The Sutra

Execution ends. Commitment begins. Few notice the crossing.

Leave a comment

Not the intent behind them.

Not the context they were made in.

Just the decisions themselves.

That is legacy.

Systems as Memory

We often talk about systems as tools.

Platforms.

Pipelines.

Architectures.

However, systems are also memory.

They remember:

• which decisions were made quickly?

• which shortcuts were tolerated?

• which compromises became defaults?

They encode assumptions and replay them every day, long after the people who made them have left the room.

Architecture is not just structure.

It is memory with consequences.

When Temporary Becomes Permanent

One of the clearest lessons I have learned is how often temporary decisions outlive their context.

A synchronous integration pattern introduced for a partner interaction that should have been asynchronous.

Long SLAs treated as acceptable because delivery pressure was high.

Analytical capability areas repurposed to plug a gap in a product driven customer journey.

At the time, these decisions felt contained.

Pragmatic.

Reversible.

They were not.

I remember the moment it became clear that the system had moved on without us.

What we thought was temporary had become assumed.

The system remembered it.

Future designs worked around it.

Teams adapted to it.

What began as a tactical choice became structural reality.

Systems do not forget urgency.

They internalise it.

The Inheritance We Rarely Question

Some of the most powerful forces shaping systems are the ones we inherit.

Data models filled with flags.

Hundreds of them.

Each one added with intent.

Few ever removed.

Over time, those flags became a language of their own.

Logic scattered across the ecosystem.

Behaviour defined by combinations no one fully understood.

Alongside this, architectural boundaries were drawn not by how domains should be scoped, but by available skill sets.

Who could build it.

Who could support it.

Who was ready now.

These decisions made sense at the time.

But systems do not remember why boundaries were drawn.

They only remember that they exist.

New teams inherit these shapes as facts.

Not as choices.

That realisation was uncomfortable.

When Context Fades but Consequences Remain

What makes legacy difficult is not that decisions were wrong.

It is that context fades faster than consequences.

The pressure that justified a shortcut disappears.

The deadline that forced a compromise is forgotten.

What remains is the system.

Enforcing behaviour.

Constraining change.

Teaching new teams how things work here.

Often without explanation.

Systems train people more than leaders do.

How Legacy Changed How I Decide

These experiences have changed how I approach decisions today.

I spend more time deliberating on long term state.

Not as an abstract end point, but as a direction.

I ask how each step moves us closer or further away from that state.

I pause longer on why before jumping to how.

And I think deliberately about the teams I will never meet.

The people who will inherit decisions without the benefit of context.

Legacy is not about getting it right forever.

It is about leaving systems that are understandable, adaptable, and kind to their future owners.

Responsibility Beyond Tenure

Leadership does not end when delivery does.

Architectural responsibility extends beyond presence.

Decisions should assume:

• context will be lost

• documentation will age

• intent will fade

What remains must still make sense.

Reversibility matters.

Clarity matters.

Simplicity matters.

Not because systems must be perfect.

But because someone else will live with them.

🧭 Summary: What Legacy Teaches Us

• Systems remember decisions, not intent

• Temporary choices often become permanent

• Inherited structures shape behaviour silently

• Context fades faster than consequences

• Leadership responsibility extends beyond tenure

🧭 The Legacy Sutra

Systems remember what leaders forget.

Which temporary decisions in your system are now impossible to undo?

Which inherited structures quietly shape behaviour today?

And what will your systems teach the people who come after you?

Leave a comment