This week we’re taking a look at how teams in high consequence domains perform handoffs between shifts. I’ve personally experienced some of these in both tech and the original domain and have found them useful.
How about you ? Have you used these or similar hand off strategies? How do you help make sure handoffs go well? Please hit reply and let me know, I love hearing about how others are doing this work.
This is a paper by Emily Patterson, Emilie Roth, David Woods, and Renee Chow. The authors look over several different domains, including nuclear power and ambulance dispatchers, examining the hand off strategies that they employ.
This paper was originally geared towards improving handoffs in health care, but as software people, we can learn a lot from the data gathered, putting some of the strategies to work for our own handoffs.
Since this data had been originally gathered for other purposes and observational study is shaped by the goals of the study, some work was done to ensure the data was still valid. They had original observers put together the summaries for analysts and also had someone familiar with the given domain review the analyst conclusions. Further, they only focussed on strategies that were relatively easy to observe, so nothing that may have been a cognitive approach in an individual was explored for example.
This also means that some of the strategies that are employed may have been missed, but I think the ones they review are still useful to learn from. They go over about 20 different strategies that they saw, we won’t go over them all, instead I’ll highlight a few of the ones that stood out to me and some of the ones that I’ve helped tech teams implement.
First though, why do handoffs? The authors tell us that failing to do handoffs or to do them poorly creates a risk of the incoming person having an incomplete model of the state of the system and leaves them less able to anticipate future events.
But beyond just creating risks if ignored, good handoffs can also add good things. Such as allowing the incoming person’s fresh perspective to help detect fixation errors.
A common theme that emerged across many of the strategies was that the teams prioritize handoffs; they treat them as a critical part of the work itself and of getting up to speed to be able to perform it. They do this in a few different ways. One way that showed up across domains was to create social norms where handoffs would not be interrupted except for emergencies.
Another, at least as was the case in space shuttle mission control (see issue 24 for more about mission control structure), was to give up to an hour of overlap between shifts so that the outgoing and incoming people were able to work side by side for a time. Other domains did similarly on as needed basis. Though they had a clear mechanism to indicate who was in charge (usually with the transfer of the console or headset), if they felt it was needed for training or difficult situations, the outgoing person could stay near at hand for a time. Teams were also willing to engage in some strategies that tradeded efficiency for effectiveness.
I’ve seen cases where handoffs can be something that is done by rote, something that falls into the background, just one more step on a checklist so that the outgoing person can just get home already. It’s understandable that this happens, but I believe it definitely hurts the effectiveness of handoffs. One way that teams seem to have combatted this in the study was by having both people, incoming and outgoing, bring up topics. This wasn’t just a one way info dump. The
outgoing person would also include their stance on the current issues along with the updates.
Other strategies seemed to be able to help effectiveness and efficiency. Some teams wrote a 1 paragraph summary of what happened. This wasn’t something that neccessarily became part of the official record, but helped them be ready for the verbal report. I’ve personally seen this be effective as well, especially for teams that are just starting to do handoffs. The danger here is that this starts and ends with a rigid template. Having a guide on what to include can be helpful, but it’s important to make sure that there is room for the outgoing person, the observer and expert in the situation, to include whatever they think is important to know.
Some teams included information that wasn’t in the verbal report when they did the actual transfer. This could be things like documentation or tools to save the incoming person time in tracking it down. I think there is lots of room in most software teams for this strategy especially, to transfer what references one might be using to the next person.
Finally, many of the domains created situations in which others can overhear the different handoffs. This allows for error checking, calibration, and anticipating of questions.
When to do handoffs? In software teams, we may or may not have such a well defined shift structure, so it may be less obvious where we can hand off. I think a good target to start is with incident command. Any time you’re changing the incident commander or swapping out a responder is a good time for a handoff. Also, if your team has a support rotation of some sort, you can use some of these strategies during the transition.
A caveat as we close though. These strategies were all observed in an in person, face to face, verbal setting. Not all of the strategies are going to be able to translate well or at all to remote teams. I do believe, and my experience tells me, that many of them can be modified, sometimes very little, to be effective in remote teams as well.
Takeaways
- Having a consistent, understood process for performing handoffs can help keep mental models up to date and assist planning.
- All the domains observed had a common theme of prioritizing the handoffs. This includes things like:
- Social norms of not interrupting handoffs except for emergencies
- Dedicating time, sometimes including up to an hour overlapping shifts to update incoming staff
- Some strategies prioritized effectiveness over efficency, but others were able to preserve both, such as:
- Including their stance on an issue in the update
- Providing documentation and tools in the transfer that wasn’t covered verbally
- Writing a short summary of the handoff to prepare for a verbal one
- The strategies examined were all face to face, so may not be applicable for all remote teams, though I think many of the strategies can be modified as needed and retain their effectiveness.
Subscribe to Resilience Roundup
Subscribe to the newsletter.