The Career Ladder That Accidentally Trained Everyone to Break Prod
If your promotion packet rewards shiny features and ignores reliability work, you’ll get exactly what you measure: fragile systems and burned-out on-call rotations. Here’s a framework that pays people for keeping the lights on—without turning into KPI theater.
If reliability isn’t promotable, you’re not doing “culture.” You’re doing incentive design—and incentivizing outages.Back to all posts
Most leveling frameworks I’ve seen in big companies (and I’ve seen a lot) have the same bug: they reward building new things and treat reliability as “keeping up.” Then leadership acts surprised when the org optimizes for feature throughput, ships brittle changes, and expects the on-call rotation to absorb the risk. The ladder didn’t cause the outages, but it absolutely trained people to create them.
If you want reliability, you have to make it promotable. Not with vague statements like “improves operational excellence,” but with concrete expectations, visible artifacts, and measurable outcomes that survive calibration and performance review season.
Below is what actually works in enterprise realities—where you have ServiceNow, quarterly planning, SOX change controls, legacy systems you can’t rewrite, and teams that already have too many meetings.
Key takeaways
- If reliability work isn’t promotable, you’re training engineers to ship risk.
- Define reliability as first-class scope with artifacts: `SLOs`, runbooks, postmortems, and risk buy-down plans.
- Tie progression to outcomes (MTTR, change failure rate, SLO attainment) and behaviors (incident leadership, follow-through, cross-team alignment).
- Create communication rituals that make reliability visible: weekly risk review, incident learning review, quarterly reliability planning.
- Make leadership do the hard part: protect error-budget time, celebrate boring wins, and stop promoting heroics.
- Use a “reliability portfolio” section in promotion packets so the work survives calibration.
Implementation checklist
- Add reliability expectations to every level (not just SRE).
- Require at least one reliability artifact per quarter per team (SLO, runbook, game day report, postmortem).
- Introduce a weekly Reliability/Risk Review with a standard agenda and owners.
- Update promotion packet template to include a Reliability Portfolio.
- Publish a reliability scorecard with 3–5 metrics: SLO attainment, MTTR, change failure rate, paging load.
- Create a policy: feature work that consumes error budget must include a stability plan.
- Train managers on how to evaluate reliability contributions fairly.
Questions we hear from teams
- Won’t this slow down feature delivery?
- In the short term, you’ll surface tradeoffs you were already paying for—just via incidents, churn, and customer escalations. Making reliability promotable shifts time from unplanned work (incident thrash) to planned work (risk reduction). Teams that adopt SLOs and change safety typically see lower change failure rate and fewer fire drills, which increases sustainable throughput.
- How do we avoid turning reliability metrics into KPI games?
- Keep the scorecard small, use metrics for trend not punishment, and require artifact-backed evidence (SLO docs, postmortems, dashboards). Combine metrics with qualitative behaviors: incident leadership, follow-through, and cross-team alignment. If numbers look “too perfect,” that’s usually your signal to audit definitions and data sources.
- We have ITIL/ServiceNow and strict change control. Can this still work?
- Yes—arguably it works better because artifacts and audit trails are already culturally accepted. Treat SLOs, runbooks, and postmortems as controlled documents; integrate reliability work into change records; and use quarterly reliability planning to justify sequencing and risk acceptance in language governance teams understand.
- Do we need a separate SRE ladder?
- Not necessarily. Many enterprises succeed with a shared engineering ladder where reliability expectations scale with level, plus an SRE specialization track for deep infrastructure work. The key is that product engineers can earn progression credit for reliability outcomes—not just feature scope.
Ready to modernize your codebase?
Let GitPlumbers help you transform AI-generated chaos into clean, scalable applications.