How should a distributed team handle work that depends on another team?
Quick answer
Name the specific work your team needs from the other team, who will provide it, and when it is needed to keep your own work on track. Send a concise request with the purpose, expected output, owner, and proposed response date. Agree on a check-in and a fallback if timing slips, such as resequencing work or raising the trade-off with relevant leads. Record decisions where both teams can find them.
The question, the details, the next step.
How should a distributed team handle work that depends on another team?
Treat the dependency as a small piece of planned work, not as a vague hope that someone will respond. Identify what your team needs, who on the other team can own or route the request, when you need the result, and what your team can do while waiting. Then make the request and its timing visible in a place both teams can access.
For example, suppose your team cannot prepare a launch note until another team confirms a feature name. The dependency is the confirmed name—not “help with launch.” Your team can record that input as a separate item, name a contact or team owner, and show which part of your work depends on it. That gives both teams something concrete to discuss and makes a delay easier to spot.
What should I include in the request so the other team knows exactly what we need?
Keep it brief, but include enough context to make the request actionable: the output you need, why it matters to your work, the person or role you believe should own it, and a proposed date for the response. State any format or decision needed, and ask the recipient to confirm ownership and timing—or suggest the right contact if you have reached the wrong person. Avoid implying that a proposed date is already agreed.
Copyable example:
“Hi [name/team] — We’re preparing [deliverable] and need [specific input or decision] to complete [dependent task]. Could you confirm who owns this and whether you can provide [output/format] by [date]? That timing would let us [next step]. If that date does not work, please suggest a realistic date or an alternative route. We’ll check in on [check-in date]. Thanks, [your name/role].”
For the feature-name example, ask for the approved name and who can confirm it; don’t ask broadly for “launch feedback.”
How do we agree on timing when the other team has its own priorities?
Explain the sequence, not just your preferred deadline: when you need the input, what work follows it, and what becomes harder if it arrives later. Ask the other team to confirm a date they can meet. If your dates do not fit, discuss options together—for example, a smaller first response, a different order of work, or an updated delivery date. Do not silently treat a request as accepted just because you sent it.
Record the agreed owner, output, date, and next check-in in the shared project space or another agreed channel. If the date is still tentative, label it as tentative. In the launch-note example, the teams might agree that the other team will confirm the name by [date], with a check-in on [earlier date]. Your team can then distinguish a confirmed commitment from a date that still needs agreement.
What should we do if the agreed response is late?
Use the fallback you agreed on rather than letting the dependency disappear into chat. At the check-in, ask for a revised date and whether the requested output or owner has changed. Update the visible plan, including which downstream task is affected. Then decide with the relevant teams whether to wait, do independent work first, reduce or change the dependent work, or raise the schedule trade-off to the people who can resolve it.
For example, if the approved feature name is not ready, your team might continue drafting sections that do not use it, while marking the naming-dependent section as blocked. Do not publish a placeholder as if it were confirmed. If no revised date or owner is clear, ask the project leads to help decide the next step; make the impact and options explicit rather than assigning blame.
A practical checklist
Write the dependency as a specific input, decision, or deliverable.
Identify an owner, or ask the recipient to route the request to one.
Explain what depends on the output and propose a needed-by date.
Confirm the response date, check-in, and where the agreement will be recorded.
Agree on next steps if timing slips, including who can decide trade-offs.
Update the shared plan when an agreement or date changes.
A few more useful answers
Should I mark a dependency as confirmed when I have only sent the request?
No. Track it as requested until the other team confirms an owner and timing. That distinction helps your team plan around uncertainty.
What if we do not know which person on the other team owns the work?
Send the request to the most relevant team contact or shared channel you have, and explicitly ask them to identify or route it to the right owner. Keep ownership unresolved in your plan until someone confirms it.
How can we keep work moving while waiting?
List the tasks that do not require the missing input and proceed with those where practical. Mark dependent work clearly so a placeholder or assumption is not mistaken for an agreed result.