Governance as a Path

Control functions are not the obstacle. Making every team rediscover the route through them is.

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.

Why this matters in a hiring conversation

It demonstrates influence without authority across functions that do not report to you, which is the specific capability most enterprise product roles are actually screening for and most candidates describe only in the abstract.