Keep It Moving: Handoffs, Dependencies, and Clearing Blockers

Making the work visible, as you did in the last chapter, tells the group where everything stands. But a clear picture is not the same as forward motion. Once the effort is live, work has to pass cleanly from one person to the next, waiting tasks have to be freed in the right order, and the inevitable snags have to be cleared before they quietly stall everyone. This chapter is about keeping a coordinated effort actually moving while it runs.

Manage Handoffs So Work Actually Lands

Picture a volunteer finishing their part of a group task, messaging “done!”, and moving on, only for the next person to open the file and find they cannot use it: a name is missing, the format is wrong, half the information lives in someone’s head. The work was “done” for the sender, but it did not land for the receiver. That gap is where a handoff goes wrong.

A handoff is the moment a piece of work passes from the person who was doing it to the next person who needs it. It is one of the most common places a group effort loses time, because it is easy to confuse finishing your part with handing it over well. They are not the same thing.

The test of a clean handoff is simple: the output is usable by the receiver, not just “done” for the sender. The receiver should be able to pick it up and keep going without coming back to ask what was meant, where something is, or what to do next. A clean handoff usually carries three things: the finished work itself, whatever the receiver needs to use it (a file location, a decision, a short note), and a clear signal that it is now theirs. When those are present, the work lands; when they are missing, the receiver stalls and the sender does not even know it.

Track Dependencies During Execution

Back in the foundation chapter you built a dependency map, a simple table of what depends on what. That map was a plan. Once the work is live, the same relationships stop being a diagram and start being real: a task is genuinely waiting on another, and someone has to watch those links as they play out.

Tracking dependencies during execution means keeping an eye on which finished task frees which waiting task. When a predecessor (the task that had to finish first) lands, its successor (the task that was waiting on it) can start, and the person who owns that successor should know right away. This is exactly what the blocked state on your tracker is for: a task sitting in “blocked” is telling you a dependency has not been met yet. Read together, your tracker and your dependency map show you the chains, the sequences where one task feeds the next feeds the next.

The skill is spotting a chain that is about to stall before it does. If the task at the front of a chain slips, every task behind it is at risk, even if those later tasks look fine right now. A group that watches its dependencies notices this early (“if the design is not done by Thursday, printing cannot start Friday, and pickup is Saturday”) and acts while there is still room to move. A group that does not watch them discovers the problem only when the successor’s owner sits down to work and finds they cannot start.

Surface Blockers Early and Give Each One an Owner

Every live effort hits snags. A blocker is anything that stops a task from moving forward: a missing decision, a late delivery, a dependency that has not landed, a tool that will not work. Blockers are normal. What separates a coordinated group from a stuck one is not having fewer blockers, it is how they handle the ones they get.

Two moves make the difference. The first is to surface the blocker early. The moment a task cannot move, the person on it says so, out loud and on the tracker, rather than waiting quietly and hoping it resolves. Early surfacing beats late discovery every time, because a blocker raised on Monday has all week to be solved, while the same blocker discovered on Friday has run out of room.

The second move is to give the blocker an owner: one named person responsible for clearing it. This is the step groups most often skip. A blocker that “everyone knows about” but no one owns tends to sit exactly where it is, because each person assumes someone else is handling it. The owner of a blocker is not always the person stuck behind it; often it is whoever is best placed to unblock it. Naming that person turns a shared complaint into an assigned task with a clear next step.

A Handoff and a Blocker, Handled

Let us watch both moves in action. An amateur theater group is setting up the technical side of a small production: lighting, sound, and set changes, run by a handful of volunteers over the final week of rehearsals.

First, a handoff. The director finalizes the lighting cues and needs to hand them to Nadia, who runs the lighting board. A weak handoff would be the director saying “the cues are basically decided” and leaving it there. Instead, the director writes the cues into the single shared sheet Nadia already uses, notes which scene each cue belongs to, flags the two cues that changed since yesterday, and messages: “Lighting cues are final and in the sheet, the two changes are highlighted, it is yours now.” Nadia opens it and can program the board immediately, without a single follow-up question. The work landed.

Now a blocker. Mid-week, the group realizes the rented sound board has not arrived and the supplier is not answering. The task “program the sound cues” is stuck. Rather than let it sit, Priya, who spotted it, marks the task blocked on the tracker the same afternoon and raises it at the evening check-in. The group gives the blocker a clear owner: Theo, who knows the rental company, will chase the delivery first thing tomorrow and, if it cannot arrive in time, borrow a board from a nearby venue. Because the blocker was surfaced early and given an owner, the sound cues are back on track two days before the show, instead of surfacing as a disaster on opening night.

Common Beginner Trap

Your Turn! Run a Handoff and Clear a Blocker

Now you handle a live effort of your own.

Context. A crew of volunteers is putting on a charity 5K run for a local cause. It is the week of the event. The route still needs its final permit from the town, and until that permit is confirmed, two things cannot happen: the signage team cannot print the course markers, because they need the confirmed route, and the volunteer briefing cannot be finalized, because volunteers need to know where they will be posted. Right now the permit task is stuck, no one is clearly chasing it, and the group chat keeps saying “hopefully it comes through.”

Your task. Get this moving in two pieces:

• Clear the blocker: name the blocker plainly, and give it a single owner, saying who will chase the permit, by when, and what their backup move is if it does not come through in time ;

• Define a clean handoff: once the permit is confirmed, describe the handoff from the permit owner to the signage team, listing exactly what the signage team needs to receive so they can start printing immediately, with no follow-up questions.

Deliverable. A few sentences: the named blocker with its owner and deadline, plus a short description of what a clean handoff to the signage team includes.

Then check your answer against the model solution found at the end of this chapter.

Let's Recap!

• A handoff is clean only when the output is usable by the receiver, not just finished for the sender ;

• Tracking dependencies during execution means watching which finished task frees which waiting one, and spotting a chain before it stalls ;

• A blocker is anything stopping a task from moving forward, and every effort will have some ;

• Two moves clear blockers: surface them early, and give each one a single named owner ;

• A blocker everyone sees but no one owns is the one most likely to sink the effort.

You can now keep a live effort moving through clean handoffs and cleared blockers. The final chapter handles what happens when reality changes the plan anyway, and walks through one fully worked example that runs the whole method from shared goal to delivery.

Model Solution

Here is one solid way to handle the charity 5K. Yours will differ in the details; check that it does the same two jobs.

Clearing the blocker. The blocker is plain: the course permit is not yet confirmed, and it is blocking both the signage and the volunteer briefing. Give it one owner: Dana will call the town permit office first thing tomorrow morning and get a yes or no by noon. Her backup move, agreed in advance, is that if the permit cannot be confirmed by tomorrow afternoon, she switches the run to the pre-approved park loop the group already holds a standing permit for, so the event happens either way. The blocker now has a name, an owner, a deadline, and a fallback, instead of a group chat hoping.

The clean handoff. Once the route is confirmed, Dana hands off to the signage team so they can print without coming back. A clean handoff here means she sends them the final confirmed route (the exact streets or the park loop), the number and placement of the course markers, and a clear “this is final, start printing” signal, all in the shared place the signage team already uses. With that, the signage team can begin immediately, and the volunteer briefing owner can post people along a route that is now certain.

If you named the blocker, gave it one owner with a deadline and a backup, and described a handoff the signage team could act on with no follow-up questions, you have practiced the two moves that keep a live effort moving.