Engineering Standards: Too many and not enough
- Myles Henaghan
- Jun 18
- 4 min read
Updated: Sep 19
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, system forces over time reach 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
Most teams don't need more standards — they need clearer, visible, and easier-to-follow ones. Here's how to get started without reinventing the wheel:
🔄 Propose, Review, Approve (or Reject), and Retire
Create a lightweight workflow (and healthy friction) that lets standards evolve. Something like
Propose: Any engineer can pitch a standard — ideally in a short template that captures the “what,” “why,” and “where it applies.”
Review: A community of practice or tech lead group gives feedback, ideally asynchronously.
Approve or Reject: A small respected panel decides if it becomes “official.”
Retire: Don’t let dead standards linger — review annually and flag for deprecation.
You don’t need new tooling to do this — Jira, Notion or even GitHub Issues/PRs can all do the job with a bit of structure.
📘 Document Once, Surface Everywhere
The full content of your standards — plus revision history and context — should live in a central, version-controlled space like a wiki, and linked to the original workflow item. But discovery needs to happen elsewhere:
Onboarding checklists
README files in repos (tip LLMs respond quite well to these)
Engineering portals and scorecards
Slack/teams bots (if you’re fancy)
Standards are only useful if engineers remember they exist before they write the code — not when they’re being reviewed.
🔍 Automate Compliance Where Possible
Many standards can be made enforceable (or at least observable) using:
Static analysis tools
CI/CD checks
Observability tools
Scorecard integrations from internal dev portals
These tools give you a way to see how adoption is going — and nudge teams if things drift. For things like practices e.g. all teams must perform activity x twice a year, just treat it like other audit requirements. Ensure you have some trail of evidence that it is happening. Ask to see it - trust but verify.
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