Stop Standardizing the Wrong Things
A diagnostic for knowing when standards help and when they hurt.
Standards are seductive. Roll out one template. One cadence. One workflow. Every team.
It feels decisive. It looks like progress. It demos well for the all-hands.
But standards in the wrong place produce process theater: everyone follows the process, but the process doesn’t produce anything useful.
Most processes have layers. Think of an egg:
There’s the egg white. It’s the part that moves information between people and teams. Routing, handoffs, status reporting, dependency tracking.
And there’s the yolk. That’s the part where people actually figure things out. Prioritization, tradeoff discussions, leadership reviews.
Well-designed processes are a soufflé. You need both parts of the egg, but carefully separated and handled differently.
Standards help coordination. They reduce the cost of moving information by making handoffs predictable and routing legible.
Judgment works when people adapt to what’s in front of them. Standardize it and you replace their context with your template. And your template doesn’t know their situation. You can tell people to use their judgment, but the template is louder.
If you don’t tease apart the layers, you’ll end up with broken yolks and overhead.
A new CTPO needed visibility into initiatives across the technology organization. People asked for a template. I built one: what you shipped, where the CTPO could help, red/yellow/green on your OKRs.
First cycle was great. The CTPO was engaged, pressure-testing, asking hard questions. But after he’d been through each initiative once, the meetings started to drift. Nobody brought anything that didn’t fit the format. The template had gone from guidelines to tight guardrails.
Within a quarter, delivery updates had replaced the leadership review entirely. A perfect example of process theater.
One day a product director Slacked me before her presentation. She’d already shared her updates at a cross-functional SteerCo earlier that week and didn’t know what to present. So I asked: “What’s actually keeping you up at night? You have 30 minutes with the CTPO and his leadership team. What would be the most valuable use of that time?”
She walked in with an extra slide and looked to me for reassurance that it was okay to go off-script (and the fact that she felt she needed my permission says a lot).
What she told the room stopped the meeting cold.
They hadn’t closed a new customer in six months. The team was going to miss their annual revenue target. The roadmap was focused on hardening and scaling, but they hadn’t found product-market fit. Everyone was scared to pivot because it felt like admitting defeat.
For the first time in that meeting, people were thinking together rather than presenting at each other. The CTPO was back to pressure-testing. The VPs jumped in with questions and suggestions. Nobody was looking at their laptop.
The CTPO asked why nobody had raised this sooner. She shrugged. Projects were technically on track. Engineering was shipping on time. But nobody was buying the product.
By the end of the session, her team had thrown out their quarterly plan. Not a tweak. A full pivot to customer acquisition.
And I threw out the meeting template. One question replaced the entire structure.
The room already had the information it needed. But presenters needed permission to surface hard conversations. My template defined what counted as a legitimate topic, and the real problem didn’t fit the format.
That’s the dangerous part about standardizing judgment. It doesn’t blow up on day one. It calcifies. The process works at first, then quietly starts defining what counts as legitimate. The things that don’t fit the format disappear from view. And because everyone’s still following the process, nobody flags it.
The question I should have asked before building that template: is this process moving information, or producing decisions? Mine was producing decisions. I standardized it anyway.
Once you isolate the coordination layer, ask yourself if you’re standardizing costly or cosmetic divergence?
Costly divergence means the inconsistency is causing real operational failures. Requests get lost. Routing breaks. Leadership can’t see across teams. Work falls through cracks.
Cosmetic divergence means the coordination works but looks different across teams. Different sprint start dates. Different dashboard layouts. Different field names for the same status. As long as nobody’s losing requests or missing handoffs, let teams be the special snowflakes they think they are.
I applied this lens when redesigning a product intake system. Requests were going to the wrong team, sitting in limbo. Leadership had no visibility into volume or turnaround. The costly divergence was apparent: requests disappeared into black holes and nobody tracked anything.
My team member leading the implementation knew we had to accommodate team nuance. His plan was to build our “intake domestic policy”: his design would account for different states, but still maintain shared laws and infrastructure.
But as he gathered requirements from each product team, the picture shifted. These weren’t states. They were countries. Different customer types, different definitions of urgency, different triage logic. The shorthand stuck. Every time either of us got pulled toward over-standardizing, the correction was instant: “design for countries, not states.”
So we were surgical about standards: a single entry point, shared routing, SLA tracking that rolled up for leadership. Shared borders and a common currency. And left the judgment local. Each team kept their own intake form, their own triage logic, their own definitions.
We even isolated the cosmetic layer: field ordering, dashboard layout, whether work happened in the original ticket or a linked one. We didn’t have a reason to care, so we let those vary.
Leadership got a rolled-up view without requiring every team to ask the same questions. From above, it looked like one system. From inside each team, it felt like theirs.
Both stories started with a broken process and the instinct to standardize it. In one case the right answer was to strip the standard out entirely. In the other it was to standardize selectively. The difference came down to two questions:
Is this process moving information or producing decisions?
If coordination, is the divergence costly or cosmetic?
There’s a reason soufflés earn their reputation as a challenging dish: it’s hard to separate your egg whites from the yolks. But do it carefully, and you’ll design better processes.
This is a fantastic guide on how to approach standardization. I recently heard Clare H. speak on the subject at the Product Ops Summit in NYC, and her insights really resonated with me. Highly recommend giving this a read. Thanks, Clare!