How do I identify work that could fall between teams during a transfer?
Quick answer
List the work that will move, then trace what happens before, during, and after each handoff. For every task, record who currently does it, who is expected to own it after the transfer, who depends on it, and what happens when it is missed or delayed. Mark tasks with no named owner, conflicting assumptions, or an unconfirmed handoff as gaps to resolve with the teams involved.
The question, the details, the next step.
We’re transferring a set of responsibilities between teams. How do I spot the work that might get missed?
Look beyond the headline responsibilities and follow the work through its full path. A task can appear to belong to one team while a related request, check, update, or follow-up is handled informally by another.
Start with three kinds of work:
- Recurring tasks: regular reports, reviews, updates, or requests.
- Dependencies: information or decisions one team needs from another to proceed.
- Exceptions and follow-ups: incomplete requests, unusual cases, corrections, and work that continues after a handoff.
For each item, ask: Who notices that it needs doing? Who does it now? Who is expected to do it after the transfer? Who receives the result? What happens if it is late or not done? A missing, vague, or disputed answer is a signal to clarify ownership—not proof that someone has failed.
How can I map shared responsibilities without making the discussion about blaming one team?
Describe the work as a sequence of steps rather than assigning fault. Use neutral language such as “the request arrives,” “the details are checked,” and “the result is sent.” Then invite both teams to confirm who performs each step today and what they expect after the transfer.
Make a simple ownership-gap map with one row per task or handoff:
- Task or trigger: what starts the work?
- Current owner: who handles it now, if known?
- Expected owner after transfer: who is expected to take it?
- Dependencies and recipient: what does it need, and who uses the result?
- Gap or uncertainty: what is not agreed or confirmed?
- Next clarification: who can settle the question, and by when?
Use labels like “confirmed,” “unclear,” or “not discussed.” Keep assumptions visible instead of quietly turning them into decisions.
Could you show me what one row might look like?
Here is a hypothetical example; replace the bracketed roles and task with your situation:
Task or trigger: A recurring status update is due when [period ends]. Current owner: [Team A] prepares it; [Team B] supplies one input. Expected owner after transfer: [Team C] is expected to coordinate it, but this is unconfirmed. Dependencies and recipient: The update needs [input] and goes to [recipient or role]. Gap or uncertainty: No one has confirmed who requests the input or checks that it arrived. Next clarification: [Teams A, B, and C] agree who requests, prepares, reviews, and sends the update, and record the decision in [shared handoff document].
The useful finding is not simply “Team C owns the update.” It is that requesting an input and checking its arrival are separate steps that could be left unassigned. Confirm the proposed owner and timing with the people responsible; the map itself does not establish agreement.
What should we do with gaps we find before the transfer is complete?
Sort the gaps by what needs a decision and what needs a documented handoff. For each unclear item, name the question, the people who need to agree, and a follow-up point. For example: “Who checks for unfinished [request type] on the transfer date, and where will that status be recorded?”
Before treating a row as settled, ask both sides to confirm the owner, the trigger for action, the expected output, and the route for exceptions or unfinished work. If ownership cannot be agreed in the transfer discussion, mark it as unresolved and identify the appropriate decision-maker rather than assigning it by assumption. Keep the map current as decisions are made, so unresolved items remain visible instead of blending into the general transfer plan.
A practical checklist
List recurring tasks, dependencies, exceptions, and follow-ups—not only formal responsibilities.
Trace each item from its trigger through its output and recipient.
Record current and expected owners separately; mark assumptions as unconfirmed.
Flag steps with no named owner, conflicting expectations, or unclear escalation.
Ask the relevant teams to confirm decisions and record unresolved questions with a next step.
A few more useful answers
Should every task in the transfer have just one owner?
Not necessarily. A task may involve several teams, but the map should make each team's part clear and identify who coordinates the handoff or follows up when a step is incomplete.
What if nobody knows who currently handles a task?
Mark the current owner as unknown and ask the people closest to the task how it is triggered, completed, and passed on. Keep the uncertainty visible until it is checked rather than guessing.
When is a possible ownership gap resolved?
When the relevant people confirm who handles the step, what starts it, what result is expected, and how exceptions or unfinished work are handled. Record the agreement so the map reflects the decision.