Somebody in your company sent an email last quarter with the subject line "Standard Engineering Process v3". Twelve pages. One pipeline. One branching model. One ticket workflow. One definition of done. Every team, same rules, no exceptions.
I understand the impulse. I have had the impulse. When you run more than three teams, the sprawl gets ugly fast. Four logging stacks. Six ways to deploy. Two teams who write tests and one who writes prayers. Standardizing all of it feels like leadership.
It is not leadership. Most of the time it is fear wearing a policy document.
The mandate solves your problem, not theirs
Here is the uncomfortable bit. A blanket standard almost always solves a problem the person writing it has, and creates work for the people reading it.
Your problem is visibility. You have twelve teams and no way to compare them, so you flatten the differences until comparison gets easy. Your problem is on-call. Nobody wants to be paged at 3am for a service written in a language they have never touched. Your problem is audit. One process is one document to hand the auditor.
Those are all legitimate problems. None of them are the problem of the team building the real-time pricing engine, whose batch-oriented deployment standard adds forty minutes to every release.
Amrut Patil put the tradeoff well in The Cloud Playbook: standardization shifts cognitive load off individual teams and onto the platform team, and when the guardrails sit in the wrong place, they constrain the right behaviors alongside the wrong ones. His line stuck with me. When teams route around your standards, the standards are wrong. Not the teams.
The data is less flattering than the slide deck
The 2024 DORA report looked at internal developer platforms, which is the polite modern name for "one way to do things, with better tooling". The finding has two halves, and most leaders quote only the first one.
Half one: an internal developer platform improves individual productivity, team performance, and organizational performance. Great. Print it.
Half two: it also leads to decreased change stability and decreased throughput, and DORA calls out the need for careful implementation focused on developer independence.
Read half two again. The thing sold to you as the way to ship faster and safer shipped slower and wobblier in the research. Not because platforms are bad, but because a platform built to control people behaves differently to a platform built to serve them. Same tooling, opposite outcome, and the difference is intent.
The same report found something else worth pinning to your wall. Unstable organizational priorities cause meaningful drops in productivity and large increases in burnout, and the effect resists mitigation. Strong leaders and good documentation do not save you. So if your standard process gets rewritten every two quarters because a new director arrived, you are not standardizing anything. You are churning people.
Desire paths tell you the truth
Walk across any university campus. There is a concrete path, and next to it there is a worn dirt line across the grass where everyone walks. Architects call it a desire path. It shows you where the path should have gone.
Engineering orgs are full of desire paths, and leaders keep treating them as vandalism.
The team with a shadow deploy script. The one with a Slack channel where they approve changes before the official approval tool sees them. The staging environment somebody keeps alive on a personal cloud account. Every one of those is a message: the paved route does not go where the work goes.
You have two options when you spot one. Punish the workaround, or read it. Punishing feels decisive and buys you nothing except a better-hidden workaround next quarter. Reading it costs you an hour and tells you exactly which part of your standard fails under real conditions.
I would rather have twelve visible desire paths than one process with perfect compliance stats and a shadow economy underneath it.
Copying someone else's shape
The classic version of this mistake is the Spotify model. Squads, tribes, chapters, guilds. Beautiful diagram. Enormous influence.
Spotify published a snapshot of their way of working in 2012, and as one long-running critique put it, companies asking "do you do the Spotify model?" are missing the forest for the trees. It was a photograph of one company at one moment, with their people, their product, their history. It was never a template.
Yet I have sat in rooms where a leadership team adopted the vocabulary in eight weeks and the culture in never. The squads had no autonomy. The chapters had no time. The guilds had a calendar invite and no agenda. Renaming your teams is cheap, which is precisely why it happens first.
If your reorg is mostly a glossary, you have bought the shape of somebody else's answer without asking their question.
What good looks like instead
I am not arguing for chaos. Twelve teams with eight languages, six deploy mechanisms and no shared on-call playbook is a different flavor of the same failure. The fix is not less standardization. It is standardizing the right layer.
Standardize outcomes, not tools. Every service is observable, recoverable, and owned by a named team with a working pager. How each team reaches those is theirs. Outcomes travel across contexts. Tools do not.
Make the paved road optional and obviously better. If your golden path is genuinely faster, teams pick it without a mandate. Mandates are what you reach for when the product is weak. Adoption under threat tells you nothing about quality.
Put a clock on exceptions, not a moat. An exception process needing four approvals and six weeks is a ban with extra paperwork. Give teams a documented way to differ, with a review date. Some exceptions become the new standard. Those are the valuable ones.
Measure adoption, not compliance. Compliance asks "did they obey". Adoption asks "did they choose". One of those numbers predicts your next outage.
Ask before you write the policy. The people closest to the work already know which part of the standard hurts. They have written the workaround. Nobody asked them, because asking risks an answer you dislike.
This is a leadership problem wearing an engineering costume
Here is the part I keep coming back to. Blanket mandates are rarely about engineering quality. They are about a leader who has lost confidence in their ability to judge individual situations, so they remove the need to judge at all.
One rule for everyone means no hard conversations. No case-by-case thinking. No risk of looking inconsistent. It is management by policy, and it is comfortable in the way a locked door is comfortable.
The people underneath feel it immediately. Our research at Step It Up HR found 99.5% of survey respondents had experienced one or more types of bad boss. The bad boss in this story is not shouting at anyone. They are sending a twelve-page process document to teams whose work they stopped understanding two years ago, then reading the compliance dashboard as proof things are fine.
Your best engineers do not quit over a deployment pipeline. They quit over the accumulated experience of being treated as interchangeable.
The question worth asking on Monday
Go and find one standard your teams work around. Not the worst one, the most routed-around one. Then ask the team a single question: what would need to be true for you to use the official route?
Their answer is your roadmap. If you do not like it, the problem was never the team.
So which is it at your company... do people follow the process because it works, or because somebody is watching?