Separating Planned and Reactive Work

Separating planned from reactive work involves clear definition, dedicated tracking, and distinct resource allocation. Planned work aligns with strategic roadmaps. Reactive work addresses operational incidents, urgent fixes, or critical support. Accurate classification and measurement are essential for predictable delivery and resource management.

Why This Happens

Reactive work often contaminates planned workstreams due to insufficient operational capacity or unclear prioritization. Teams typically under-allocate time for unplanned incidents. This leads to engineers context-switching from projects to production issues. Project managers absorb reactive tasks into existing sprints without proper re-estimation. The engineering organization then perceives scope creep or slow execution. Lack of dedicated incident response processes forces development teams to handle all operational escalations. Additionally, inadequate system observability delays problem identification, increasing investigation time. This directly impacts engineering velocity.

Investigation Process

1. Define Categorization Criteria. Establish clear definitions for planned vs. reactive work. Planned work contributes to product roadmap initiatives. Reactive work addresses production incidents, critical regressions, or security vulnerabilities requiring immediate attention. Define severity thresholds for reactive work.
2. Implement Dual Tracking Systems. Use separate, distinct tracking systems or tags for each work type. Planned work lives in project management tools (e.g., Jira epics, stories). Reactive work is logged in an incident management system. Link reactive work to its originating incident ID.
3. Establish Triage and Prioritization. Institute a formal triage process for all incoming requests. A designated on-call engineer or team triages new issues. They classify it as planned or reactive. They then assign priority based on impact and urgency.
4. Isolate Reactive Work Capacity. Dedicate a specific portion of team capacity for reactive work. This might be a rotating on-call engineer or a fixed percentage of each engineer's time. This prevents reactive work from entirely derailing planned efforts.
5. Track Time Allocation. Monitor the actual time spent on planned versus reactive tasks. Use time-tracking tools or retrospective analysis of incident logs. Compare actual allocation against planned capacity.
6. Analyze Root Causes of Reactive Work. For significant reactive incidents, conduct post-mortems. Identify underlying systemic issues. This helps understand why reactive work occurs. Incident investigation is distinct from incident response.
7. Feed Learnings into Planning. Use insights from reactive work analysis to inform future planning cycles. Prioritize work that reduces incident frequency or impact. This might involve re-architecting components or improving monitoring.

Practical Example

A team planned a new billing module for Q3. They allocated most engineering time to it. One week into the quarter, StripeHookProcessor service started failing intermittently. Customers reported missing subscription updates. PagerDuty alerted the on-call engineer. The issue was classified as P1, requiring immediate reactive work. The on-call engineer debugged and found a race condition in a recent deployment that was not fully tested. The hotfix development and deployment then took further time from a feature engineer. The following day, a critical security vulnerability surfaced in a third-party library used by the authentication service. This also required immediate patching, consuming time from two engineers. These reactive tasks were logged in the incident management system with high priority tags. The project manager noted multiple engineers pulled from the billing module. The team then reviewed their Q3 plan during an operational review meeting. They acknowledged the unplanned reactive work consumed from the billing module initiative. This forced a re-evaluation of the Q3 billing module scope and timeline. They adjusted expectations for the billing module delivery date based on actual incurred reactive time.

Preventing Recurrence

Operational improvements are key to reducing the bleed of reactive work into planned efforts. Implement robust monitoring and alerting for all critical services. This allows for proactive issue detection. Maintain a rotating on-call schedule with dedicated time for incident response. Ensure sufficient staffing for this role. Conduct thorough post-incident reviews for all critical incidents. Focus on identifying and addressing system observability gaps. Prioritize work that eliminates common sources of reactive toil. Automate repetitive operational tasks. Establish clear Service Level Objectives (SLOs) and Service Level Indicators (SLIs) for core services. This defines acceptable operational limits. Integrate security reviews early in the development lifecycle. This reduces last-minute critical vulnerability fixes.

What Teams Usually Do Instead

Many teams typically merge all work into a single backlog. Product managers then treat everything as a configurable backlog item. This confuses strategic priorities with operational necessity. They often pull engineers directly from feature work to address urgent issues without tracking. This creates an invisible drain on productivity. Teams might also over-commit to new features without accounting for operational overhead. They often assign reactive work to the first available engineer, regardless of expertise. This leads to inefficient incident resolution. Some teams also rely solely on development teams for all operational tasks. This prevents developers from focusing on new product capabilities. Others delay addressing technical debt and operational improvements. This ensures a steady stream of recurring reactive work.

Key Takeaways

• Define planned and reactive work clearly.
• Use distinct, separate tracking mechanisms.
• Allocate dedicated capacity for reactive work.
• Prioritize fixing root causes of recurring incidents.
• Measure and analyze time spent on each work type.

See also how we help founders build products and reducing unplanned engineering work.

Frequently Asked Questions

How Do You Separate Planned Work From Reactive Work?

We define categorization criteria, track each type in a distinct system or with distinct tags, and triage every incoming request as planned or reactive with a priority based on impact and urgency. We then reserve capacity for reactive work so it cannot silently consume the roadmap.

Why Does Reactive Work Leak Into Planned Work?

We see unclear prioritization and too little operational capacity, so engineers context-switch from projects to production issues. Project managers absorb reactive tasks into sprints without re-estimating, and without a dedicated incident process development teams handle every escalation, which the organization then perceives as slow execution.

How Much Capacity Should Be Reserved for Reactive Work?

We dedicate a specific portion of team capacity, either a rotating on-call engineer or a fixed percentage of each engineer's time. The right share comes from tracking actual time spent on planned versus reactive tasks and comparing it with planned capacity, then adjusting delivery dates when reactive time runs higher.

What Should Teams Do After a Reactive Incident?

We run post-mortems for significant incidents, look for underlying systemic issues, and feed the findings into planning. That means prioritizing work that reduces incident frequency or impact, such as re-architecting components, improving monitoring and closing observability gaps, and automating repetitive operational tasks.

What Do Teams Usually Do Instead?

We often see everything merged into a single backlog, engineers pulled off feature work without tracking, reactive work given to whoever is free regardless of expertise, and new features over-committed without allowing for operational overhead. That hides the productivity drain and keeps recurring reactive work flowing.