Earlier in my career, I worked on a large, monolithic, legacy codebase. As you can imagine, shipping new features was frustrating, bug-ridden, and time-consuming. We resorted to release trains (a release once every two weeks), but that still didn’t solve the problem of how unrefined the whole process was.

To combat this, we came up with the idea of appointing a "release captain" – an engineer whose sole task in the sprint was to ensure the release went out smoothly. By reserving a portion of our engineering capacity to address a frequent distraction, we stopped other engineers from having to split their focus between sprint tasks and release issues. This led to an increased velocity and less frustrated engineers. 

I have since applied this technique of reserving capacity in many other situations. During a sprint, reserving capacity means not utilizing 100% of an engineer's availability. The outcomes and advantages are always the same. In this example, we found that: 

• For the duration of a release cycle, there’s a clear point of contact to address release issues. 
• The rest of the team is free to focus on planned work instead of supporting the release ad hoc.
• We were able to quantify how much effort it was to manage a release – in this case, it was one engineer’s time for a sprint. This helped communicate the difficulty of the release and the opportunity cost to leadership in a way they could understand.

Capacity planning is hard

Planning how much work will get done in a sprint, before a sprint starts is a difficult task. What’s more difficult is then executing on planned commitments, as several factors can throw a wrench in progress. For instance:

• Production fires that need immediate attention.
• Last-minute business requirements, such as timed asks from marketing or requirements from legal that need to be addressed right away.
• Things that you have no power over, such as sick leave.

These distractions, which could be any task that isn’t an expressly assigned feature or ticket, take precious time away from planned sprint work and can result in projects falling behind schedule. 

Ultimately, failing to deliver projects on time can be traced to a lack of reserved engineering capacity.  Managers will allocate 100% of a developer's sprint time to tasks, leaving no room for unexpected issues. Though this is done to gain an engineer’s full skill set in the timeframe, it often sets an unrealistic bar. 

Reserve engineering capacity with ease 

As an engineering leader getting ready to assign sprint time, it’s good to be aware of other obligations that a developer might have running in tandem with their primary commitments. These disruptions to the sprint can span many areas. For instance: 

• Code reviews: Code reviews inherently require a lot of context-switching and are time-consuming if you want to provide quality feedback. 
• Legacy code: What might seem like a simple change can take a long time in a legacy codebase. 
• Situations outside one’s control: This can include access to tools, different permission levels, and approvals from different layers of management.  
• Disorganized bug intake processes: Without an official bug-triaging process, engineers won’t understand the bug’s priority, causing a lot of disruption. 

With so many potential problems being thrown at developers and no one way to address the root cause, leaders have to embrace them as beyond control. Code reviews are a necessary function of the job, legacy tech debt will require a major rewrite, organizational issues require a lot of political capital, and access controls are beyond the engineering team’s control. So we have to find a way around the problem. 

How to reserve engineering capacity 

Find your biggest pain point 

Amongst all the noise, you will find that one or two things cause the most disruptions to planned work. This is contextual for each company, but it is often one of the aforementioned issues. For example, I once worked on a team where a major disruption to our sprint work was bugs being sent from different sources. This could be project managers, quality assurers, or designers, and the occurrence was daily. Most times, a well-meaning engineer would pick it up, but it was happening often enough that it started becoming disruptive.

Dedicate some engineering time to that specific problem

Once you understand what’s throwing the biggest wrench in your machine, communicate with your team and pinpoint who will be responsible for dealing with this work – will it always be the same person? You may decide it’s to be a rotational responsibility (like on-call) to stop the same few engineers from volunteering. Set clear expectations that there’ll be no sprint work during this period. In the case of the daily bug disruptions, we decided to appoint one person dedicated to tackling the problem. This immediately provided a clear assignee for all issues, ensuring that no other work was dropped to address them. With no conflicting commitments, this person could dedicate time to triaging, prioritizing, and either fixing the bug or assigning it to the right person. 

Challenges in implementing reserved capacity 

The biggest hurdle in implementing “reserve capacity” is getting buy-in. There are two groups of people you need buy-in from – stakeholders and your team.

When introducing this pattern to your team, it helps to take a soft-handed approach.

• Start by emphasizing how important it is to get reliable story points.
• Keep reiterating that the goal of this exercise is to achieve a consistent team velocity.
• Gently encourage your team to prioritize sprint commitments first before taking on additional responsibility.
• Have mid-sprint check-ins to see how much work remains and how you can help your team finish those.
• Identify any work that’s straggling or taking longer than planned as it’s happening and identify ways to help before it becomes a problem.

When introducing your plans to stakeholders:

• Reiterate how much time your team spends on non-planned sprint work.
• Introduce the idea of holding up an engineer’s time so that others can focus. 
• If you get pushback, use data from the previous few times this issue has cropped up and quantify how much engineering capacity has been lost.
• Explain the cost and effects of context-switching.
• Be open to pushback and mention that you are trying this out for a short period of time and can pivot if it doesn’t work well.

The truth is both your team and stakeholders benefit when you provide accurate timelines and meet them. No one likes missing deadlines or being under pressure, so as your team is assimilating this new pattern of working, remind them of why you are making this effort. 

Does this require a full- or part-time role? 

A technical program manager (TPM) is a role that encapsulates reserving capacity. TPMs ensure that other teams do not block projects so that the sequence of deliveries happens in a way that de-risks the project. In this case, the cross-team dependency is the bottleneck, and the capacity assigned to mitigate it spans 100% of the TPM’s time. 

Be mindful that not all problems will require a full-time role. In many cases, an engineer only needs to dedicate their efforts for a short, part-time period. The duration of the period will depend on your problem. 

Final thoughts

Reserving engineering capacity is a powerful strategy to help teams manage unavoidable distractions and improve overall productivity. By dedicating specific time to handle disruptions, teams can ensure smoother workflows and more accurate project deliveries.

This approach reduces developers’ stress and frustration and provides a clear method to quantify and address bottlenecks within the organization. While it may require some initial effort to get stakeholder buy-in and properly implement the process, the long-term benefits of improved focus, better estimates, and enhanced team morale make it worth the investment. As you introduce and iterate on this practice, remember to communicate clearly with your team and stakeholders, and be flexible in adapting the process to fit your unique context.