Ashley’s legs churned. Her feet flew across the asphalt. Ahead of her, Becky started into a slow jog, gradually picking up her pace, arm extended backwards. “Becky was so tan last fall,” Ashley mused, noticing how pale Becky’s arm was against the track, while another part of her brain noted what a strange thought that was and chalked it up to oxygen deprivation. Ashley willed herself to move just a bit faster, reaching out, putting the baton squarely in Becky’s hand. Becky’s hand closed around the baton and she lunged forward. Ashley coasted to a stop, gasping for breath, careful to stay in her lane. “Come on, Becks!” she shouted, then put her hands on her knees, head up, watching Becky edge out Central’s anchor. Oh, how good the win felt!

Handoffs are an important part of sports. Very literal handoffs happen in relay races, American football, basketball, and more.

Emily dribbled the ball with her right hand, reading the defense. She drove in, hard, toward the right side of the court. Just as her toes touched the three point arc, she changed direction, almost instantly. She crossed the ball to her left hand, running just outside the arc to her left, feeling the defender at her heels, fired a hard pass to Denae at the top of the key. Denae turned to shoot and both inside defenders jumped toward her, arms up for the block. Instead of releasing the shot, Denae pulled the ball down, pivoted, handed the ball to Emily. Emily passed Denae, cut hard to the basket, past the defense tangled up on Denae, up for a left-hand layup.

But I’m not really writing about sports here.

Carl’s legs churned. His feet flew across the asphalt. He was by far the fastest runner at East, and he knew his job was to set up the team for a win. Ahead of him, Darrell stared back, unmoving. Carl extended the baton, while some corner of his brain wondered if he’d be setting the school—or state!—record for fastest relay leg. Darrell’s hand went up, ready to take the baton, but his feet stayed planted. Carl pulled up to avoid knocking Darrell over, slapped the baton in Darrell’s hand. “Go! Come on, Darrell! Let’s go! Come on! You can do this!” Instead of turning and sprinting, Darrell examined the baton. Orange, shiny, 11.5 inches, hollow¹. “Darrell, dude, turn around. Run. Stay in the lane, get to the finish line. Go, dude, go!” Darrell nodded, turned, and jogged off. As Coach would say later, at least they’d stayed out of last, if only because that kid from Lincoln had tripped, hurt himself, and had to be helped to the finish. As for Carl, he had indeed set the state record for his leg.

I’m writing about work. Organizational life.

“Set, hut!” yelled George. The center snapped the ball and George dropped back from the line, ball at the ready, eyes watching his star receiver. No good, bracketed by the defense. George turned and extended the ball to Henry, the running back. Henry ran forward, put two hands on the ball. George noted how high and tight Henry tucked the ball—great work, no possible way the defense could knock that out. George’s satisfaction dissolved as Henry stopped and said “hey George, uh, on this play, which way do I run? And, uh, if it’s inside, which gap is the line expecting me to hit?” Before George could answer, though, two defensive linemen found gaps of their own and barrelled into Henry. Losing four yards on the play hurt, but probably not as much as Henry’s shoulder after that hit.

Everyday, on-the-job working life.

“Now that the poster is ready, let’s get that to the printer before they close.” That’s a handoff.

“The engineering diagrams are done? Great, send those down to manufacturing so they can set up a first run.” Handoff. “The page designs are done? Sweet, send them over to the web developers and ask them when the page can be live.” Handoff.

There is a chance, be it ever so small, that you may have been involved in at least one handoff in your working life.

More than that, there is a chance, be it ever so small, that you may have been involved in at least one handoff in your working life that didn’t go well. Instead of Ashley to Becky, your handoff was Carl to Darrell. Instead of the beautiful flow of Emily and Denae’s play, it felt more like George handing off to Henry. It just didn’t go well.

Unlike those ridiculously contrived examples, though, it wasn’t obvious why it didn’t go well.

It’s strange, really, given all the good reasons for handoffs. Handoffs are a powerful tool. People can work in their area of expertise. Risk can be contained and monitored. Work can flow smoothly through large organizations running complex processes to build complex products. Think of a Honda Civic. There are hundreds or thousands of handoffs involved in building one. There is no way a person, alone, could build one in their lifetime². Honda builds hundreds of Civics every day, handing off parts and assemblies until a finished car rolls off the line.

Despite all those reasons, sometimes handoffs don’t work³. That’s because sometimes, handoffs get in the way of getting work done.

Handoffs have some costs. There’s the need to transfer context (or the cost of not transferring context). When parallel work is involved, there’s a need to integrate work product. Quality can suffer. Dependencies can be ignored, not mentioned, or discovered late in the process. There’s a loss of control over the work as it gets handed off. The costs of handoffs are sometimes hard to notice. They masquerade as other problems⁴.

Let’s start by defining what a handoff is, for the purpose of this essay.

You’ve seen physical handoffs for most of your life. You’ve sat at the dinner table and seen Uncle Frank pass the salt to Cousin Walter. That’s a handoff. You might have watched a relay race and seen sprinters pass a baton at a full-on sprint. That’s a handoff. You might have watched the quarterback hand the football to a running back. Handoff.

Your intuition is right. A handoff is when some thing gets passed from one person or team to another.

But, you might point out, at work it’s not usually quite so physical. “Handoff” in that context is a bit more metaphorical. What “handoff” usually means at work is that a task or unit of work is being passed from one person or team to another. The order from table four is handed off to the kitchen. The TPS report is handed off to your manager. The design is handed off to the programmers.

Even so, the definition stays that simple. A handoff is when some thing gets passed from one person or team to another. It doesn’t have to be physically passed. Any transfer of ownership, responsibility, control, execution (whatever you want to call it) can count.

Now that we have a definition, let’s take a brief look at a couple of the costs of handoffs. This isn’t a comprehensive treatment of any of the problems, and certainly not a look at all of the costs. That might fill a book, but I’m not sure it’d be worth writing⁵.

The first cost I want to look at is transferring context. Work items exist in context. Some of that context is easy to transfer: “the photos you’re taking are for the trade show next month.” Some of that context is less easy to transfer—all those discussions you had with the rest of the team about the nuanced message you’re trying to send at the trade show, and how it differs from the messaging your company has historically done, and how it builds credibility for that important pivot you’re planning for next year, for example. Then there’s the context you’ve forgotten about because you’ve been in it for so long that it just feels like the wallpaper. It’s really easy to forget to clue the next team in about something essential because “everyone knows” it. And the receiving team doesn’t know enough to ask.

Next cost: managing dependencies. A “dependency” is another task that the original task relies on⁶. Dependencies mean teams (or individuals) that are performing tasks must rely on other teams (or individuals). At the very least, relying on other teams⁷ means work is not divided into the nice, neat compartments that handoffs imply⁸. The team handling the original task and the dependency must communicate—and there may be communication back upstream to find out if the team handling the dependency has already been contacted. If that communication among teams breaks down, it’s very, very easy for work to pile up on one dependent team, throwing off the planned schedule. The further removed the planning team is from the deep dependent teams, the more difficult it is for the planning team to recognize the dependencies and where they might pile up⁹.

Last, let’s look at quality and loss of control together. When handoffs occur, a piece of work is passed from team to team. If there are quality issues with that piece of work that affect the receiving team, they’re relatively easy to correct¹⁰. Not all quality issues affect—or are noticeable by—the receiving team¹¹. When quality issues get introduced that are only detectable much later in the process, the cost of those issues can multiply. But aside from the cost of correcting the work, this scenario demonstrates how handoffs reduce control over the work. It’s not possible to control work if visibility into the work is limited. Correcting this is simple in theory (provide sufficient visibility into the work to control it, or provide sufficient context at each step to ensure localized control aligns with overall goals). That said, we’ve already touched on the difficulty of transferring context, and providing enough visibility for control has similar difficulties. To put that a bit differently, solving the problem of maintaining quality of and control over work across handoffs likely requires creating expensive oversight systems¹² or finding an approach that does away with handoffs.

Okay, great. So handoffs have costs. But let’s be honest here. The web designers don’t have the development skills to build the pages they designed. The engineering team honestly doesn’t have a clue what goes into the manufacturing set-up. The accounting team doesn’t know what goes into shipping the product. And yet, we want to make sure the product gets designed, built, shipped, that the accounting gets done, and that we are running our business efficiently and reducing risk where it makes sense.

There are three basic paths for getting the work done when various skillsets are needed: clean, mechanical, well-designed handoffs; overlapping handoffs; or cross-functional delivery teams with tight feedback loops.

Clean, mechanical, well-designed handoffs are exactly what they sound like. They’re what you’d expect to see on an assembly line. Station B expects a partly-completed widget from Station A. Workers at Station B have the materials they need available to complete their work on the widget. Once it’s done, they pass the widget along to Station C. There’s very little thought needed in these processes. The third widget of the day gets the same treatment as the thirty-third widget.

The mechanical handoff approach is a terrible choice for most knowledge work. However, it’s a common choice. Someone writes a specification, draws some diagrams, generates some mock-ups, gives a presentation, and expects the downstream team to be able to instantly take the metaphorical baton and run full speed with the project. Usually the downstream team is as confused as Henry was. Or they dawdle along because, like Darrel, they don’t recognize the urgency of the project.

If handoffs in your work world are clunky, there is a good chance that you’re aiming for the clean, mechanical handoff approach and that you’re thinking about ways to make your handoffs work better. Maybe you’re planning to increase the detail that goes into your specs, draw more diagrams, hold more detailed handoff meetings, spend a bit more time on the presentation, or use reverse briefings¹³. Let me save you some effort: that’s not going to help as much as you’re hoping it will. If you’ve been on the receiving end of a handoff, you know why. Things are obvious when you already know them, and the hander-offer doesn’t want to waste time or insult your intelligence by telling you things that are obvious. Except, of course, they’re not obvious to you, the receiver. Or, in other cases, the time and effort to create handoff materials and truly transfer context in sufficient detail begins to approach—or dwarf—the expected benefit from handing the work off. Instead of trying to find the magical fix for mechanical handoffs, consider one of the other basic paths.

Overlapping handoffs are handoffs in which the hander-offer spends some actual work time working on the task along with the receiver. It’s not simply a presentation or the old “if you have questions, you know where to find me” bit. Instead, the hander-offer joins with the receiver to provide guidance, context, and the right sense of urgency. When the receiver is properly up to speed and is able to independently move the task along, the hander-offer pulls back.

The overlapping handoff approach can be reasonable for many types of knowledge work. It’s often rejected as inefficient (“Why should my web designer waste time working alongside my developer? There’s more designs that need to be done, you know!”), and I’ll admit: it may be less efficient having two people working on one task. However, I’ll argue: it’s often more effective to do a better handoff. It would have been more efficient for Becky to stand still until Ashley had handed off the baton. That would have gotten the baton to Becky faster¹⁴, saved a bit of Ashley’s energy for the next race¹⁵, and even reduced the risk of a dropped baton¹⁶. Wow, I’ve almost convinced myself that relay teams should adopt the more efficient approach—it’s that much better on paper!

The results of relay race handoff techniques are easy to see¹⁷. Knowledge work is harder to measure effectively. If you’re using an efficiency argument for opposing overlapping handoffs, I would make a high-confidence guess that you’re not measuring lead time, cycle time, quality, or organizational alignment on results. You may be optimizing each department or team’s metrics at the expense of overall outcomes. Counterintuitively, optimizing subsystems is a good way to reduce the performance of the overall system!¹⁸

(TL;DR of the last couple paragraphs: don’t reject effectiveness for the sake of efficiency, especially if your current approach is ineffective.)

Trying the overlapping handoff approach takes a small shift in mindset. Instead of keeping each team or work center fully loaded (optimizing for workload efficiency) or racing to pick up the next task (optimizing for speed-to-start or minimizing intake queues), the mindset shifts to ensuring that the work item continues moving toward completion without loss of momentum¹⁹. Teams that are not fully loaded are okay. Period²⁰. Doubly so if by having a team less than 100% loaded allows them to be available to receive a handoff without delay in the work.

The third basic path is cross-functional delivery teams with tight feedback loops. Truthfully, this path bypasses handoffs. Instead of a designer doing a bunch of work and handing it off to a developer, the designer and developer work together. Instead of a product engineer doing a bunch of work and handing it off to the manufacturing team, the product engineer and manufacturing folks work together.

If you’re feeling a deep distaste for the inefficiency of this idea, I’ll invite you to suspend your disbelief for a paragraph or two. You don’t have to implement this, or even try it. But don’t dismiss it so quickly you don’t even consider the possibility there might be something worthwhile lurking inside.

There are some big costs that come with handoffs: transfer of context, dead time when work waits in queues between work centers or teams, loss of focus, loss of ownership, communication overhead, high probability of misalignment, rework, ineffective risk management, and more.

A cross-functional delivery team works together. The entire team knows the context they are operating in. They have a shared focus, so work doesn’t pile up waiting for a downstream team to pick it up. They communicate regularly within the team. The tight feedback loops keep them closely aligned with each other and their stakeholders, which preserves ownership and reduces risk of rework, while making risk management a part of the rhythm of getting the work done. The efficiency of each individual member of the team might be less, but the overall effectiveness of the team at delivering suitable work product quickly can go up.

In the example above with Emily and Denae on the basketball court, neither player was 100% utilized²¹. In fact, Denae only had the ball for a second, maybe two. But she pulled in two inside defenders and let Emily drop a third, making a basket for Emily much easier²². Would Denae have been a more effective player if she had been “doing more”, perhaps by chasing around the court screening off defenders or calling for passes? No. Should she have “gotten ahead on things” by starting on the next play? No. She served the team best by being in position at the right time, knowing the play the team was running, and doing her part quickly²³. It’s pretty obvious in a sports setting, but we somehow feel like a work setting lets us be clever and squeeze more work in.

Enough about cross-functional delivery teams for now. If you don’t want to take that path, don’t²⁴. But if your handoffs feel clunky, consider a path other than clean, mechanical handoffs.

It turns out clean, mechanical handoffs are the most costly option. It’s just harder to see the costs.

Don’t hold handoffs as a sacred requirement. Hold handoffs as a handful of options. Pick the model that best helps you achieve your goals.

1. very rigid! Aluminum is an unusual material for a wand, of course, but … oh. It’s just a baton? [↩]
2. I’d love to be proved wrong. That’d be really cool, actually. [↩]
3. Once upon a time I was working with a team building a stage set. We had some door size constraints that made it hard to have the height we wanted. We came up with a clever design, and a mechanical engineer on the team ran some pretty extensive calculations to make sure the jacks and supports would hold safely. Just to check all our boxes, we checked the designs with the facility’s stage manager. He looked at the design and vetoed it for safety reasons. Our mechanical engineer pulled out the calculations. The stage manager’s response: “Sometimes physics don’t work.” [↩]
4. Sometimes handoff problems are blamed on people: laziness, inattention to detail, not “knowing how we do things around here”, asking too many (or not enough) questions, not “being bought in” to a project. Sometimes handoff problems are blamed on tools or processes: we need to get our project management software configured right, we need to test more, we should get more diligent about capturing all the requirements up front. Those handoff problems are sneaky like that. [↩]
5. “All the Costs of Handoffs: Problems Galore” can get shelved next to “1001 Ways to Mess Up a Cake” and “You Should Open Your Garage Door Before Pulling Out: An Illustrated Guide”. The schadenfreude might be fun, but the usefulness might be limited. [↩]
6. Less often, “dependency” is used to mean resources or teams that the original task relies on—but that is often because the team is needed to perform a task (which is actually a subcase of the “task” definition). [↩]
7. Or individuals! [↩]
8. Or complexity gets added by converting an acyclic graph into a cyclic graph. The easy math of counting up the schedule at each step of an acyclic graph becomes much less deterministic when cycles are introduced. [↩]
9. With sufficient investment into planning, these dependencies can be identified. Unfortunately, an investment sufficient to identify piled up dependencies is often a large enough fraction of the anticipated project schedule that it’s not worth making. Insufficient planning brings obvious costs; over-planning comes with its own set of costs; finding the exact right amount of planning is left as an exercise for the interested reader. [↩]
10. As a super-simple example, imagine Dad just asked Junior to pass him the hammer. Junior passes Dad a screwdriver. Dad will immediately note the error, teach Junior what a hammer is (preventing the error from being repeated!), and get his hands on a hammer. [↩]
11. An example of an issue undetectable by the receiving team, let’s go back to the Honda assembly line. If my job is to install the radio, I’m probably not also testing the radio. If the radio doesn’t work, it might not get noticed until final quality control—or until the finished car ends up on the dealer’s lot with a prospective buyer ready for a test drive. [↩]
12. The expensive oversight systems might be worth it. Factories are a classic example: the quality control and oversight processes involve a large investment, but keeping defect rates and manufacturing expense under control is worth significantly more. That cost/benefit calculation does not always come out in favor of oversight. [↩]
13. A model in which the “sender” gives the broad overview of the task, followed by the “receiver” delivering a briefing on their understanding. This allows quick discovery of misunderstanding and iteration to fill in gaps. It requires a high degree of psychological safety and is best with tasks that are not enormously detailed, or even simply enormous. [↩]
14. Getting started satisfies a manager wanting to “show progress” or insisting “we need to get this moving so they’ll know we’re working on this”. The results of rushing to get started are often every bit as beneficial as asking a sprinter to stand still until the baton has been handed off “just so we can get that checked off a bit sooner”. [↩]
15. Saving resources (often money or time) does not gain you much if you don’t accomplish your goal. If I understaff a project team to save money, and the project fails, I’ve likely wasted far more money than I “saved”. [↩]
16. Risks should be recognized, planned for, monitored, and not feared. If the cost of avoiding or mitigating a risk will cause the project (or the company!) to fail, that risk should be accepted and monitored. But it also sounds like a doozy of a risk. [↩]
17. and things that are easy to see, well, are easy to see the results of attempted improvements. [↩]
18. This is called the principle of suboptimization. As a quick example, imagine a car in which the radiator was optimized at the expense of the rest of the system. You’d have an enormous radiator, so your car would handle heat great, but the overall vehicle would be a terrible car—unbalanced because of the radiator, reduced space for an engine so it might be underpowered, lousy vision because of the enormous radiator up front… [↩]
19. But what if the current work item is less important than the next task? Common question. I can’t give you the right answer for your circumstances, but I can offer you a better question. It sounds to me like you’re asking “what if a work item in process is (relatively) unimportant and is taking resources away from a thing that’s important?” [↩]
20. For more on this, the Theory of Constraints (read The Goal by Goldratt). [↩]
21. For the sake of this example, I’ll go with the very common (and wrong) management approach of “if you’re not ‘working on something’, you’re not being utilized”. That would translate to basketball as “if you’re not handling the ball, preferably shooting, you’re not being utilized”. Given that there’s only one ball, the efficiency argument would suggest putting only a single player on the court at once. Or asking anyone not actively engaged in the play to do something else (cheerlead? fill water bottles?). Let me know how that works out for you, coach. [↩]
22. A “slam dunk”, if you will. [↩]
23. “They also serve who only stand and wait.” [↩]
24. Cross-functional delivery teams have costs, too. They need a psychologically safe organization. The right disciplines need to be represented on the team. Boundaries need to be drawn between the cross-functional team and other functions that are “just dependencies”. [↩]