A Golden Path No One Walks is a Golden Myth
What Platform Engineers Must Learn from “Work as Imagined” vs. “Work as Done”
This article is a follow-on from this short story:
There are two systems in play in every organisation. The one that gets presented at the all-hands, smooth as a marble countertop, full of diagrams in colours chosen by someone who believes teal conveys maturity.
Then there’s the system people actually use—the improvised, work-scarred, duct-taped, caffeine-fuelled version that keeps the company alive on a Tuesday at 4:37 p.m., three minutes before the deployment window closes and someone from Risk starts clearing their throat ominously.
The first system is imagined. The second is done. And the distance between them is where all the interesting, human, infuriating things happen.
No one talks about this gap because it’s embarrassing. We draw beautiful architectures, gleaming deployment paths, frictionless flows—then we turn our backs and the developers do something unspeakably clever, horrifying, or both. A curl command stored in a Notion page. A Bash script older than the CTO’s children. An entire compliance process bypassed because “the checkbox didn’t load.”
This gap—this yawning chasm between the official and the real—isn’t a failure of discipline. It’s the default mode of human work. Bureaucracies dream; practitioners improvise.
And platform engineers, unlike most, stand with a foot on each side.
You are the custodians of imagination and the paramedics of reality. You inherit the neat models but get paged when they collapse under the weight of actual human intent. You design golden paths while knowing full well that humans are not golden-path creatures—they are stubborn, brilliant, panicked, bored, ingenious, and chronically allergic to anything that increases cognitive load even by a teaspoon.
The imagined workflow always assumes rational behaviour. The real workflow always assumes a deadline. The imagined platform assumes compliance. The real platform assumes coping. The imagined delivery pipeline assumes information flows neatly. The real one assumes someone will paste logs into Slack, ten seconds before giving up and asking, “Does anyone know why this test hates me?”
The real work is the only work. The imagined system is the menu—the glossy fantasy. The real work is the kitchen: heat, knives, smoke, and habit.
The imagined system isn’t merely wrong; it is often a comforting political fiction. It is the version of work that lets executives sleep. The real version is the one engineers pray won’t set fire to prod during the weekend.
If platform engineering has a singular purpose—and it does—it is to recognise these two universes. To encourage imagination to let go a little of the fiction and to see and recognise reality, and bend reality towards something more humane. To design for the system people actually use, not the one we wish they used. To treat friction, deviation, and workaround not as sin but as evidence of improvements to be had.
Because if you ignore the gap, it does not shrink. It widens, darkens, and eventually swallows the organisation whole. But if you study it—ruthlessly, curiously, without judgement—you begin to build platforms that fit the shape of human work rather than forcing human work to deform itself into a platform.
Platform engineering succeeds when it honours the work people do, not the work people say they do
The imagined workflow is linear, compliant, tidy. The real workflow is adaptive, emotional, fragmented, conditioned by cognitive load and social dynamics.
Failure occurs when the platform assumes the former and punishes the latter. When the catcalls of efficiency tune out the adaptive capacity needed to survive and flourish.
Success occurs when the platform learns from the real and slowly reshapes the imagined. The point is not to erase deviation but to understand why it exists—because deviation is information, not defiance.
Some practices to consider
Do Platform Ethnography — Shadow teams. Watch real deploys. Listen to the Slack/Teams channels. Reality lives in the workarounds.
Measure Cognitive Load, Not Just Lead Time — The fastest systems focus thinking, not just reduce steps. If your platform makes people feel stupid, they will route around it.
Turn Workarounds into Features — A workaround used by three people is a smell. Used by thirty, it’s a requirement.
Publish Observability for the Platform Itself — If people can’t see what the platform is doing, they will assume it’s untrustworthy and, worse, potentially judging them.
Treat Golden Paths as Living Contracts — Continuously revised, continuously validated. A golden path no one walks is a golden myth.
Co-author the Platform with Its Users — Invite dissent. Reward candour. Build with, not for. Inner open source FTW.
Some things to avoid
Blaming users for divergence — Divergence is rational behaviour in an irrational system.
Confusing documentation with truth — Docs describe imagined work; observation describes real work.
Over-optimising for compliance — A compliant workflow that destroys flow is still failure.
Believing incentives will fix behaviour — Behaviour follows friction, not policy.
Reality is not the enemy of design. It is the only teacher worth having.
A platform that serves imagined work becomes shelfware. A platform that serves real work becomes a habitat. Learn the difference, honour the difference, and build for the world that exists, not the one that flatters your imagination.