The Handoff Is Part of the System

A few days ago, I gave my students a presentation assignment.

They had visited an art gallery in pairs, discussed what they noticed and how they interpreted the artwork, and now had four questions to answer about their partner's perspective.

Several students seemed surprised when they realized they had only four days to prepare for the presentation.

My first thought could have been: “Four days should be enough.”

But their reaction made me reconsider the assignment.

The purpose of the assignment was reflection. I wanted students to think carefully about:

I wasn't particularly interested in slides. I wasn't expecting an elaborate production. They didn't even need to meet with their partner again. The difficult work was supposed to be thinking.

But I hadn't made all of that explicit.

I designed the assignment with one understanding of “presentation.” Students received it with their own. For some of them, presentation may have implied: meet again → coordinate → create slides → organize content → rehearse → present.

Suddenly four days doesn't sound like much time. The problem wasn't necessarily the deadline. The problem was the handoff between my intention and their interpretation.

So I sent a clarification:

Use your experiences to help you think about handoffs. That experience made me think differently about handoffs.

Organizations divide work for good reasons.

One person investigates. Another decides. Another communicates. Another implements. Another evaluates.

But every time work moves from one person or function to another, something has to travel with it: information, context, responsibility, expectations, constraints, decisions.

And what leaves one person isn't necessarily what arrives for the next.

A strategist hands a recommendation to a manager. A manager hands instructions to an employee. Sales hands a client to operations. A professor hands an assignment to a student. An advisor refers a student to another office.

The work can be excellent on both sides and still fail between them.

The person sending the work has context the receiver doesn't have.

That's easy to forget. I've spent hours thinking about an assignment before students encounter it. I've considered the purpose, sequence, learning outcomes and relationship to previous classes.

Then I compress all of that into a few instructions. The student receives the compressed version.

If I've removed context they needed to act, they have to reconstruct it themselves. Sometimes they reconstruct it differently than I expected. That's not always a failure of attention. It may be a failure of translation.

When something isn't working across a team or system, we often investigate the people or functions separately.

Did the first team do its job? Did the second team do its job?

But another useful question is: What happened when the work moved between them?

What did the sender assume? What did the receiver understand? What context disappeared? What was ambiguous? Who was supposed to confirm that the handoff worked?

Sometimes the problem isn't located inside either function. The problem lives at the boundary.

Think about a piece of work that regularly moves between people in your organization.

Map one handoff:

Who sends it?

What do they think they're sending?

Who receives it?

What does the receiver need in order to act?

How do you know that's what actually arrived?

That last question is the one I'm becoming increasingly interested in. My students' surprise was information.

It told me something about what had—and hadn't—travelled successfully through the system I designed.

The response wasn't necessarily to give them more information. It was to identify the unnecessary work they thought I was asking them to do and remove it.

Sometimes improving a handoff means adding context. Sometimes it means removing complexity.

Either way, the handoff itself deserves to be designed.

Next time, I'll look at another constraint that makes priorities and coordination real: Where do the resources go?

— Greg K. Campbell