# Golden paths and engineering governance > The most effective governance models don't rely on approval boards, process documents or compliance checklists. They make the right thing the easiest thing, and then mostly get out of the way. By Matthew D. Webb · 2026-02-21 · 9 min read Canonical: https://mdwebb.io/articles/golden-paths-and-engineering-governance/ AI involvement: Used to draft and revise this article, images and diagram included. --- Governance has an image problem, and it has earned most of it. Say the word out loud in an engineering organisation and watch the room deflate. People picture architecture review boards, mandatory templates, a sign-off chain with too many links in it, and documents that were written to be filed rather than read. Engineers assume governance is there to slow them down. Leaders assume that without it everything will quietly catch fire. Both are right often enough that neither side ever fully relaxes. The trouble is that neither instinct scales. Too little governance and every team solves the same problem in its own slightly different way, so you end up maintaining nine flavours of the same authentication flow. Too much and delivery turns into a sequence of permissions and meetings, where the actual writing of software is the short bit in the middle. The organisations that get out of this bind tend to do so by changing the question entirely. They stop trying to govern through process and start governing through the platform. ## The governance paradox Almost every control gets introduced for a reason that sounds completely sensible at the time. The organisation wants secure systems, consistent architecture, reliable deployments, something it can show an auditor, and the ability to sleep through the night. So it adds a review here, a sign-off there, a document to capture the expectation. Each one, taken alone, is hard to argue with. The problem is what they add up to. Every new control is friction, and friction is the one thing engineers are reliably good at routing around. Past a certain density, governance stops being something that helps the work and becomes something done to the people doing it. What you get at the end is compliance, in the narrow sense that the boxes are ticked. What you rarely get is the consistency you were actually after. This is the same gap I keep coming back to with [engineering metrics](/articles/why-most-engineering-metrics-fail/): measuring the proxy and mistaking it for the thing. ## Why standards documents fail Every engineering organisation of any age has a graveyard of standards documents somewhere. Technology standards, architecture standards, security standards, API standards, naming conventions, deployment requirements. The content is usually fine. Someone competent wrote it, and most of it is correct. The content was never the problem. Adoption is. Engineers are not sitting there defying the architecture guidelines out of spite; they are trying to ship something before the end of the sprint, and a document is a poor competitor for their attention when the pressure is on. The moment delivery gets tight, the written standard quietly demotes itself to a secondary source of truth. The real standards become whatever the templates, the pipelines and the existing code actually do, because that is what people copy. Which leaves an uncomfortable conclusion sitting in the open: > The standards that matter are the ones engineers follow without noticing they are following them. A standard that depends on someone choosing to read it has already lost. A standard baked into the thing they were going to use anyway has nothing to lose. ## The rise of the golden path Platform engineering gave this idea a name worth keeping: the golden path. A golden path is the supported, opinionated way of building and operating software inside an organisation. Crucially, not the only way - simply the easiest one. A decent golden path hands an engineer service templates, a CI/CD pipeline, observability already wired in, security controls switched on by default, deployment automation, sensible infrastructure patterns, and somewhere for the documentation to live. They can still go off and build something bespoke if the situation genuinely calls for it. Most of the time there is no reason to, because the common problems have already been solved by someone whose actual job was to solve them properly. This is where governance gets interesting, and it is more or less the point Spotify were making when they [coined the term](https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem): paving the path took spinning up a basic service from roughly two weeks to under five minutes. Once that path exists, the organisation no longer has to tell people which approach to take. The platform makes the preferred approach the path of least resistance, and least resistance is what engineers under deadline pressure follow every single time. ## Making the right thing the easy thing The best governance models all share one quiet characteristic - they remove decisions rather than add them. Compare the two ways to end up with a compliant service.
Two rows converging on a single node marked Ready for production. The top row, the manual path, is a chain of four boxes, each a human decision: read the standard, interpret it, configure controls, submit for review. The bottom row, the golden path, is one box, Create the service, followed by three controls (observability, security, CI/CD) applied automatically by the platform.
The first path relies on a person reading a standard, interpreting it correctly, configuring the controls by hand, and then submitting the result for someone else to check. Four places to get it wrong, four places to diverge, four places to wait. The second path relies on engineering: you create the service, and the controls arrive with it. Both reach the same outcome. One leans on human interpretation; the other leans on a system that has already made the right choice the default. Given any real scale, the second approach wins without much of a contest. The reason is not that engineers are lazy or hostile to governance. It is that they are sensibly allergic to unnecessary work, and reading a PDF to manually reproduce a configuration the platform could have handed them is, by any honest measure, unnecessary work. ## Governance through platforms This is a large part of why platform engineering has had the decade it has had. The strongest platform teams are not really in the infrastructure business; they are in the leverage business. A mature internal platform quietly becomes the delivery mechanism for governance itself, which is roughly the argument Evan Bottcher and Martin Fowler make about [what a platform is actually for](https://martinfowler.com/articles/talk-about-platforms.html). In practice that looks like logging standards embedded in the shared libraries, security scanning that runs in the pipeline whether you remember it or not, approved infrastructure patterns exposed as templates, identity and access handed over as a service, and observability that is simply on by default. None of it requires an engineer to attend a governance meeting or read a wiki page. The platform enforces it at the point the work is being done, rather than at the point someone asks permission to do it. Governance stops being a gate you queue at and becomes a property of the road you were already driving on. ## The danger of platform overreach None of this is a licence to route every problem through the platform, and plenty of organisations have learned that the expensive way. Lean too hard into standardisation and the golden path stops being an accelerator and turns into a tollbooth. The platform team becomes the gatekeeper everyone resents, exceptions become impossible to obtain, and the more capable engineers start building careful little workarounds, which is exactly the fragmentation you stood the platform up to prevent. A golden path is supposed to be the easiest route, not the only legal one. The aim is to make the sensible choice effortless and the unusual choice deliberate, so that going off-path costs a conversation rather than a quarter. That distinction matters more than it looks. The instant the platform team becomes an approval gate, you have rebuilt the review board you were trying to escape - just with better branding and a Slack channel. The org chart has a way of [reasserting itself](/articles/why-most-technical-debt-is-really-organisational-debt/) the moment a platform team turns into a bottleneck: the system ends up shaped like the friction that produced it, as it usually does. ## Engineering judgement still survives No platform replaces judgement, and the good ones do not try to. Every organisation eventually meets the case where the standard answer is the wrong answer. A heavily regulated workload needs controls the template never anticipated. A latency-critical service needs an architecture the golden path would talk you out of. An experiment needs room to be a bit feral for a while. Golden paths earn their keep by removing the decisions that did not need making, not the ones that did. The skill, for the people running the platform, is telling the two apart, and resisting the urge to pave over a genuine fork in the road just because paving is what they do. Take the standard move back when the position demands it. That, more than any template, is what good governance actually looks like. ## What good organisations stop asking The strongest engineering organisations eventually stop asking the question that sounds responsible and start asking the one that is useful. They give up on: > How do we make teams follow our standards? and move to: > Why would a team choose not to? That second question changes everything downstream of it. If the supported path is secure, observable, documented, operationally boring in the best sense, and genuinely easier than rolling your own, compliance stops needing to be argued for. It becomes the default outcome of doing the obvious thing. The organisation gets to stop relying on persuasion, which never scaled, and start relying on good engineering, which does. ## Governance as an engineering problem The most useful thing platform engineering has taught us is that governance, at scale, is not primarily a process problem. It is an engineering problem that we keep mistaking for a process one. Processes can surface issues, policies can write down expectations, and reviews can provide oversight, and all three have their place. But consistency across a large organisation comes from systems, not from goodwill or memory. It is the same lesson lurking behind DORA metrics: the durable outcomes are properties of the system, not heroics performed inside it. The organisations that balance autonomy and control well are almost never the ones with the largest governance function. They are the ones that invested in platforms, automation and good defaults, and then let those do the quiet, unglamorous work of keeping everyone roughly on the same path. Because the best governance model is not the one with the most controls. It is the one engineers barely notice, which usually means the right path has simply become the easiest one to walk down. ## Further reading - [How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem (Spotify Engineering)](https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem): the post that popularised the term, with the numbers on what paving the path did to their setup time. - [What I Talk About When I Talk About Platforms (Evan Bottcher, on Martin Fowler's site)](https://martinfowler.com/articles/talk-about-platforms.html): the clearest definition of what an internal platform is actually for, and the trap of treating it as a project rather than a product. - [Team Topologies (Skelton and Pais)](https://teamtopologies.com/book): the book that frames the platform team as an enabling capability rather than a gate, which is the whole game.