How On-Call Slows Feature Delivery

On-call rotations reallocate engineering time from planned development to unplanned incident resolution. This directly reduces the capacity available for feature delivery. The unpredictability of incidents prevents accurate forecasting of project timelines and resource allocation.

Why This Happens

On-call engineers are responsible for system stability. Incident response takes immediate precedence over other tasks. This interruption directly competes with scheduled feature development.

Incident volume and severity are often unpredictable. This makes it difficult to budget for on-call impact. Engineers shift focus from proactive building to reactive fixing. Context switching further reduces productivity for feature work. Production issues directly decrease engineering velocity.

Frequent on-call interruptions lead to task fragmentation. Engineers must re-establish context for development tasks after each incident. This overhead accumulates, slowing progress beyond the direct incident resolution time.

Organizational structures sometimes fail to account for on-call burden in planning. Teams are expected to meet feature goals despite unallocated reactive work. This leads to missed deadlines and increased pressure.

Undocumented systems or poorly understood codebases increase investigation time. This extends the duration of on-call engagement. Junior engineers on-call also spend more time resolving issues, further impacting their development capacity.

Investigation Process

1. Quantify On-Call Hours. Track actual hours spent by engineers on-call. Include incident response, post-mortem participation, and follow-up tasks.
2. Categorize Incident Types. Classify incidents by system, root cause, and severity. Identify recurring issues or problematic service areas.
3. Measure Feature Delivery Impact. Compare planned vs. actual delivery dates for features. Correlate delays with periods of high on-call activity.
4. Analyze Context Switching Overhead. Survey engineers on the time lost due to context switching post-incident. Estimate the hidden cost beyond direct incident time.
5. Assess System Reliability. Evaluate system stability metrics. Higher incident rates correlate with greater on-call burden. Identify bottlenecks before they cause outages.
6. Review On-Call Paging Data. Examine paging frequency and duration per engineer. Identify disproportionate burdens or 'hot' systems.
7. Cross-Reference with Team Roadmaps. Overlay on-call data with team roadmaps. Pinpoint specific feature delays directly linked to on-call duties.

Practical Example

A B2B SaaS company experienced consistent delays in its Q3 roadmap for a new analytics dashboard feature. The initial projection assumed a fixed timeline for a small team, and the feature was still incomplete well after that date.

Investigation revealed that two engineers on the dashboard team were also primary responders for the core API service. During Q3, the API service experienced many critical incidents. Each incident required hours of direct debug time, and post-mortems and follow-up tasks added more. For these two engineers, this amounted to a large block of unplanned work that consumed a substantial share of their allocated development time for the quarter.

Additionally, engineers reported significant time lost regaining context on dashboard code. Interruptions from PagerDuty alerts, even if resolved quickly, broke focus. This reduced their effective coding hours. The team also lacked sufficient observability into the API service, leading to extended debugging sessions due to incomplete log data. The analytics dashboard project saw its deadline extended. This incurred opportunity cost from delayed customer value and marketing campaigns.

Preventing Recurrence

1. Dedicated On-Call Teams. Establish separate teams focused solely on production support. This isolates reactive work from feature development.
2. Buffer Planned Work. Account for a percentage of unplanned reactive work in project timelines. Do not assume 100% feature development capacity.
3. Improve System Observability. Invest in better monitoring, alerting, and logging. Reduced MTTI (Mean Time To Isolate) lowers on-call impact.
4. Blameless Post-Mortem Actions. Prioritize reliability improvements from post-mortems. Address root causes to reduce incident frequency.
5. Automate Runbooks. Automate common incident response steps. Reduce manual toil during active incidents.
6. Share On-Call Burden. Distribute on-call responsibilities broadly across a larger pool of qualified engineers.
7. Service Ownership Clarity. Clearly define service owners and their on-call responsibilities. Reduce ambiguity during incidents.
8. Dedicated Reliability Engineering. Establish a dedicated SRE or Production Engineering function. They focus on preventing, not just responding to, incidents.

We plan capacity for reactive work as part of product engineering, so roadmaps stay honest.

What Teams Usually Do Instead

Many teams ignore or understate the on-call burden. They attribute delays to poor planning, not reactive work. This leads to unrealistic feature delivery expectations. Managers pressure engineers to 'catch up' on feature work after incidents. This results in burnout and reduced code quality. Some teams rotate junior engineers into complex on-call roles too early. This increases incident resolution times and impact. Others focus only on incident count, failing to track actual time spent. This obscures the true cost. They may also implement monitoring alone, assuming it prevents issues, without addressing underlying reliability. Companies often fail to backfill development time lost to on-call. They expect the same output with fewer effective hours, leading to perpetual delays.

Key Takeaways

• On-call directly consumes planned feature development capacity.
• Unpredictable incidents cause project delays and missed deadlines.
• Context switching after incidents significantly reduces productivity.
• Ignoring on-call impact leads to unrealistic roadmaps.
• Dedicated reliability work reduces future on-call burden and improves delivery.

For more on how we work, visit Better Software.

Frequently Asked Questions

How Do On-Call Rotations Reduce Feature Delivery Capacity?

They reallocate engineering time from planned development to unplanned incident resolution. Incident volume is unpredictable, so we cannot forecast it well, and each page adds context switching and task fragmentation. Teams that do not budget for this reactive work still expect full feature output.

How Do We Measure the Hidden Cost of On-Call?

We track actual on-call hours, including incident response, post-mortem participation and follow-up tasks. We categorize incidents, compare planned and actual delivery dates, survey engineers about context switching, review paging data per engineer, and overlay the results on team roadmaps to link delays to on-call duties.

What Should We Change to Protect Planned Work?

We buffer timelines for reactive work, improve observability, automate common runbook steps, and act on post-mortem findings. We also share the burden across a larger pool of qualified engineers, clarify service ownership, and consider dedicated on-call or reliability teams that isolate reactive work from feature development.

Why Does Context Switching After an Incident Matter?

Engineers must re-establish context for development tasks after each incident, and even quickly resolved alerts break focus. We see this overhead accumulate, so progress slows beyond the direct incident time. It reduces effective coding hours and is easy to miss when only incident counts are tracked.

What Do Teams Usually Get Wrong About On-Call?

Many ignore or understate the burden and blame poor planning instead. Others pressure engineers to catch up after incidents, rotate junior engineers into complex roles too early, track incident counts rather than time spent, rely on monitoring alone, or fail to backfill lost development time.