Our staff engineer ladder was written entirely around feature engineers. Promoting our first reliability-track staff engineer forced us to rewrite it from scratch.

When we tried to write the promotion packet for our strongest SRE, we discovered our staff-level rubric didn't have a category that fit anything he actually did. "Drives cross-team technical strategy" assumed a roadmap with a name on it. His biggest impact that year was a cardinality budget system that quietly prevented three separate teams from independently causing the same cost blowup.

The ladder that didn't fit

Our existing staff criteria leaned heavily on artifacts feature engineers naturally produce: design docs, launched systems, cited technical decisions. Reliability impact is often preventive and cross-cutting by nature — it shows up as incidents that stopped happening everywhere, not as one system with a name. Forcing that into the existing rubric meant either inflating minor projects to sound bigger, or underselling genuinely staff-level impact because it didn't look like the template.

staff_ladder_addendum: reliability_track
new_evaluation_dimensions:
  - blast_radius_of_prevention: >
      Scope of what this person's system/process change protects,
      measured in teams or services covered, not lines of code.
  - incident_reduction_attributable: >
      Quantified drop in incident rate/severity directly traceable
      to a system this person built or a practice they instituted.
  - cross_team_adoption_without_mandate: >
      Did other teams adopt this voluntarily because it was good,
      or only because it was required? Voluntary adoption scores higher.
"I kept trying to describe my work as a project with a launch date, because that's what the template wanted. It was never a project. It was a habit I got twelve teams to adopt."

What changed after we fixed the ladder

Within a year of publishing the addendum, two more reliability engineers were promoted to staff using the new dimensions, neither of whom had a single "launched system" in the conventional sense. Just as important, feature engineering staff packets started citing "cross-team adoption without mandate" too — it turned out to be a good dimension generally, not just a reliability-specific patch.

  • A career ladder built implicitly around feature-shipping artifacts will systematically undervalue reliability impact — audit yours explicitly.
  • Measure prevention by blast radius and voluntary cross-team adoption, not by whether it resembles a launched product.
  • Fixing a ladder for one track often improves it for every track — invisible impact isn't unique to reliability work.