Governance as a Path
In one sentence: separate the right to decide from responsibility for the route, then build the route.
The problem
In a regulated organisation, a delivery team meeting governance for the first time faces something like six control functions, each with its own process, vocabulary, artefacts and timing. None of them is unreasonable. Collectively they are close to unnavigable, because no single document describes the route and nobody owns the route as a thing.
So each team rediscovers it. That rediscovery is the actual cost. It is paid repeatedly, it is invisible in every plan, and it gets attributed to governance being slow, which is both unfair and unhelpful, because it points the frustration at the controls rather than at the missing map.
The model
Separate two things that are constantly conflated.
Control authority is the right to decide whether something is acceptable. It belongs to the control function. Privacy decides privacy. Model risk decides model risk. This should not move, and attempts to move it are how organisations get into trouble.
Path ownership is responsibility for the route being knowable, sequenced and passable. This is a product problem. It is usually owned by nobody, which is why governance feels like a wall.
Once separated, the work becomes concrete: build the path, leave the authority alone.
The four components of a path
A control map. Which functions apply, under what conditions. Most work does not need all of them, and knowing that early is worth a great deal.
Gates in sequence. Defined points where work moves from one state to the next, with the specific approvals required at each. Not a checklist of everything, ever. An ordered sequence.
Artefacts, specified in advance. For each gate, exactly what has to exist. This is where most of the recoverable time lives, because teams routinely produce the wrong evidence and then produce it again.
A single owner of the path itself. Not of the decisions. Of whether the route is documented, current and actually working.
How to use it
Observe before designing. Take two or three pieces of work that have already been through the process and trace what actually happened, in order, including the loops. The real path is never the documented one.
Validate with each function separately. Not in a combined workshop, where corrections get smoothed over. The corrections are the most valuable output of the exercise.
Make it operational. A document nobody opens is not a path. Put it in whatever tool teams already work in, so following the path is the default behaviour rather than an act of diligence.
Keep it current. This is the part organisations skip, and the reason governance frameworks have a two-year half-life.
When to use it
When several teams are independently working out how to get approved, when elapsed time for comparable work varies by months, or when governance has become the thing people complain about rather than the thing people plan for.
Not worth doing below roughly ten pieces of work a year.
Limitations
This does not make controls faster. It removes rediscovery cost, which is often the larger number, but a review that takes three weeks still takes three weeks. If leadership expects governance transformation to halve elapsed time, this will disappoint them, and it is worth saying so early.
It requires genuine cooperation from control functions, who have their own priorities and no obligation to help you document their process. Without that cooperation you produce a plausible map that is wrong, which is worse than none.
It assumes enough volume to justify the effort and the maintenance.
And it is quietly political. Documenting a route makes visible which functions are slow and which requirements are unclear. That visibility is the point and is not always welcome.
An example
A platform supports several teams, each of which has independently worked out how to get a workload approved. Elapsed time varies by months for comparable work, and the variance is almost entirely explained by how much of the route each team happened to discover early.
The intervention is not a new committee or a policy rewrite. It is mapping the existing requirements into one lifecycle, expressing it as templates in the tool teams already use, and putting the platform in the position of confirming that the defined approvals are complete before a workload is promoted. The control functions keep every decision they had.
The measurable outcome is reduced variance before reduced duration. Teams stop being surprised. Surprise, not scrutiny, is what makes governance feel like a wall.
References
- Federal Reserve and OCC, "SR 11-7: Guidance on Model Risk Management". 2011. United States guidance, from the Federal Reserve and the OCC. It is cited here because it is the clearest public statement of the expectation that a model is validated, documented, owned and monitored, which is most of what control distance turns out to mean in a bank. New Zealand has no direct equivalent for model risk. What binds locally is the Privacy Act 2020 for personal information, alongside the Reserve Bank of New Zealand's prudential requirements, and for Australian-owned banking groups the APRA prudential standards
- NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)". January 2023. Organises the work into Govern, Map, Measure and Manage, which is a useful cross-check against whichever control functions your organisation happens to have