Most engineering teams don't fail because they lack smart people.
They fail because standards slowly decay, even when everyone agrees they're important.
And the frustrating part is this:
it happens even on good teams.
Teams with experienced engineers.
Teams that care about quality.
Teams that have CI, code reviews, and best practices written down somewhere.
Yet over time, the same patterns show up.
The pattern everyone recognizes
Early on, standards are clear:
UI changes include screenshots
Behavior changes include tests
Risky changes include rollout notes
PRs explain what and why
At first, this is enforced naturally.
People remind each other. Reviews are thoughtful. Feedback is consistent.
Then the team grows.
Suddenly:
Screenshots are "usually" included
Tests are added "most of the time"
Rollout plans exist... except when they don't
PR comments repeat the same reminders
Nothing dramatic
That's what makes it dangerous.
Standards don't disappear --- they erode.
"Just this once" is the most expensive phrase in engineering
The decay almost never comes from bad intent.
It comes from moments like:
"It's a small change."
"We're rushing a hotfix."
"I'll add tests later."
"The UI didn't really change."
"We've done this before."
Each one feels reasonable in isolation.
But standards don't decay in isolation --- they decay in aggregate.
After enough exceptions, nobody is sure what's actually required anymore.
Why this isn't a people problem
A common response is:
"If people don't follow standards, that's a performance issue."
That's true in extreme cases --- but it misses the more common failure mode.
Most standards erosion happens because of:
time pressure
context switching
unclear ownership
reviewers missing things
seniors being offline
fatigue from repeating the same feedback
None of these are fireable offenses.
They're human limits interacting with scale.
As teams grow, relying on memory and vigilance becomes brittle.
The hidden cost: senior engineer fatigue
Here's the part we don't talk about enough.
When standards aren't enforced by the system, they're enforced by people.
Usually the same people.
Senior engineers become:
walking checklists
living linters
human reminders
They leave the same comments over and over:
"Can you add tests?"
"Do we have a screenshot?"
"What's the rollout plan?"
Over time, this leads to:
review exhaustion
rubber-stamping
resentment ("why do I always have to say this?")
Eventually, people stop fighting the decay.
Why CI and code coverage don't solve this
We already have great tools for certain things:
CI catches broken builds
Linters catch syntax and style
Coverage tools measure test presence
But they cannot enforce things like:
whether a UI change has visual proof
whether a risky change has a rollout plan
whether a behavior change was tested intentionally
whether an exception was justified
Those standards live in heads, docs, or tribal knowledge.
And anything that lives only in people's heads will eventually drift.
Checklists help --- until they don't
Some teams use PR templates or Jira workflows.
They help, but they rely on:
humans remembering to check them
reviewers enforcing them consistently
social pressure to comply
Over time, they become:
ignored
copy-pasted
treated as ceremony
At that point, the checklist still exists --- but the standard is gone.
The uncomfortable tradeoff: speed vs certainty
Every team eventually faces this tension.
Strict standards can feel slow.
Loose standards feel fast --- until something breaks.
The real problem isn't choosing one over the other.
It's that standards enforcement often depends on who's reviewing and how much energy they have that day.
That's not a stable system.
A different way to think about standards
Instead of asking:
"Did someone remember to enforce this?"
A better question is:
"Is this expectation explicit and verifiable?"
When standards are:
explicit
deterministic
applied consistently
They stop feeling personal.
They stop being debates.
They stop relying on heroics.
This isn't about control --- it's about clarity
Good engineers don't resist standards.
They resist unclear, inconsistent enforcement.
When expectations are obvious:
juniors aren't guessing
seniors aren't policing
managers aren't arbitrating constantly
Everyone spends less energy arguing about whether something is required --- and more on building.
An open question
I don't think most teams need more reminders.
They need fewer assumptions.
I'm currently exploring ways to make engineering standards:
explicit
provable
and consistently applied at merge time
Still early. Mostly listening.
If this pattern feels familiar to you, I'd love to hear:
where standards break down on your team
what feels unfair to enforce
what you wish the system handled for you
Top comments (0)