Engineering Standards: Too many and not enough
- Myles Henaghan
- 18 hours ago
- 4 min read
Updated: 12 hours ago
Standards, like dollars only come in two quantities - too many and not enough. And for those of you who eye-roll at the mention of standards (like me six years ago), instead championing automation, and culture... I know for certain, given enough time, we automate the unnecessary, people will forget, and new people won't be convinced.
The Importance of Engineering Standards
Just like Jeremy found out in season 1 of Clarkson's farm, when an engineering team reaches a level where they need a structured way of agreeing on standards. It creates a foundation for consistency, quality and compliance. Standards, when properly defined and upheld, become the backbone of engineering practices. They distinguish themselves from mere guidelines by being specific, observable, and universally agreed upon by the community.
Too Many [Standards/Guidelines/Best Practices]
On one hand, having too many standards, or guidelines misinterpreted as standards, can lead to overwhelming bureaucracy. When governance bodies, like those focused on security, cost, or privacy, go overboard, the standards become too complex and end up being ignored. This is when you get that "broken window" effect, where standards lose their respect and effectiveness.
Not Enough Standards
On the other hand, having too few standards leaves teams without a clear framework. This lack of structure makes it difficult to achieve consistency and alignment. Without written and agreed-upon standards, teams struggle with inconsistency, and the overall system suffers as a result.
If you’re a leader that believes you don’t need standards, people just know our do’s and don'ts, consider for a moment, if you were absent, how long before things would backslide? 1,3, 6 months?
So why bother?
On the bright side, once standards are well-established, they make decisions about what to automate significantly easier. Platform teams and independent experts can focus on automating processes that have become standards, rather than navigating multiple variations. This also means that as certain practices become ubiquitous and deeply embedded through automation or platform engineering, the explicit need for them as written standards can be reduced. This helps maintain a healthy balance and avoids cognitive overload, ensuring that standards remain focused on what truly matters and continues to drive improvement.
A Standard for Standards?
From our playbook on adoption Engineering Standards, my top tips would be:
Definitions: Make a strong distinction between best practices, guidance, standards, and standardisation.
Ownership: Ensure every standard has an owner - a real person who can (re)explain the rationale, and when the time comes help decide if it’s no longer valid.
Mandate: Leadership needs to actively demonstrate commitment to upholding standards which have been approved.
Document once, Discover everywhere. Keep the history and detail of a standard in one place with a consistent format. Link back to there from multiple other places (codebases, pipelines, portals, runbooks....)
👓 Practical Tips for Making Standards Work
Fewer, Clearer, Embedded
Engineering Standards aren't just rules — they're shared decisions that help teams build faster and better. But they only work if:
They’re owned and kept alive
Discovery is effortless
Feedback is part of the process
You automate the boring parts
So start with just a few. Pick the ones that unlock automation or reduce real pain. Then embed them where work already happens. Fewer. Clearer. Embedded.
Want to know more?
Let’s be clear, standards can be quite a dull topic, until they’ve become the top constraint and they go from dull to intimidating. We’ve helped many teams, and teams of teams figure out their approach to Engineer standards. From small SaaS to enterprise and highly regulated organizations. Please reach out if you’d like an initial chat about your organization’s needs.
Links 🔗
Comments