Governance as decision enablement
Every organization I have seen pays for governance twice. Once for the process itself: the boards, the templates, the waiting. And once, invisibly, for all the questions the process never actually answers: the same architecture debate held in four teams in parallel, the standard nobody can find, the ownership question that resurfaces every quarter like an unpaid invoice.
The second bill is the expensive one, and it points at what governance is really for. The product of a governance function is not oversight. It is decisions: reliable answers people can build on without asking again.
The tax of undecided questions
An undecided question does not wait politely. It gets answered anyway, locally, differently, and repeatedly. Which database for a new service. Who owns the interface between two systems. What the standard is for logging, for naming, for access. Each local answer is cheap; the divergence they add up to is not. It shows up later as integration effort, audit findings, migration projects, and the quiet complexity that makes every change a little harder than the last one.
So the first honest measure of a governance function is coverage: how many of the questions that teams actually meet have a usable answer. The second is latency: how long it takes from a question being raised to an answer being usable. If those two numbers are bad, no amount of process discipline compensates.
Gates and guardrails
Most governance is built out of gates: control points where work stops until someone approves. Gates have their place, but they scale with request volume, consume senior attention case by case, and train teams to package requests for approval rather than to think about the underlying question.
A guardrail is the same decision made in advance for a whole class of cases: a standard, a pattern, a documented default. Work inside the guardrail proceeds without asking. Work that needs to leave it goes to the guardrail's owner, deliberately and visibly. A gate scales with volume; a guardrail scales with reuse.
Gates still earn their cost in a narrow band: decisions that are effectively irreversible, changes with a large blast radius, mandated approvals, and genuinely new territory where no pattern exists yet. The craft is in the conversion. When the same request shows up for the third time, cluster the cases, decide the pattern once with its owner, publish it with an explicit exception path, and retire the gate for everything in-pattern.
Decide once, write it down
An undocumented decision is a scheduled repeat discussion. The half-life of a verbal decision is roughly one reorganization. The fix costs half a page: what was decided, by whom, in what context, with what consequences, and when it should be reviewed. Kept in one findable place, with an owner. The trigger rule is simple: if a question took a meeting to settle, it gets a record.
One owner per question
Every recurring question needs exactly one accountable owner. Shared ownership is the polite form of no ownership. Gray areas are where complexity breeds: they generate escalations, workarounds, and shadow decisions that nobody can later explain. Assigning owners is unglamorous work, and it removes more friction per hour invested than almost anything else a technology leader can do.
From architecture to operations
I spent four years operating architecture governance across a large corporate group: standards, reference architectures, conformity reviews, target pictures. The lesson that survived contact with reality is exactly the one above. The governance that worked did not add steps; it removed questions. The reviews people valued were the ones that ended with a usable decision.
The same mechanics carry directly into infrastructure and operations, where I work today. Handover criteria for new technology are guardrails: decided once, applied to every service that wants to enter regular operations. Service standards, access models, and naming conventions are guardrails. The exception path is deliberate and owned. And the measure of success is unchanged: fewer open questions, answered faster, decided once.
What changes when it works
Fewer meetings, because fewer questions need one. Faster delivery, because the paved road is genuinely faster than the detour. And a different relationship with governance itself: teams start bringing questions early, because the function has a track record of answering them. That is the tell. Governance that people seek out is working; governance that people route around has already failed, whatever its compliance statistics say.
If a process adds steps without removing questions, it is not governance. It is friction.