The Exchange Zone

Handoffs are everywhere on a building project.

Between planners, architects, engineers, contractors and trades.

Between senior and junior people.

Between colleagues.

Information is constantly moving from one person to another.

Yet we spend enormous effort improving the work and surprisingly little improving the transfer of the work.

Track and field teams do.

In a 4×100 metre relay, the baton is transferred inside an exchange zone.

At the Olympic level, teams deliberately practise these exchanges because having four incredibly fast runners isn't enough.

The objective isn't simply to pass the baton

It's to pass the baton without slowing things down.

And that requires both runners.

The upstream runner needs to arrive at speed, ready to make a reliable transfer.

The downstream runner needs to anticipate the handoff, accelerate before it arrives, and be ready to receive it without breaking stride.

That second part is easy to miss.

The receiving runner doesn't stand still waiting for the other runner to finish.

They start running before they have the baton.

For a period, both runners are running together. Their work overlaps.

That's not inefficiency. That's what makes the handoff fast.

Building projects have exchange zones too.

We often imagine work as a clean sequence:

Architect starts → Engineer starts → Contractor starts → Trade starts.

But our best collaborative work rarely happens that way.

The structural engineer might start exploring framing before every architectural decision is complete.

The contractor might start thinking about sequencing while the design is still developing.

A trade partner might provide fabrication or constructability input before the engineer has finished the details.

For a period, two people are running with the same problem.

That's the exchange zone.

And a good exchange requires something from both sides.

The downstream person helps define the handoff:

What do I need?

When do I need it?

What does "ready" actually look like?

The upstream person can then reliably commit to delivering it.

But just as importantly, the downstream person doesn't sit still waiting for everything to be perfect.

They're already accelerating.

Working with what they know.

Testing assumptions.

Preparing to receive what's coming next.

The upstream person can't simply say:

"I sent it."

And the downstream person can't simply say:

"I'm waiting for it."

For a period, responsibility overlaps too.

Information moves back and forth.

Questions get answered.

Assumptions get tested.

Partial decisions allow the next person to begin moving while the remaining pieces are still being resolved.

Then, when the baton is finally transferred, the next person is already moving.

That's one of the ideas behind pull planning and collaborative delivery.

We don't just ask:

"When can this be finished?"

We ask:

"When does the next person need to start?"

That changes how we plan the work.

Instead of treating each task as something to complete in isolation, we work backward from what the next person needs and when they need it.

And sometimes, that means our work overlaps.

Not because the process is inefficient, but because the handoff has been designed to keep the project moving.