Sustainable Pace, Alert Fatigue, and On-Call Design

Core Concepts

The Demand-Control Model

Robert Karasek's demand-control model is the load-bearing theory behind sustainable engineering pace. It predicts outcomes from the combination of two variables: job demands (the pace, volume, and urgency of work) and decision latitude (the degree of control engineers have over how they work).

The worst quadrant is the one most engineering teams stumble into without noticing: high demands + low control. This combination produces what Karasek calls "high-strain" jobs—environments that generate elevated stress and depletion risk regardless of individual resilience or team culture. On-call scenarios make this concrete: an engineer who must respond to incidents on a mandatory schedule but cannot modify the alert thresholds, choose their escalation path, or adjust the rotation timing is experiencing high strain in its purest form. Responsibility without autonomy.

The inverse—high demands paired with high decision latitude—produces "active jobs." Engineers in active jobs report lower depletion despite handling significant incident frequency, because control provides the psychological and operational space to manage demands adaptively. On-call engineers who have the authority to define escalation protocols, adjust rotation schedules, and tune alert thresholds handle more work with less strain.

The difference between a burned-out on-call rotation and a functional one is often not the volume of incidents—it is the degree of control engineers have over how they respond to them.

The JD-R Model: Two Parallel Mechanisms

The Job Demands-Resources (JD-R) model extends Karasek by operating through two simultaneous processes:

1. The health-impairment process: Chronic job demands deplete cognitive and physical resources, leading to exhaustion. This is the burnout pathway.
2. The motivational process: Job resources—autonomy, feedback, social support, tooling quality—foster growth and engagement. This is the retention pathway.

These processes run in parallel. High demands initiate the first pathway. Adequate resources activate the second. This is why simply reducing demands without increasing resources, or vice versa, tends to produce incomplete results. The practical implication for org design: interventions that focus only on individual coping—meditation, time management apps, resilience training—underperform because they leave the demand-resource balance untouched. Structural change on both sides is required.

Autonomy as the Primary Buffer

Of all job resources, autonomy is the most effective buffer against the negative impact of high demands. When engineers lack the discretion to manage their own time, make technical decisions, or influence their workflow, even good tooling and collegial culture cannot fully offset the exhaustion created by high workload and on-call demands.

This has a direct structural implication: clear assignment of decision authority—through frameworks like DRI (Directly Responsible Individual) or explicit RACI—is not a governance formality. It is a burnout prevention mechanism. Ambiguous escalation paths force on-call engineers to either act without authority or delay while seeking approval—both outcomes erode control and increase strain.

Role ambiguity compounds this. When engineers are unclear about expectations, decision rights, or performance criteria, they spend cognitive resources seeking clarification rather than executing. This functions as a persistent job demand layered on top of actual workload.

The Optimal Utilization Range

Queueing theory establishes a practical constraint that engineering leaders often ignore: systems and teams operating at 60–80% utilization handle variability gracefully, while systems pushed above 85% experience steep latency increases. Beyond 80%, wait times increase dramatically and the system loses its ability to absorb spikes.

This is not a wellness argument. It is a systems argument. Engineering teams at constant 100% utilization have no slack to absorb incidents, urgent requests, or on-call load without something else slipping. The optimal utilization range provides headroom for variability—which is exactly what on-call rotations introduce.

---

Key Principles

1. Treat depletion as an organizational signal, not an individual failure

83% of software developers report experiencing burnout, with heavy workloads, unclear expectations, and constant interruptions cited as primary causes. This is not a population of people who need better coping strategies. It is a measurement of how common high-strain job design is in software organizations. Burnout and job satisfaction are inversely related—as depletion rises, satisfaction drops—and the relationship is not merely correlational. Depletion erodes efficacy perceptions, which erodes satisfaction, which accelerates attrition.

2. Design the control axis before adding resources to the demand axis

Adding engineers to an under-controlled system makes more engineers subject to that system's high-strain conditions. Job control and autonomy function as critical protective factors—the Conservation of Resources (COR) model explains this precisely: job control provides psychological resources (autonomy, mastery, efficacy) that protect against depletion. Expanding responsibilities without corresponding autonomy removes this protection.

3. Social support moderates but does not replace structural change

Social support from managers, peers, and team culture substantially reduces the impact of high job demands on burnout. Teams that normalize vulnerability and allow members to openly discuss being overwhelmed produce better outcomes than isolated problem-solving cultures. This is a real effect—but it operates as a moderator, not a substitute. A team with strong culture inside a high-strain job design is less depleted than one without it, but still more depleted than a team in a well-designed job.

4. Alert fatigue is a cognitive science phenomenon, not a willpower problem

When the stream of alerts surpasses an engineer's capacity to interpret them, attention declines, reaction times slow, and critical issues blend into the noise. This is not a trainable limitation. It is how human cognition works under high information load. Google SRE principles establish a sustainable cognitive baseline: a maximum of 2–3 actionable incidents per shift. If your teams are consistently handling 8–10 incidents per shift, the primary problem is not on-call staffing. It is alerting and classification.

5. Recovery from on-call is an operational necessity, not a courtesy

On-call shifts constitute sustained job demands that cannot be fully offset by single-shift rest. Engineers who carry a full project workload through an on-call period experience cumulative exhaustion because availability demands persist even when no incidents are firing. Google SRE invests at least 50% of SRE time in engineering, capping on-call at 25% and requires a minimum team size of 8 engineers for single-site coverage. Lighter workload expectations in the week following a heavy on-call period are a capacity management decision, not a perk.

6. Blameless postmortems are an information design choice

When incidents are investigated by allocating individual blame, team members suppress information, delay incident acknowledgment, and avoid speaking up during response. Blameless postmortems are not about protecting individuals from accountability—they are about ensuring the organization receives complete, honest information about what happened. Organizations with mature postmortem cultures experience 50% fewer repeat incidents and 43% faster recovery. This improvement is not accidental: it reflects the difference between an information system that surfaced the failure and one that obscured it.

---

Worked Example

Diagnosing a High-Strain On-Call System

A 14-person platform engineering team at a Series C company is experiencing attrition: three engineers have resigned in six months, all citing "on-call stress." The leadership framing is that the team needs to hire more engineers and implement better incident management training.

Let us apply the demand-control lens to this scenario.

Step 1: Measure the demand side.

The team runs 7-day on-call rotations, meaning each engineer is on-call roughly every two weeks. During the last quarter:

• Average pages per on-call week: 47
• Pages between midnight and 6 AM: 18% of total
• Post-incident reports completed on time: 31%

When on-call load is distributed across the rotation and trended over time, it functions as a leading indicator of unsustainable burden. Here the data is unambiguous: 47 pages per week is roughly 7 per day, far above the 2–3 actionable incidents per shift that SRE baselines recommend. The midnight-to-6-AM paging rate indicates significant sleep disruption across the rotation.

Step 2: Measure the control side.

Interview the team. Ask three questions:

1. Can you modify alert thresholds without a manager approval gate?
2. Do you know exactly who to escalate to at each severity level, and do you have the authority to page them without asking first?
3. Can you adjust your own project workload expectations during and immediately after an on-call period?

In this example, all three answers are "no." Alert threshold changes require a VP approval. Escalation paths are informal and inconsistent. Post-on-call recovery time is not structurally allocated.

The diagnosis: This is a high-strain job design in Karasek's terms—high demands, low decision latitude. The training and headcount response will not address the underlying mechanism. Adding two engineers to a high-strain rotation produces two more engineers in a high-strain rotation.

The interventions:

• Conduct an alert audit. Classify every alert by whether it requires immediate human action. Eliminate or downgrade those that do not. Target: max 2–3 actionable pages per shift.
• Publish a 4-level escalation matrix with explicit decision authority at each level (L0: automation, L1: on-call engineer, L2: service owner, L3: incident commander). Remove approval gates from L1 decisions.
• Implement structured recovery: engineers completing a weekend on-call shift receive a lighter workload allocation in the following week by default, not by request.
• Track on-call load distribution per engineer, high-severity page counts per rotation, and MTTR as a trend metric reviewed at the bi-weekly engineering lead meeting.

What happens to attrition? The mechanism: engineers who had no agency to shape how they responded to demands gain agency. The high-demand environment persists—systems still fail—but it becomes an active job rather than a passive-strain job. On-call engineers with authority to define escalation protocols and influence rotation schedules report lower burnout even with high incident frequency.

---

Step-by-Step Procedure

Designing a Sustainable On-Call System

Phase 1: Classify your alert volume.

Before changing rotation design, audit what the rotation is actually responding to.

1. Pull the last 90 days of alert data. For each alert, classify it as: actionable (required immediate human judgment), informational (could have been a dashboard metric), or noise (false positive or auto-resolved).
2. Calculate the ratio. If your system is tuned to maximize alerts fired, responders will learn to ignore them, and genuine critical incidents blend into noise. Target: eliminate or demote all non-actionable alerts. This is not a performance review on the instrumentation team—it is an incident health intervention.
3. Set threshold governance. Establish a process for reviewing alert thresholds quarterly, with on-call engineers as primary input. Setting thresholds too low creates alert fatigue; setting them too high misses genuine issues. The on-call engineers who live with the alerts are the best source of calibration signal.

Phase 2: Redesign rotation structure.

4. Determine minimum team size. Google SRE recommends a minimum of 8 engineers for single-site on-call coverage to ensure adequate rotation spacing. If your team is smaller, this is a forcing function for identifying which services actually require 24/7 on-call versus which services have an on-call rotation because it was never questioned.
5. Set shift length. Shorter shifts—8–12 hours—are better for engineer mental health and decision quality than 24-hour or 7-day blocks. Follow-the-sun models eliminate overnight shifts entirely by routing incidents to engineers in their daytime hours.
6. Define the recovery protocol. Formalize lighter workload expectations for engineers in the week following a heavy on-call period. This is a calendar item, not an informal conversation. Make it visible to the rest of the team so project planning accounts for it.

Phase 3: Publish escalation authority.

7. Write and distribute a severity-tiered escalation matrix. Each severity tier should specify: who is paged first, what decision authority they have without further approval, and when and how to escalate. A practical framework:

Level	Role	Authority
L0	Automation / runbooks	Self-healing only
L1	On-call engineer	All mitigations within their service domain
L2	Service owner / senior engineer	Cross-service decisions, deploy rollback
L3	Incident commander	Business impact calls, external communication

8. Test the matrix. Run a tabletop exercise. Ask each level: "You receive this page. What do you do? Do you have the authority to do it without calling someone first?" Gaps in answers are gaps in decision latitude.

Phase 4: Tie postmortems to severity thresholds.

9. Define postmortem triggers by severity. SEV-1 incidents: postmortem mandatory, leadership invited, broad organizational distribution. SEV-3 incidents: postmortem optional, at team discretion. Additionally, follow Google's error-budget policy: any incident consuming more than 20% of the four-week error budget triggers a mandatory postmortem with at least one P0 action item, regardless of severity tier.
10. Schedule postmortems within the window. 24–72 hours after resolution balances recency (details still fresh) with emotional distance (participants can analyze rather than react).

Phase 5: Run the postmortem.

11. Establish facilitation discipline. The facilitator's job is to keep the discussion on system factors, not individual performance. When "Person X should have checked the configuration" surfaces, the facilitator redirects: "What about our process made it easy to miss that configuration check?". Every human error is a signal that the system allowed the mistake.
12. Compose attendees cross-functionally. Include: the incident commander, engineers who handled the response, service owners for affected systems, product managers for business impact, and customer support or communications representatives. This composition ensures technical accuracy, business context, and customer perspective.
13. Specify action items. Each action item requires five elements: a named individual owner, a verifiable action verb, a specific measurable outcome, a deadline, and a ticket in the team's actual task management system. Action items that live only in postmortem documents are reliably forgotten.
14. Distribute widely. Organizational learning from postmortems increases proportionally with distribution breadth. A postmortem shared only with the incident response team is lost learning for every other team that runs a similar system.

---

Common Misconceptions

"We can solve this by adding headcount."

Headcount expands capacity, but not decision latitude. If the job design is high-strain—high demands, low control—additional engineers inherit the same conditions. The Conservation of Resources model is explicit: expanding responsibilities without corresponding autonomy removes the protective buffer that job control provides. Restructure the control axis first, then add capacity.

"If engineers are burning out, we need better wellness programs."

Individual coping interventions—meditation, time management, resilience training—underperform because they leave the demand side and resource architecture untouched. They may temporarily manage symptoms, but they cannot restore the demand-resource balance that sustained engagement requires. The research is consistent: team-based interventions that change job demands and resources produce better burnout outcomes than individual-focused programs.

"Our postmortems are blameless—we just need to track action items better."

Postmortem culture and action item completion are separable problems. Blameless narrative enables information flow; action item tracking is what converts that information into system improvement. Most organizations have gaps in both. The most common failure mode: technically blameless postmortems whose action items silently disappear because they were never entered into the team's task system.

"Leadership knows when the team is burning out."

The data says otherwise. 46% of engineers report their teams are experiencing burnout; only 34% of executives believe burnout is occurring at the team level. The perception gap is not a management failure of attention—it is a measurement failure. Burnout signals are visible to individual contributors who experience them daily and invisible to executives who have no telemetry on them. This is why leading indicator telemetry exists: not as surveillance, but as a transparency mechanism that ensures executive awareness matches ground reality.

"Alert fatigue is about having too many alerts. We just need to train engineers to triage better."

Alert fatigue is a cognitive science phenomenon, not a triage skill gap. When alert volume exceeds cognitive processing capacity, attention and decision quality degrade—this is a hard constraint of human cognition, not a trainable limitation. Addressing alert fatigue at the instrumentation layer (reducing noise, calibrating thresholds) is more effective than training because it changes the demand rather than asking engineers to cope with it differently.

"Focus blocks are a nice-to-have."

They are a productivity prerequisite. Protecting 2–4 hours of daily uninterrupted focus time yields productivity gains equivalent to 10+ hours of fragmented attention. When a team moved to no-meetings before noon for engineers, daily focus time improved from 2.3 to 5.1 hours per person within six weeks, and production bug rates dropped by 40%. The productivity impact of calendar fragmentation is not an experience report—it is measurable in defect rates.

---

Active Exercise

Exercise: Demand-Control Audit for Your Current On-Call System

This exercise produces a structured diagnosis of one team's on-call design using the demand-control framework.

Part A: Measure the demand side (30 minutes)

Pull the following data for the last 90 days from your incident management system:

1. Total pages per on-call shift per engineer (average and max)
2. Pages between midnight and 6 AM as a percentage of total
3. Number of engineers currently in the rotation
4. Average time each engineer spends on-call per month (hours)
5. MTTR trend (stable, increasing, or declining)

Plot the page-per-shift data as a simple time series. Are you trending up? Is load distributed evenly across the rotation, or concentrated on specific engineers?

Part B: Measure the control side (20 minutes)

For the same team, answer these questions:

Question	Yes / No / Partial
Can an on-call engineer modify alert thresholds without manager approval?
Is there a written escalation matrix with named roles and explicit authority at each level?
Does the rotation schedule include protected recovery time after heavy on-call periods?
Do on-call engineers have documented input into rotation design changes?
Are severity classifications updated dynamically as incidents evolve?

Count your "Yes" answers. 0–1: high-strain design. 2–3: partial control. 4–5: adequate control.

Part C: Identify one structural intervention

Based on your audit, identify the single control-axis change that would have the largest impact. Options:

• Alert audit: eliminate or demote all non-actionable alerts.
• Escalation matrix: write and publish a 4-level authority matrix.
• Recovery protocol: formalize lighter workload expectations post-on-call.
• Rotation resizing: add engineers or reduce rotation frequency.
• Threshold governance: establish quarterly review with on-call engineers as primary input.

Write one paragraph describing: (a) what you will change, (b) who owns the change, (c) how you will know it worked (the metric), and (d) when you will review it.

Part D: Leading indicator selection

Choose two leading indicators you will track weekly to monitor for depletion risk before attrition occurs. Options from the research:

• After-hours commits (late evening or weekend activity in source control)
• Pulse survey energy scores tracked longitudinally over 4+ weeks
• PR review wait times trending above baseline
• On-call load distribution imbalance across the rotation
• Calendar fragmentation index (contiguous focus blocks under 60 minutes)

For each indicator: name the specific measurement, where the data comes from, and who reviews it.