How do we avoid rewarding ‘incident heroes’ instead of prevention?

Define success as fewer, shorter incidents and documented prevention. Cap pager load, require postmortems with prevention actions, and value rollbacks and kill switches. Do not count pages as points.

What if product pushes back on error budgets blocking launches?

Make the trade-off explicit in planning: breaching error budgets increases churn and support costs. Use SLO data to quantify the revenue risk. Negotiate staged rollouts, feature flags, and risk-limiting canaries instead of hard stops.

We’re an enterprise with strict HR bands. How do we fit this in?

Translate reliability into the existing competency language (systems thinking, influence, delivery). Provide example behaviors and outcomes per level—HR-friendly wording plus hard metrics. Pilot with one org to prove it aligns to performance, not heroics.

How do we measure toil reduction credibly?

Track before/after counts of manual steps or time-per-step. Example: rotate secrets via automation saved 10 minutes per deploy x 200 deploys = ~33 hours/quarter. Require links to scripts, PRs, and runbooks.

What about AI-generated code that increases incident risk?

Set a policy: no AI-generated PR merges without observability, rollback, and test coverage. Tag cleanup as `toil-reduction` and reward `AI code refactoring` that reduces incidents. Don’t punish the on-call who cleans up vibe code; promote the prevention.

Culture · Nov 16, 2025 · 9 minute read

Stop Promoting Pager Tourists: Career Frameworks That Reward Reliability Work

If your promotion packets celebrate launch counts but ignore SLOs, MTTR, and pager load, you’re paying for outages with morale. Here’s the career ladder redesign that actually rewards reliability.

Back to all posts

Stop Promoting Pager Tourists: Career Frameworks That Reward Reliability Work

Key takeaways

Implementation checklist