Two subs on the same job, both assuming the other is handling the window flashing. Nobody checked. The client calls three weeks later. The flashing was never done, and nobody knows who agreed to do it.

Multi-sub coordination failures are not communication failures. They are documentation failures. A conversation that assigns the window flashing to the plumber is worthless if the electrician is also on site and never knew the boundary. Documented agreements are what make the boundary visible to every sub on the job.

The parallel also runs to job handoffs. When the owner hands a job to a lead, the lead needs to know not just the status but who owns what among the subs. The Three-Part Handoff Package carries that responsibility map. But the map has to exist before the handoff can carry it.

The Multi-Sub Responsibility Map is created before the first sub mobilizes. It names every scope item, the sub who owns it, and the sequence dependencies between them. When something goes wrong, the map is what answers the question.

Why Multi-Sub Jobs Produce Scope Gaps

The obvious problem is assumption. Each sub assumes the adjacent work is someone else’s problem. The flashings, the penetration seals, the coordination at transitions between mechanical and structural. Nobody assigned these items explicitly, so they belong to whoever first realizes they haven’t been done.

The less visible cost is timing. The scope gap discovered on day twelve is expensive: materials to order, a sub returning at return-trip rates, and a client timeline affected. The same gap caught in the responsibility map before day one costs a thirty-minute conversation.

The deepest cost is the relationship. Two parties with contradictory memories cannot resolve a scope dispute fairly without a document that was never made.

The Multi-Sub Responsibility Map

The Multi-Sub Responsibility Map is a single document with three layers. It takes thirty to forty-five minutes to build on a job with two or three subs. It takes less than ten minutes to update when something changes.

Component 1 assigns every scope item to a named sub before mobilization

Component 1 is a complete scope list with each item assigned to a named sub. Not general categories. Specific items.

Instead of “Framing: Sub A,” the map reads “Exterior sheathing: Sub A; window rough openings: Sub A; window flashing: Sub A.” Each item that could be claimed by more than one sub gets a specific name against it.

This takes longer than a verbal assignment. It also produces an assignment that is visible to every sub on the job. Any sub who sees the map knows what they own and what the adjacent sub owns.

Component 2 documents the handoffs that create sequencing dependencies

Component 2 is the sequence: what Sub A must complete before Sub B can start a dependent phase.

Multi-sub coordination failures often happen at sequencing transitions. Sub B cannot start electrical rough-in until Sub A completes rough framing in the same zone. Sub C cannot hang drywall until Sub B completes electrical and Sub D completes mechanical. Component 2 makes these dependencies explicit before anyone is on site.

Before: Sub B arrives and discovers the north zone framing is incomplete, rearranging scheduling at day-of cost. After: The handoff requirement is documented and the sequence tracked against the map before either sub arrives.

Component 3 updates the map when scope or sequence changes during the job

Component 3 is the living update. When the scope changes, the map changes. When the sequence shifts, the map shifts. Every change to the map is dated and noted.

A map that reflects the original plan is only half a document if the plan has changed. Component 3 is what keeps the map current rather than archival.

How the Conductor Maps Your Sub Responsibilities

Two weeks into a three-sub renovation, the owner is off-site. The lead asks who is responsible for the rough mechanical coordination in the kitchen zone.

The Living Library is the platform’s active working layer. It holds the responsibility map built before the job started and updated as scope has changed. The Conductor draws from that record. It identifies the responsible sub, the handoff point that needed to complete first, and the current status against the map.

The lead gets a specific answer, not “check with the owner.” The Sub A framing closed on Tuesday, so Sub C mechanical can enter the kitchen zone Wednesday. The coordination question is answered from the map, not from a call.

Build the Map Before the First Sub Calls to Confirm Their Start Date

Don’t build the map at the job start meeting. Build it before.

When the last sub confirms their schedule, the responsibility map should already exist. Name each sub, list what they own, and note what must be complete before each handoff. Email the map to all three subs before anyone arrives.

The map sets the boundary before the boundary is tested. The conversation that happens at the job start meeting uses the map as a reference, not as a starting point.

If Two Subs Disagreed About Who Owned the Flashing, What Would You Look At?

If the map existed, you would look at the map. If the map didn’t exist, you would spend three days trying to reconstruct a conversation that both parties remember differently. The Multi-Sub Responsibility Map is what answers that question before it has to be asked. Try Kiluma free for 14 days at kiluma.ai.