Governance Sized to the Organisation

Overview

Governance is the part of the practice that constrains other people, which makes it the part that can be imposed rather than adopted — and therefore the part most often introduced too early and at the wrong size.

The governing question is not what good governance looks like. It is: what problem does this mechanism solve, and does the organisation have that problem yet?

Each mechanism solves a specific problem

Stated plainly, because the enterprise versions of these are usually described in terms of their form rather than their purpose.

An Architecture Board solves the bottleneck problem: one architect cannot review everything, so authority is distributed to a group with shared criteria. The problem appears when review volume exceeds one person’s capacity — and the next topic shows that threshold arrives from an unexpected direction.

Standards solve the divergence problem: teams independently choosing differently, producing an estate nobody can operate. The problem appears when there are enough independent teams for the divergence to cost more than the constraint does.

A technology radar solves the communication problem: many teams needing to know the portfolio position without asking. It requires enough teams that asking does not scale, and enough mandate that the statement is credible.

A review gate solves the escape problem: significant decisions being made without architectural input. It is also the most easily routed around, and Module 8 established the cost of being routed around — once a gate is bypassed successfully, it is bypassed thereafter.

The sizing argument

graph LR
  A["<b>Small</b><br/>one architect,<br/>few teams"] --> B["<b>Growing</b><br/>divergence begins<br/>to cost"]
  B --> C["<b>Large</b><br/>review exceeds<br/>one person"]

  classDef sm fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef md fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef lg fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  class A sm
  class B md
  class C lg

Three regimes. Records and templates belong in the first; standards become worth their cost in the second; a board answers a problem that belongs to the third.

At a company with no existing practice, the mechanisms that fit are the ones that cost nothing to the people they touch: decision records, templates, one description of the system. They are adopted rather than imposed, which means they need no mandate — the thing Module 8 established the architect usually does not have.

The ones that do not fit are the ones requiring authority to enforce. Not because they are wrong, but because introducing a mechanism that is then ignored is worse than not introducing it. The second attempt is harder than the first, and the organisation has learned that process announcements can be safely disregarded.

Standards that help versus standards that ossify

The distinction worth carrying, because this is where governance most often turns harmful.

A helping standard reduces decisions nobody wants to make. One logging format, one deployment shape, one way to expose a health check. Teams adopt these gratefully, because the choice was never interesting and the consistency has obvious value.

An ossifying standard forecloses decisions that should stay open. A mandated framework, a prescribed service granularity, an approved-database list. These foreclose exactly the choices Module 3 said should be made against a specific context — and they rot, because the right answer in a standards document is the right answer of the year it was written.

The test: does this standard remove a boring choice, or an interesting one? Boring choices are where standards earn their place. Interesting ones are where they do damage, and where they get routed around first.

Every standard also needs an exception path with a named decider. Without one, the first genuine exception either breaks the standard’s credibility or forces a bad decision, and both are worse than a documented deviation.

Starting without a mandate

What is available to someone with no authority, which Module 8 established is the normal condition:

Do it yourself first. Write the records, write the one description. Nobody’s permission is required to document your own decisions, and a set that visibly exists is a far better argument than a proposal that one should.

Make it useful before making it required. When engineers start linking to the decision set in reviews because it answers their questions, it has been adopted. Requiring it before then produces compliance, which looks similar and decays as soon as attention moves.

Borrow authority rather than claiming it. Module 8’s sponsorship point: a practice backed by the sponsor whose initiative depends on it travels further than one backed by its author.

Six months of governance, and what is deliberately deferred

Sized for about 140 engineers, roughly eighteen teams, no existing practice, no mandate, and a culture that Module 8 read as pragmatic with a quiet aversion to publicly recording failure.

Months one and two — nothing that touches anyone else. The eight recovered decision records and the HLD, written by you and published where people can read them. No announcement, no requirement. The only goal is that the artifacts exist and are visibly useful.

Months three and four — two templates, offered. The five-field decision template and the proposal template, in the repository, with the existing set as worked examples. Offered rather than mandated: anyone making a decision they think is significant is invited to file one. Expect two or three takers, which is success.

Months five and six — one expectation, one standard. The expectation: a pull request that moves a boundary updates the description. Enforced in review by people, not by a check. The standard: one logging and tracing format for the new services, which is a boring choice nobody wants to make and which the operational work in Module 6 needs anyway.

Deferred, each with its reason. No Architecture Board — it solves a bottleneck that does not exist at one architect and eighteen teams, and it would add ceremony to an organisation whose actual problem is that nothing is written down. No technology radar — no mandate to make the statement credible. No approved-technology list — it forecloses interesting choices, which is the failure mode above. No mandatory review gate — the fastest route to being bypassed, and once bypassed it stays bypassed. No standards catalogue — nothing to enforce it with yet.

The culturally specific adjustment. The 2023 routing feature was switched off without a postmortem, and Module 8 established that the absence is the cultural finding rather than an oversight. So the practice introduces no blame-adjacent mechanism in its first six months — no postmortem requirement, no decision audit, no retrospective review of past choices. The decision records are framed as forward-looking and the one reconstruction of that event waits until the set has earned trust. Governance that fights the culture in month one spends credibility that Module 8 showed takes far longer to accumulate than to lose.

Feeds the workbook

This is the process proposal artifact directly, and two rubric items land on it: the proposal must be sized for an organisation of this scale with no existing practice rather than for an enterprise, and something must be explicitly deferred with a reason.

Check your understanding

1. Pick a governance mechanism you have worked under. What problem did it solve, and did the organisation have that problem?
2. Name a standard from your experience. Did it remove a boring choice or an interesting one?
3. What would you introduce in your first two months with no mandate at all?

---

→ One mechanism’s threshold is about to move, and not because of headcount. — The review shift, and real-world texture