Engineers don't resist governance. They resist governance that gives nothing back.

Most central architecture teams are one reorg away from deletion. Most have earned it.

I write from years inside the central architecture function of a global enterprise: the guiding principles, the technical standards, the technology radar, the decision process that ties them together. On a good day, delivery engineers rate that machinery mostly harmless. On a bad day, a queue.

The deletion gets earned through control. Standards written centrally and announced downward, to teams who were never asked what already worked. A review board that meets fortnightly while the deploy train leaves daily. A wiki of mandatory patterns, stale for a year, contradicted by the codebase in a hundred places. Each of these prices governance in engineers’ time and pays nothing back. Everything the machinery produces arrives as latency: decisions travel away from the people who hold the context, wait in line, and come back with conditions attached.

Engineers run this arithmetic long before the org chart does. What reads as resistance from the center is, from the team’s side, a rational refusal to pay a tax.

The one justification that survives

One justification for a central architecture function survives contact with delivery: it makes good decisions cheaper. The right thing has to be the easy thing: the default path, the pre-approved pattern, the pipeline that passes because the guardrail already lives inside it. When the compliant route costs three extra meetings, engineers pick the workaround, and they are correct to do so. Cognitive load is the scarcest resource in a large engineering organization. A central team either reduces it or has no business existing.

Here is what that buys you if you write code for a living:

• An answer in days, from a named owner, where today you wait weeks on a committee.
• Fewer meetings standing between you and production.
• A default stack that is demonstrably the fastest route to a deploy, so choosing it is self-interest rather than obedience.
• A documented way to deviate when the standard genuinely doesn’t fit, at a lower cost than hiding.

That is also the test this essay commits to: every governance mechanism gets priced in engineer time. If a mechanism costs the engineers it governs more than it returns to them, the mechanism is wrong. Most governance fails that test.

Why this is suddenly existential

For once, the timing argument is empirical.

Google’s DORA program spent 2025 studying AI-assisted software delivery and concluded that “AI’s primary role is as an amplifier, magnifying an organization’s existing strengths and weaknesses.” The same research locates the returns in the system underneath the tools: version-control discipline, review practice, platform quality. The gains land where those foundations already hold. Weak system, amplified weakness.

Gartner put a number on the downside in June 2025: over 40% of agentic AI projects will be canceled by the end of 2027, on escalating costs, unclear business value and inadequate risk controls. Forrester’s 2026 predictions add the budget pressure behind that figure: fewer than a third of decision-makers can tie the value of AI to their organization’s financial growth, and CFOs have started asking. Thoughtworks, meanwhile, named a theme of its Technology Radar Vol. 34 “Retaining principles, relinquishing patterns”: generated code makes patterns cheap, so the principles above them now carry the structural weight.

Read together, these findings say something uncomfortable to both camps. To the governance skeptics: the organizations getting returns from AI are the ones with the strongest engineering foundations, and foundations are what an architecture function is supposed to produce. To the governance industry: a function that produces latency instead of foundations is now a measurable liability, and the measurement is coming whether it participates or not.

The paved road has become the AI strategy. A central function that cannot make the right thing the easy thing has turned into a P&L problem with a nice org-chart position.

Three registers, and receipts

What I write here comes in three registers, and I’ll be honest about which one you’re holding:

• War stories from inside a federated global enterprise: work I’ve been close to, with specifics sanded down to what isn’t mine to share, and numbers withheld because they belong to my employer.
• Positions I’ll defend in the comments.
• Investigations into ground that moves fast (agent governance, AI regulation, evaluation gates), where I read the primary research and work out where I land, in public.

Where I can’t show receipts from employer work, I show them from a lab I own outright: my personal site. It runs the same ideas at toy scale. A hexagonal core with architecture rules enforced as failing tests. Significant decisions published as records anyone can read. A CI gate that blocks confidential figures from ever reaching a public page. Toy scale, real mechanisms. When a claim can be verified in the repo, I link the code.

Prescriptions versus instruments

On frameworks, one distinction does the work in everything that follows: prescriptions versus instruments. Prescriptive operating models, the four-letter certifiable kind, arrive with answers to questions your organization never asked. Instruments observe and measure: a way to price what enablement is worth, a map of who actually holds each decision, a ledger of where your standards don’t fit. An instrument pointed at your organization produces your answer, and the conclusions stay yours.

These essays build instruments.

Where this is going

Four themes, sketched so you know what to expect:

• The operating model: why principles nobody helped write go unadopted, who should own an architecture decision, why the escape hatch is the governance.
• The estate and the proof: triaging accumulated systems by harm, measuring a function whose product is other teams’ speed, instrumenting whether AI actually made you faster.
• The agentic shift: standards for code no human wrote, architecture docs as runtime context for machines that act on them, controls that still work at machine speed.
• The wider mandate: data contracts as governance, AI cost as a constraint, build versus buy when software builds itself, and what happens to the architect’s job.

Where to start

Pick the standard your teams complain about most. Time the compliant path against the workaround, in hours of engineer effort. If the workaround wins, make the compliant path faster: pre-approve the pattern, move the check into the pipeline, delete the meeting. Then tell your engineers what changed and watch what they choose.

Worth taking away:

• Governance is a product, and engineers are its customers. Price every mechanism in their time; retire the ones that run at a loss.
• The paved road is your AI strategy, whether you’ve written that down or not. Foundations decide what the tools return.
• Cheap beats mandatory. Adoption you had to force is a measure of your enforcement budget, and it tells you nothing about your defaults.
• Start with one standard, this month. The credibility from making one compliant path demonstrably faster buys you the room for everything else.

If you work in one of these functions, or you live downstream of one, this is for you. Disagreement is welcome and useful; the comment thread is part of the method.