Talk to us
The Standards Drift Audit
A 20-minute workbook to find the paper cuts stealing innovation time
Innovation rarely dies because of one big thing. It dies by a thousand small things: repeated decisions in PRs, inconsistent service readiness, dependency drift, coordination follow-ups, and rebuilding the same "baseline" every time a new service or scorecard shows up.
A lot of those paper cuts share one root cause: standards drift—the gap between what your org intends ("we do things this way") and what actually happens across teams and services.
Identify Standards
Find the top 10 repeatable standards that are being re-litigated or rebuilt
Score Them
Evaluate whether they're explicit, reusable, and enforced
Take Action
Select 3 standards to "make real" in the next 30 days without creating bureaucracy

The Core Heuristic
If a task or decision is repeatable, engineers shouldn't be re-deciding it every time.
Where OpsLevel Fits
Standards drift happens when standards depend on memory and heroics. The fastest way to reduce drift is to make standards verifiable.
When standards become checks on a scorecard, they stay true because the system measures them continuously instead of asking humans to remember.
That's the difference between "we should do this" and "we do this."
The 20-Minute Audit
Step-by-step process
01
List Your Top 10 Re-litigated Standards
Time: 5 minutes
Answer as a group (VP + Staff + EMs/Platform works well). Capture the repeatable friction.
02
Score Each Standard
Time: 7 minutes
Score quickly. Aim for directionally correct, not perfect.
03
Tag Risk Level
Time: 3 minutes
Classify as Low, Medium, or High risk for trust and automation.
04
Pick Your Top 3
Time: 3 minutes
Choose standards for the next 30 days.
05
Define Evidence + Exceptions
Time: 2 minutes
Document what proves it's true and who owns exceptions.
Step 1: Discovery Prompts
  • What do we explain in PR reviews over and over?
  • What "baseline checks" do teams rebuild each time they spin up a new service/scorecard?
  • What do we think is standard, but can't trust across teams?
  • When someone asks "how do we do this here?", where do they look besides docs?
Step 2: Scoring Guide
Explicit
Is it written down, discoverable, and current?
  • 0 = tribal knowledge
  • 1 = partially documented
  • 2 = clear and accessible
Reusable
Can teams apply it without rewriting from scratch?
  • 0 = mostly custom each time
  • 1 = partially reusable
  • 2 = fully repeatable
Enforced
Does it stay true without heroics?
  • 0 = inconsistent
  • 1 = partially reliable
  • 2 = systematically enforced
Step 3: Risk Classification
Low Risk
Start here: formatting, dependency bumps, doc updates, config hygiene, metadata consistency
Medium Risk
Small refactors, flaky test fixes, config changes with good tests
High Risk
Production behavior changes without strong tests or clear rollback paths
Audit Worksheet
Copy and customize this table for your audit session
Use this worksheet to capture your standards audit. Focus on the standards that repeat most frequently and have the highest impact when made consistent. Copy + paste the worksheet below to get started with your audit.

Optional Enhancement
Add a repeat tag column to track frequency: Daily / Weekly / Monthly. This helps prioritize which standards to tackle first based on how often teams encounter the friction.
Using Your Results
After completing the worksheet, look for patterns:
  • Which standards score lowest on enforcement?
  • Where is the gap between intent and reality largest?
  • Which low-risk, high-frequency standards could you fix quickly?
These patterns will guide your selection of the top 3 standards to tackle in the next 30 days.
Use Case Library
Examples to get your wheels turning
Use these examples to prime your brainstorming. You're looking for the standards that are repeated and worth codifying.
Service Readiness & Ownership
  • Each service has a clear owner (team), on-call rotation, and escalation path
  • A runbook link exists (even if short)
  • "How to rollback" is documented for risky systems
  • Critical dependencies are identified
Reliability Basics
  • SLO/SLI basics exist for critical user journeys
  • Alert hygiene expectations (noise targets, paging thresholds)
  • Post-incident learnings are captured in a consistent format
Security Hygiene & Patch Discipline
  • Dependency update cadence ("baseline monthly, urgent security within N days")
  • Secrets scanning expectations and exception handling
  • Minimum bar for dependency freshness / vulnerability posture
Delivery Standards
"How we ship" consistency
  • CI gates: unit tests + lint + security scan (your baseline)
  • Release conventions (tags, changelogs, versioning)
  • PR template expectations (rationale, testing notes, rollback)
Operational Quality
"Paper cut killers"
  • Logging fields / correlation IDs / tracing propagation
  • Health checks / readiness endpoints conventions
  • Environment config conventions
  • Tiering / criticality classification with associated expectations

Pro Tip
Don't try to standardize everything at once. Start with the low-risk, high-volume standards that create the most friction. Quick wins build momentum for tackling more complex standards later.
Make Standards Real
Evidence → Scorecard Checks
For each of your top 3 standards, you need to define three critical components that transform good intentions into measurable reality.
Why Evidence Matters
Evidence turns standards from "good intentions" into something you can verify consistently. Without clear evidence, standards remain aspirational rather than operational.
Standard
Plain English description of what "good" looks like
Evidence
What proves the standard is true and being followed
Exception Policy
Who owns exceptions and how they're documented
Turn Evidence into OpsLevel Scorecard Checks
If your evidence can be answered consistently (owner exists, runbook link present, dependency freshness within policy, SLO defined), it can be tracked as a scorecard check. That's how you move from standards that depend on people to standards that depend on systems.
Mapping Examples
30-Day Rollout Plan
For your platform/staff lead
This plan is deliberately lightweight. The goal is progress, not perfection. Focus on making standards verifiable and reducing friction, not creating bureaucracy.
1
Week 1: Define + Align
  • Finalize the 3 standards + evidence
  • Name owners + exception policy
  • Identify the first 10–20 services/scorecards to apply against
2
Week 2: Apply the Baseline
  • Turn the evidence into scorecard checks for the initial set
  • Capture friction points ("why is this hard?")
  • Tighten language so teams don't interpret it 10 different ways
3
Week 3: Close Gaps + Reduce Friction
  • Fix the biggest blockers (missing ownership, unclear tiering, docs scattered)
  • Make it easier for teams to comply than to ignore
4
Week 4: Review Drift + Publish the Next Baseline
  • Re-run the scores quickly (Explicit / Reusable / Enforced)
  • Capture the before/after improvements
  • Choose the next 1–2 standards to tackle
Measuring Success
The best signal isn't "compliance %." Look for these leading indicators instead:
  • Fewer PR relitigations of the same decisions
  • Fewer "where do I find..." questions in Slack
  • Fewer surprises during incident response
  • Reduced time to onboard new services
When standards become automatic, teams spend less time coordinating and more time building.

Leadership Tip
Track reduced interruptions and fewer repeated decisions as your primary success metrics. These are the real innovation unlocks—not compliance percentages.
Before/After Capture Template
Before
Document the pain:
  • How many hours/week spent on re-decisions?
  • How many services lack the standard?
  • Latest incident caused by drift?
After
Measure the improvement:
  • Time savings per team
  • Services now compliant
  • Reduction in related incidents
Starter Baseline
10 checks engineering leaders standardize first
This appendix provides a turnkey starting point. These are the most common standards that reduce drift and unlock innovation across engineering organizations.
Service Readiness
1
Owner Present
Every service has a clearly identified team owner in your service catalog
2
On-call/Escalation Present
Incident response path is documented with rotation schedules and escalation contacts
3
Runbook Link Present
Even basic runbooks exist and are accessible when things go wrong
4
Tier/Criticality Set
Services are classified by business impact, driving appropriate standards
Reliability
01
SLO/SLI Defined for Tier-1 Services
Critical services have measurable reliability targets
02
Alerting Hygiene Baseline Met
Noise thresholds and paging policies prevent alert fatigue
Security & Hygiene
01
Dependency Freshness Within Policy
Regular updates prevent security debt accumulation
02
Vulnerability Posture Meets Baseline
Exceptions are documented and time-bound
Delivery
CI Baseline Present
Tests + lint + scan run automatically on every PR
Release Signal Present
Versioning, changelogs, or equivalent tracking exists

Getting Started
You don't need to implement all 10 checks at once. Start with the Service Readiness checks —they're low-risk and high-impact. Once teams see the value, expanding to Reliability, Security, and Delivery standards becomes much easier.
Next Steps
Use this starter baseline as a foundation, then customize based on your organization's specific pain points discovered in the audit. The goal is to establish a rhythm of continuous improvement where standards evolve with your engineering practices.
If you're ready to automate Standards Checks, book a call with us to see how we help teams level up without adding more toil.
10
Core Checks
Covering readiness, reliability, security, and delivery
30
Days to Impact
From audit to measurable reduction in friction