How to Design a Governance Framework People Do Not Route Around

Every experienced practitioner has seen governance fail in one of two directions. The first is hope: standards that exist as good intentions, applied when convenient, dependent on who is in the room. The second is theatre: required fields that accept anything, approval workflows that have never withheld approval, documentation nobody reads. Both produce the same outcome. Evidence nobody can trust and a framework everybody routes around. Designing governance that survives means designing against both failures at once.

Start from the definition

Governance is a set of standards plus the mechanism that makes them non-optional. Both halves are required. Standards without enforcement are guidelines. Enforcement without standards is bureaucracy.

The practical test of any element you design: can it refuse, and does the refusal leave a record? A required field cannot refuse a bad hypothesis, only an empty box. A review step that has approved everything it has ever seen has never refused. If nothing in your framework can say no, you are designing theatre.

Know what you are governing

Experimentation has seven points where quality is won or lost: whether the hypothesis is worth testing, whether the method is sound, whether the right metrics were chosen, whether the work is documented as it happens, whether the interpretation matches what the data supports, whether the implementation decision follows the evidence, and whether the outcome is tracked after rollout.

Most frameworks govern two or three of these and assume the rest. The most commonly skipped are the last two, which is why programmes accumulate claimed wins that never survive scrutiny. You do not need seven gates on day one. You do need to know which points you have chosen not to govern, and to have chosen deliberately.

Design for reciprocity

The single strongest predictor of whether a framework survives is whether it gives value back to the people it constrains. Governance built purely as an obligation gets routed around, quietly and permanently, no matter how senior its backing.

Every gate should return something. A hypothesis review that catches weak plans saves the practitioner weeks of wasted build. A decision record that captures why ideas were rejected saves the team from re-litigating the same idea every six months. A searchable evidence base pays back every person who contributed to it. If you cannot name what a gate gives back, redesign it before you ship it.

Fewer gates that bite

Two gates that can genuinely refuse are worth ten that cannot. Start with the two highest-leverage points: a hypothesis review before build, and success criteria defined before launch. Add further gates only when the strain of their absence is felt, because a framework that grows in response to real failures is trusted in a way a framework designed in the abstract never is.

Your first version will be wrong in places. That is fine, provided work is actually running through it. Governance improves by being used; it cannot improve as a document.

Secure the authority before you launch

A framework finalised at practitioner level, with no mandate above it, will hold exactly until it inconveniences someone senior. Before launch, two things need to exist: a named owner senior enough to defend it, and a written mandate from leadership that the standards apply. If you cannot get both, build the minimum viable version for your own team and treat the mandate as the thing you are working towards, because scaling governance without authority only scales the theatre.