This post delves into how software teams can overcome operational overload, reclaim time for technical improvements, and align their efforts with business goals. Here’s what you’ll learn:
The challenges teams face when technical work is mislabeled as "BAU" or overshadowed by reactive and support tasks.
A practical framework for categorizing work into Strategic, Reactive, and Production Support to prioritize effectively.
How tracking work allocation data can drive continuous improvement, elevate technical work, and inform smarter planning decisions.
Uncovering the Challenges
The journey began with mounting frustrations among teams. Engineers often expressed how business, product, and operational demands overwhelmed their ability to focus on technical investments. Much of the work fell into the reactive category, such as minor escalations or on-call firefighting, leaving little room for innovation or addressing technical debt. This operational burden signaled a deeper issue: technical work was often categorized as "Business As Usual" (BAU) rather than as strategic investments worthy of prioritization.
Initially, we identified two primary challenges:
Neglected Technical Improvements: Efforts to reduce technical debt, optimize processes, or enhance tooling are often deprioritized due to unclear work categorization.
Operational Overload: Teams frequently face heavy operational demands, leaving little capacity for strategic or technical improvements.
As the conversation progressed, we uncovered additional systemic gaps that further complicated the situation:
Inconsistent Terminology: Different teams use terms like "BAU" (Business As Usual), "KTLO" (Keep the Lights On), and "Operational Work" in varying ways, leading to confusion and misalignment.
Poor Capacity Planning: Without a shared understanding of work types, resource allocation during quarterly planning becomes inconsistent, leading to overcommitment or imbalances.
Limited Retrospection on Execution: Teams struggle to evaluate how much time and effort are spent on different work types, hampering continuous improvement efforts.
By addressing these challenges through a shared framework for classifying work, teams could finally align priorities, improve communication, and lay the foundation for better planning and execution.
Definitions of Work Types
Inspired by this post, this post, and the book The Phoenix Project, we developed the following definitions:
Strategic: Strategic work involves deliberate, long-term planning to achieve overarching goals. This type of work is primarily planned and well-defined. Meaningful technical improvements cannot be achieved by small, arbitrary allocations like "20% of a team's time"; they require deliberate investment to ensure impactful results.
Reactive/Tactical: Reactive/Tactical work is primarily unplanned and originates from the business or product. It addresses immediate needs or shorter-term goals.
Production Support: Production support refers to tasks that maintain the reliability and stability of live systems and handle customer escalations.
Work Type Classification Table
The initial baseline guidance for this framework was informed by conversations with industry peers who shared their experiences on "normal" work allocations.
Why does this work?
It improves flow. Like traffic lanes dedicated to different speeds, this establishes different allocations for work with distinct characteristics. Strategic work is like the express lane, ensuring high-impact initiatives reach their destination without unnecessary delays. Reactive work is the middle lane, handling faster-moving, unplanned tasks requiring attention. Production Support is the slow lane that keeps the system stable and addresses escalations.
By organizing work into these lanes, the framework achieves:
Improved Flow: Work progresses more smoothly when resources are allocated according to clear priorities.
Reduced Congestion: Teams can focus on high-priority initiatives without being constantly derailed by operational noise.
Aligning Work Allocation Guidance with Actuals
Overview
To better understand how well guidance for capacity allocation aligns with actual work distribution, teams were encouraged to track their activities sprint-by-sprint and conduct a summary review at the end of every quarter.
Approach
Classifying Work Types: During each sprint, label tasks or tickets with categories reflecting their nature, such as Strategic, Reactive, or Production Support.
Analyzing Distribution: Use sprint-level data and tools to quantify resources spent across Strategic, Reactive, and Production Support categories, culminating in a quarterly review for patterns and trends.
Documenting Findings: At the end of the quarter, convert findings into percentage allocations, aggregating sprint-level data for a comprehensive view. Provide context through examples of initiatives contributing to these allocations. The examples helped normalize definitions across teams.
Example Allocation Table
Leveraging Data for Future Planning
Using data collected through sprint-by-sprint tracking and quarterly reviews, teams can directly address the challenges outlined earlier:
Aligning Engineering with Business Strategy: Insights from work allocation data help justify investments in automation and tooling, demonstrate how engineering efforts align with business goals, and foster stronger stakeholder alignment. Patterns in reactive and support work also justify targeted investments to free capacity for innovation and reduce firefighting.
Proposing Targeted Investments: Patterns in reactive and support work justify investments in automation, tooling, or even bringing in contractors to handle operational tasks. This approach frees capacity for innovation and reduces firefighting, enabling teams to focus on strategic goals.
Balancing Workloads and Priorities: Analyzing resource allocation helps reduce operational strain, address reactive and support tasks, and prioritize technical improvements. It also enables more realistic planning cycles and balanced workloads across Strategic, Reactive, and Production Support tasks.
By tying these insights back to the challenges of operational overload, neglected technical work, and poor capacity planning, teams have seen encouraging success in driving continuous improvement and aligning with organizational priorities.
I love the segmentation you propose here. I've always been concerned by the usual 80/20 split because the 80 slice completely disregards tech initiatives oftentimes. Additionally, product AND tech work should always happen together (as opposed to split into 2 different buckets) if we want to facilitate effective, strategic engineering that is capable of supporting the product vision.
Great post!