If you find your organization struggling to maintain velocity due to a high maintenance/support burden, consider creating a team whose sole purpose is to centralize the cost of these distractions.
The Problem
Problem: Your engineering org is consistently blown off-course by unplanned work like emergency outages, customer requests, internal demands, etc.
Symptoms include:
- An influx of “customer” and/or “support” tickets that are consistently pulled into sprints.
- Project delays due to teams context switching off of their planned work to deal with pressing issues.
Dealing with unplanned work is distracting. It leads to a reduction of output and shifts priorities in ways that can be confusing.
A Solution
If you are experiencing these symptoms, it’s time to rethink how you staff your organization to address them. One great way to address the problem is to create an “Unplanned Work Team” - whose main focus is to centralize the cost of context switching, thus keeping your remaining team on track and pushing core development forward.
Creating This Team
Team orchestration is important when thinking about how to staff such a team. I would recommend starting with a fully cross-functional team that is able to handle any task tossed its way.
Determine how often you want to rotate this team. Is it a sprint by sprint tour of duty? Something longer to allow them to get a sense of consistency? Or does it make sense to rotate developers as they transition projects?
There are a few other important considerations to make in order to successfully pull this off:
Define Their Work
Teams work most effectively when they have a clearly defined mission; a north star they can use to contextualize their work. A mission clarifies the scope of tasks the team finds itself responsible for as well as how they can measure progress towards their ultimate goal.
For a team focused on handling unplanned work, their mission should be to centralize the cost of context switching to a single group of developers.
Their impact can be measured by any number of metrics, but a few easy ones are:
- Customer Escalation Response Rates: The volume of customer escalations handled by the team and time required to respond to them.
- Need To Pull From Other Teams: The frequency with which team members need to leave their planned work to help this team out.
Measure Their Output
Defining this team and putting them to work is one thing; Measuring their impact on the rest of the organization is vital in understanding their return on investment. Work with your team to identify metrics they think are important to that team’s success and figure out ways to measure that output.
Tune As You Go
Chances are you won’t hit the nail on the head when you initially staff this team. Maybe they are overstaffed, maybe the mix of developer types isn’t quite right, etc. As with any process you manage - practice the art of reflection. Hold regular retrospectives to understand how this team is working; what makes them effective within the context of your organization; and how they can iterate to increase the likelihood of their future success.
My hope is that these tactics serve as useful guidance for organizations struggling to cope with unplanned work. If you have thoughts on this, I’d love to hear how your tactics have found success with regards centralizing the cost of context switching.
