Hands off handoffs
Handovers as a source of low trust
For people who are passionate about the organization of knowledge work, a handoff or handover — passing work from one person to another — is usually an antipattern or a signal that something might be off.
Handovers are a naturally anti-flow and thus a threat to speed and quality: They take time and effort, the time to warm up mentally is high (at least in software development), and there is always a loss of information involved. Even if you discount the effects of the “silent post” game, there is hard-to-codify information (reading between the lines, what is not written, what nobody thought of, what everybody took for granted, what everyone considered to be obvious). I know from my own experience that even the best interface specification will have gaps.
Although the idea “I just have to specify it well enough and then somebody else will do it without having to ask any clarifying question back” has been proven wrong by reality time and time again, it is still tried, lately under the label of “Spec-driven development”. For me, yet another example of “AI is the new Outsourcing”.
But for me, the most important problem with handovers is neither speed nor quality. Those are lagging indicators of the problem. Handovers are a condition for low trust. Not being accountable for bad decisions destroys trust, and this is what handovers often mean.
Interestingly enough, there are some world views and organizational setups where the belief that handovers work is baked in: Think of the Sales function: “I close the deal, you deliver.” This is the classical “we need to deliver what we promise” illusion!
This assumes software development is like factory work — predictable, profit a question of efficiency, execution a matter of planning and tracking. Rich Mironov wrote a great article explaining what is wrong here called “The Slippery Slope of Sales-Led Development” (which inspired an episode of The No-Nonsense Agile Leadership Podcast).
Or consider anything run via traditional Project Management only (and nothing else). You can rattle at everyone’s desk — but the thought that one person can keep an overview and report back to people in power to make timely decisions while the others only need to care about a small part of the overall picture is outdated. Both have in common that there is no actual ownership. Yes, you can officially assign “something” — but it is totally possible that that “something” is actually not doable.
The erroneous thinking that “handovers are efficient” is maximized in the traditional sequential setup, where a person in every function passes work to the next one. This is often called “Waterfall”, although it is not. (Explaining this in more depth is a great topic for a future article.) This implementation of “clear responsibilities” leads to an environment where nobody wants to take responsibility, and most of the stuff gets stranded somewhere between the functional silos.
One bonus mistake is trying to save money by outsourcing part of the value creation chain and hoping that the “high cost, high quality, high responsibility” part will keep the others up. See outsourcing development, testing, 1st-level support. It leads to the expected repeating pattern: Your system will break where you go cheap.
In these cases, it hurts no matter whether you are the sender or the receiver of a handover. You need to put in extraordinary effort to either get the message across or get it yourself. And this is when they are done well!
Handovers done badly come as two extra painful antipatterns: “The receiving party has no decision power in making adjustments if new information is learned.” / “The sending party is never fully let off the hook.”
Or even worse: There is no handover at all! “The person who did this has already left the company.” I got taught in university how to deal with these situations and built a large part of my career as a software developer doing just that. Let’s be very clear: This scenario is always the result of something gone wrong.
Ok, so is the message “handovers are always bad and cannot be done properly”? That would mean aiming too low intellectually — apart from wasting a lot of words for what can be expressed in one phrase.
A single person trying to do everything is usually neither effective nor efficient. Team Topologies uses the notion of “cognitive load” as an indicator for useful boundaries of team responsibilities. The trick consists in striking a balance, for instance service teams around product/software teams, and keeping the overall flow on the radar.
Hospitals have a lot of handovers, often via reports, and have some very good human interfaces. (This does not mean that there are never problems in this setup; I only admire the people that manage to do their work like this. And obviously valuable work!) Here, it is in the nature of handoffs that the original party does not have to care any longer. Think of someone arriving at the emergency and then being passed over to the different parts of care.
Get Gunnar R. Fischer’s stories in your inbox
Join Medium for free to get updates from this writer.
Some handovers are natural, like people leaving the company. Some complete handovers are good. People moving to another position should not be bothered anymore. Sometimes, forced handoffs can be useful to identify and resolve knowledge islands.
In general, I would still highly prefer handovers chosen by those doing the work over those handovers forced by somebody else. In some cases, law and regulation require that more than one person needs to be involved (4 eyes principle). In this situation, I recommend treating this as a boundary and design the process with this in mind with the goal of optimizing the whole.
It is a ironic that I have seen more than one organizational transformation that was treated like a “Dev vs. Ops” scenario, namely involving external consultants vs. teams that have to live with the solution. The credibility of these consultants (and their solutions) suffered from “out of this world syndrome”. An easy fix is “skin in the game”. I have experienced this myself where an Agile Coach that did the first interviews to assess the situation later also served in the day-to-day work, being directly affected by his own consulting, good or bad.
What else usually creates trust and enables handovers?
- working next to each other
- shared goals
- feedback loops
Working next to each other means communication cost is very low. Shared goals mean you have a vested interest in getting this done, whatever “this” means, whatever it takes. Feedback loops ensure you learn from each other.
Note that none of these are usually present in Outsourcing. Also note that “back to the office” in order to achieve “physically working next to each other” is pointless if the other two elements are missing.
I would like to finish with what I call the scale of handover ignorance levels. Where the problem sits determines what is the best solution.
Level 0: “It is fine. We just want to know how to do it properly.” — Shared goals to foster a “let’s get this done” atmosphere are the tool of choice. I love what James Birnie has written about Code Reviews.
Level 1: “Not sure whether it is needed or useful.” — Good practices help. Tracking the overall flow, seeing where work gets stuck or takes a lot of time, and reflecting what could be improved. Redesigning the process instead of just executing it well.
Level 2: “It is done for the wrong reasons.” — Then I would try to calculate the real costs or make the waste visibile. I would also ask “cui bono” — who profits from this setup? As sad as it is, some careers are built or maintained on inefficencies…
Level 3: “It is part of the worldview / business model / incentive structure.” — Honestly, good luck!
My own experience says that arguing about solutions in a level 3 situation where the person in power thinks it is a level 0 situation is a hopeless case. Pick your battles wisely and save your energy for the time it can make a difference!
Ottawa: Hands Up
