Why Standards Are So Seductive
Standards reduce decision cost... until they're applied to the wrong problem.
Standards earn their reputation honestly. They can streamline coordination. They can create shared language across functions. They can reduce risk and improve compliance. In short, they can reduce the cost of repeated decisions.
Plus, nobody wants to reinvent how a sprint retro works every two weeks.
I joined a technology organization where the roadmap was roughly 150 projects tracked in a sprawling spreadsheet. Every 4-5 months there would be a new piece of information or a critical customer request that required roadmap reprioritization. The CPO couldn’t digest the laundry list of a roadmap, so he’d have to send a blast email out to the product managers asking them to all share a list of current priorities. This request triggered a fire drill that consumed days – first gathering the projects, then figuring out staffing levels, then normalizing the list. Only at that point could he review the list with his direct reports and make the necessary tradeoff calls.
I built a taxonomy that standardized those projects into about 20 initiatives. The next time we needed to reprioritize, we were ready. He could scan the 20 initiatives, see the resources allocated to each one and discuss tradeoffs in his staff meeting without any additional prep needed from the PMs.
The fire drills stopped entirely. Not because people got better at communication. Because the standard made the complexity legible.
The fact that standards work is part of the problem. Pretty soon you’re holding a process-hammer and every problem starts looking like a standards-nail.
Some problems are fundamentally variable. The inputs change, the context shifts, the required judgment is local. Standardizing these doesn’t streamline, it doesn’t reduce risk, it doesn’t create connection. Applying standards to the wrong problem doesn’t just create overhead, it can create risk.
A company I worked with had change management controls designed around application-layer changes: screenshots showing the environment, a date stamp, test results, all in one image. Reasonable for teams shipping UI features where changes are visible on a screen. The team documented the process narrative and worked with the independent auditor to confirm the control language. They even got a pat on the back for creating one process that everyone could follow.
But the process designers hadn’t accounted for the infrastructure team. They had to adhere to the same standard, even though their changes didn’t produce screenshots in any meaningful sense. The process didn’t fit their context, so they ended up having to choose between contorting their documentation to produce artifacts that didn’t reflect their actual work or failing the control.
Standards are a tool. A powerful one. But if you apply standards in the wrong places, you’re signing your teams up for operational busywork. And if the wrong standard gets codified into your control framework… the standard becomes unfollowable, the control becomes untestable, and now you’ve manufactured your own audit finding.
This week, I’m presenting “Stop Standardizing the Wrong Things” at the PLA Product Ops Summit. In my next post, I’ll share that framework for isolating where standards can help and where they can hurt.