“Design Authority” is a phrase that makes good engineers reach for the exit. It sounds like a committee. It sounds like a form. It sounds like the meeting where your work goes to wait three weeks for a rubber stamp from someone who hasn’t written code since the framework you’re using was in beta.
I’ve introduced one, into an organisation that had grown several delivery teams without any shared architectural direction, and I’ll admit I shared the flinch. But the alternative to some authority isn’t freedom — it’s drift. Every team solving the same problem a slightly different way; five flavours of authentication; three message formats for the same event; nobody able to move between teams without a fortnight of relearning. The question was never whether to have architectural governance. It was how to have it without becoming the very bureaucracy everyone was right to fear.
What it actually is
Strip away the grand name and a Design Authority is a small, standing forum whose job is consistency across teams that would otherwise diverge. Not a gate every change passes through — that way lies the change-advisory-board of legend, where the queue is the product. A lightweight version advises by default and blocks rarely: it sets a handful of principles, makes the cross-cutting decisions that no single team can own, and records the reasoning so the next person inherits it rather than rediscovering it.
That last part matters more than it sounds. Most of what a Design Authority produces should be decision records, not policies. A policy says “thou shalt”; a decision record says “here’s what we chose, here’s what we traded away, here’s when to revisit.” One breeds compliance theatre; the other breeds understanding. If your governance output is a wiki of rules nobody reads, you’ve built the bureaucracy. If it’s a trail of decisions people actually refer back to, you’ve built the thing.
Why mine didn’t work at first
Here’s the uncomfortable part, and it’s the reason I’m writing this rather than pointing you at a textbook. For the first stretch, it barely worked. Attendance was patchy. The meetings were low-quality — vague discussions that resolved nothing. Teams nodded along and then did whatever they’d already planned to do.
Two things were going on. The first was a theory-versus-practice gap. I’d come to the idea through study that was long on why governance matters and conspicuously short on how you make it land in a room full of people with a sprint to finish. I could argue the principle beautifully and had almost nothing to say about the mechanics. The second was simpler and more human: to a delivery team under pressure, “architectural governance” reads as “the thing that slows us down.” That instinct isn’t stupid. It’s usually correct, because most governance they’ve met was friction with a lanyard.
The honest thing that made it stick
What changed it wasn’t a better framework or a slicker meeting format. It was that leadership actually started stopping non-compliant work.
I want to be precise about this because it’s the whole post. A Design Authority with no executive backing is theatre — a group of people with opinions and no consequences, which teams correctly learn to ignore. It only became real when a senior sponsor was willing, occasionally and visibly, to say “no, not like that” and make it stick. The first time a piece of work was actually held back until it aligned, the tenor of every subsequent meeting changed. Suddenly it was worth showing up.
This is the same argument I made when I stopped being an enterprise-architecture sceptic: governance without teeth is decoration. But “teeth” is where people hear “bureaucracy,” so let me draw the line carefully, because they are not the same thing and the whole craft is in the gap between them.
Teeth are not bureaucracy
Bureaucracy is process as an end in itself — the form must be filled because the form must be filled. Teeth are the willingness to enforce a small number of decisions that genuinely matter. You can have the second without the first, and you must, or the cure is worse than the disease.
The way you keep teeth from calcifying into bureaucracy is to be ruthless about scope. Enforce the cross-cutting few — the things that are expensive to get wrong and hard to reverse, the interfaces between teams, the choices that create lock-in. Leave everything inside a team’s own boundary to that team. This is consistency versus autonomy, and like most things it’s a balance you optimise rather than maximise: govern everything and you’re the bottleneck everyone routes around; govern nothing and you’re back to five authentication schemes. The authority earns its licence to say “no” on the few things by saying “your call” on the many.
It’s a people problem, of course
None of this is really about architecture. A Design Authority is a mechanism for manufacturing shared context across teams that don’t naturally have it — and, like most things worth doing in this job, the barriers to making it work are human, not technical. It needs a credible sponsor, it needs to spend its authority sparingly, and it needs to produce understanding rather than paperwork.
I won’t pretend I’ve perfected it. Uptake still needs tending; the temptation to expand scope is constant; the line between “necessary teeth” and “creeping process” has to be redrawn every few months. But the shape of the thing is clear enough now to state plainly: a Design Authority works when it has real backing and light touch, and fails when it has either one without the other. All backing and no restraint is bureaucracy. All restraint and no backing is theatre. The narrow, uncomfortable, entirely worthwhile path runs between them.