A project can sit still for days even when everyone involved is responsive. One team believes it sent what was needed. Another is waiting for a decision, access, approval, or a more usable version of that same material. Meanwhile, follow-up messages become vaguer: “Any update here?” “Checking in.” “Let us know if you need anything.”
The problem is often not effort. It is an unspoken gap in ownership. A short, neutral ownership-reset note can turn that fog into a next action without assigning blame or turning a routine handoff into a public dispute.
Recognize the difference between a delay and an ownership gap
A normal delay has a known owner and an expected next action: someone is preparing the file, reviewing a draft, or waiting for a scheduled meeting. You may need patience or a deadline adjustment, but the path is clear.
An ownership gap sounds different. You hear phrases such as:
- “We thought your team was handling that part.”
- “We can proceed once the requirements are confirmed.”
- “That needs to come from the business side.”
- “We shared the information already.”
- “I’m not sure who has approval authority.”
These statements may all be reasonable from the speaker’s perspective. But none identifies one person or team who will produce one concrete thing by a particular point. Repeated reminders will not fix that. The work needs a visible seam: what crosses from one team to another, who sends it, who accepts it, and what “complete” means.
When a handoff stalls, do not ask only for status. Ask the group to agree on the smallest next piece of work and its owner.
Prepare four facts before you send anything
Do a brief private check first. The goal is to describe the situation accurately enough that people can correct it easily. Avoid reconstructing every past message unless a record is genuinely necessary.
1. Name the deliverable, not the broad project
“Launch support” is too large. “Approved customer email copy,” “a list of fields for the intake form,” or “confirmation that the data export includes account IDs” gives the conversation something tangible to hold.
2. State the exact condition that is missing
Be specific about what prevents movement. Examples include a named approver, a source of record, access to a system, acceptance criteria, or a decision between two options. “More information” is not yet useful; “confirmation of which customer segment receives version A” is.
3. Separate known facts from assumptions
Write down what has actually happened: “Operations sent a draft on Tuesday” or “Engineering said the format needs a field list.” Then identify the assumption: “We may be waiting for Product to choose the required fields.” This keeps your note from presenting a guess as a failure by someone else.
4. Offer a workable default
A stalled group is more likely to respond when it can react to a proposal. Your default does not have to be perfect. It might be: “Product confirms the field list; Engineering validates feasibility; Operations supplies the sample file.”
Choose a default that follows the work, not the org chart. The team closest to the business rule may own the rule; the team that maintains a system may own technical validation; the team that uses the output may own acceptance.
Send an ownership-reset note that is easy to answer
The most useful message is short enough to read in one pass and structured enough to produce a decision. Include the relevant people, but do not widen the audience merely to create pressure. A large audience often makes ownership less clear, not more.
Use this sequence:
- Shared goal: Say what the group is trying to move forward.
- Current blocker: Describe the missing input or decision in plain language.
- Proposed split: Assign the next small actions by role or team.
- Confirmation request: Ask people to confirm or correct the split.
- Checkpoint: Set a reasonable point to resolve the question or meet briefly.
Here is a reusable example:
To move the onboarding form into build, we still need the final list of required fields and confirmation of who approves future changes. My understanding is that Product can confirm the field list, Engineering can flag any constraints, and Support can confirm that the submitted information is usable for follow-up. If that split is not right, could the appropriate owner be named? If it is right, can we confirm the field list by Thursday and use it as the build input?
This works because it does not say, “You failed to do your job.” It says, “Here is the work that remains, here is a plausible route, and here is a simple moment to correct the route.”
Make ownership concrete without becoming controlling
“Product owns it” can still leave a project stuck if five people are loosely associated with Product. For the immediate step, ask for a single accountable contact. That person does not need to do all the work; they need to coordinate the answer and make sure it returns to the group.
A useful handoff has four parts:
- Sender: who prepares or provides the input.
- Receiver: who uses, reviews, or accepts it.
- Definition of ready: what must be included for the receiver to act.
- Return path: what happens if the input is incomplete or changes are needed.
For example, a marketing team may send web copy to a web team. “Ready” could mean the copy is final, includes a page location and intended audience, has required approvals, and is supplied in the team’s agreed format. If any of those elements are missing, the web team returns the request with one specific question instead of silently parking it.
This is not unnecessary process. It reduces the hidden interpretation work that otherwise lands on the receiver.
Use a short live conversation only when the written path cannot resolve it
A written reset is usually best for simple ownership questions because it creates a shared record and gives people time to check assumptions. Move to a short call when the group is choosing between genuinely competing priorities, when different teams use the same words to mean different things, or when the issue has already generated a confusing thread.
Keep that call narrow. Open with the disputed handoff, not the entire project history. A useful agenda is:
- What output is needed next?
- What must be true for it to be usable?
- Who coordinates each remaining action?
- What is the next checkpoint?
End by posting the result in the project’s normal workspace or thread. A verbal agreement that lives only in attendees’ memories often recreates the same problem when someone is absent or priorities shift.
Common approaches that make the gap worse
Sending a vague chase message
“Just following up” is appropriate when a named person has a clear commitment. It is weak when the group has not agreed on who should act. You may receive another polite acknowledgement without any movement.
Copying senior people before defining the question
Escalation can be necessary, especially where a decision has material consequences or teams cannot resolve a priority conflict. But escalating an undefined problem tends to produce a meeting, not an answer. First show the deliverable, the missing decision, and the reasonable options.
Assigning responsibility as if it were proven
“Finance has not provided the approval” may be inaccurate if Finance is waiting for a cost center from another group. Prefer language such as “The approval is still pending; my current understanding is that it needs a cost-center confirmation first.” This invites correction and protects trust.
Trying to settle every future responsibility at once
Sometimes a stalled handoff exposes a broader process weakness. Fix the immediate next step first. Afterward, decide whether the recurring process needs a standing owner, intake template, or decision rule. Combining both conversations can overwhelm an urgent issue.
A realistic example: the report nobody can finish
Imagine a monthly customer report that requires data from Analytics, commentary from Customer Success, and a final review from Leadership. Analytics has delivered numbers, but Customer Success says it cannot write useful commentary without knowing which accounts Leadership wants emphasized. Leadership assumes Customer Success chooses the accounts based on the numbers.
A status request would only reveal that each group is waiting. An ownership reset could say:
For the monthly customer report, the remaining question is which accounts should receive commentary. Analytics has provided the account metrics. I propose that Customer Success recommends five accounts based on customer context, and Leadership confirms or adjusts that shortlist before commentary is drafted. If Leadership would prefer a different selection rule, please identify it; otherwise, can Customer Success send the shortlist for confirmation at the next checkpoint?
The proposal gives Customer Success permission to make the first judgment while preserving Leadership’s final choice. It also turns an abstract dispute about ownership into a small sequence that can start immediately.
Build a lighter handoff habit after the immediate issue is solved
You do not need a new project-management system to prevent every ownership gap. At the start of any cross-team task, add four lines to the request or project note:
- Output: what will be delivered.
- Owner for the next action: one named contact or clear team role.
- Ready means: the minimum acceptance criteria.
- Question path: where incomplete work or changes should go.
Use this especially for work that recurs, passes through several teams, or arrives through informal channels. It is much easier to clarify a seam at the beginning than to locate it after a deadline is threatened.
Your next action
Choose one task that has been described as “waiting on another team.” Write one sentence naming the exact missing output. Then draft a three-sentence ownership-reset note: the blocker, a proposed owner for the next small action, and a request to confirm or correct it. Send it to the smallest useful group rather than adding another vague follow-up to the thread.
Ad