In this article
Before you start
This page sits in the behavioral interview questions guide. If you have not met the answer format yet, read how to answer a teamwork question with the STAR method first.
Why interviewers ask this
The question separates people who wait for other teams from people who manage the work around them. Most real projects need input from someone outside your reporting line, so the answer shows how you behave without authority.
Guidance on structured interviews from the US Office of Personnel Management (OPM) describes an answer as the situation or task, the action, and the result. A weak answer here is a complaint about another team. A strong answer shows you named the dependency early, kept a clear owner and date, and acted when it slipped. A Staff-level answer also asks whether the dependency should exist at all.
Dependencies on other teams from first principles
- Cross-team dependency
- A cross-team dependency is a case where one team's work relies on input, a decision, an approval, access or a deliverable that another team controls. The team that needs it is the requester and the team that supplies it is the provider, so the requester cannot finish on its own schedule.
- Escalation path
- An escalation path is the agreed route for raising a blocked or slipping item to someone with authority over both sides, such as two managers. It names who decides, by when, and what options they are given, so a delay becomes a decision instead of a silent wait.
In plain words
Think of baking a cake for a party. A friend promised to bring the eggs. You cannot finish without them. You do not control your friend's day. You can ask when they will arrive. You can write it down. You can prepare a plan if they are late. The analogy breaks in one place. At work the friend has their own manager and priorities. A plan B often needs a third person to agree.
In one precise sentence, the interview question tests whether you made a cross-team dependency visible, owned your side of it, and reached a result without blaming the provider.
Step 1: Name the dependency and its owner
Name the dependency and its owner first. State what you needed, from which team, and who on that team owned it. This is the Situation and Task of your story.
A practitioner guide says a dependency should have a clear requester, provider, owner, due date, decision rule, status, risk level and escalation path (Workhint). That is a vendor blog, so treat it as supporting practice, not a standard. In an answer you only need a few of these: what, who, and by when.
Input: your project goal. Output: one sentence such as "we needed the other team's interface by the middle of the quarter." You now know the setup of the story. Step 2 shows what you did next.
Step 2: Make the dependency visible with a date and status
Make the dependency visible with a due date and a status. The Scaled Agile Framework (SAFe) describes a planning board that shows feature delivery dates and feature dependencies among teams, and lists that board as an output of its planning event. You do not need that framework to tell the story. You need to say where the dependency was written down and who agreed to the date.
Input: the named dependency. Output: a shared record with a date, an owner and a status that both teams could see. This is the first part of your Action, and it shows initiative before anything went wrong. Interviewers can then hear that the later steps were planned, not improvised.
Step 3: Keep the story on your own action
When the provider slips, keep the story on your own action. The sentence "they were late, so we were late" makes the other team the plot and gives the interviewer nothing to assess. The sentence "they slipped, so I took two options to my manager" makes you the plot.
The MIT career office advises describing the actions you personally took. Amazon's published principles say leaders listen attentively, speak candidly and treat others respectfully, which is a good tone for talking about a team you did not control; the Amazon Leadership Principles page explains the rest. Escalate with options and a recommendation, not a complaint. Input: a slipped date. Output: a decision by someone who can make it.
Step 4: Close with a result and what you changed
Close with a result and what you changed. Say what happened to the launch, the quality or the relationship, then one thing you changed afterward so the next dependency goes better, such as an earlier check-in date.
Result is the shortest part of the story, but it is the part that proves the Action worked. Add a lesson only if it is specific. You have now seen the whole shape: name it, make it visible, own your action, close the loop.
Step-by-step description
- Name the dependency and its owner.
- Give it a date and a status.
- Escalate with options, not blame.
- Give the result and what changed.
- Name the dependency and its owner first.
- Make the dependency visible with a due date and status.
- Escalate with options and keep the story on your own action.
- Close with a result and what you changed.
The figure repeats the four steps. Name the dependency and its owner first. Make the dependency visible with a due date and status. Escalate with options and keep the story on your own action. Close with a result and what you changed.
Which kind of dependency is it?
Project-management guidance classifies dependencies along two separate axes: mandatory versus discretionary, and internal versus external (a project-management reference summarizing the Project Management Body of Knowledge (PMBOK)). A mandatory dependency is one forced by a physical limit or a contract or legal duty, and a discretionary dependency is one chosen from preferred practice (4SquareViews summary of PMBOK, 2013). External means outside your team's control. Because the axes are independent, a regulator's permit is both mandatory and external. Discretionary and internal dependencies are easier to change, so look there first when you want to remove one.
How long each part of the answer takes
The MIT career office suggests a split of 20% Situation, 10% Task, 60% Action and 10% Result. Other guides give different splits, so treat it as guidance, not a rule. For an answer of 90 seconds it works out as below.1
| Part | Share (MIT guidance) | Seconds in a 90-second answer | Seconds in a 60-second answer |
|---|---|---|---|
| Situation | 20% | 18 | 12 |
| Task | 10% | 9 | 6 |
| Action | 60% | 54 | 36 |
| Result | 10% | 9 | 6 |
Text description of the diagram
- Action takes the largest share, 54 seconds of a 90-second answer.
- Situation takes 18 seconds, Task 9 seconds and Result 9 seconds.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
Tell me about a time your work depended on another team.
Our checkout redesign depended on the payments team's new endpoint, and I did not control their roadmap. In week one I wrote the dependency down with their lead: what we needed, who owned it, the due date, and what we would do if it slipped. When their date slipped about three weeks, I did not wait.
I took two options to my manager: ship behind a flag on the old endpoint, or move the date. We chose the flag, I re-sequenced our own tasks, and we launched four days late instead of three weeks. Afterward I added an early dependency check to our planning. I also proposed to their lead that we own a thin adapter over their endpoint, so checkout releases no longer wait on theirs.
This is an illustrative example, and the figures are made up: the provider's date slipped 21 days and the launch moved 4 days, so 17 days of delay were absorbed.1 What makes it Staff-level is the last two moves: a process change, and a proposal that removes the dependency instead of only managing it. A 2021 post on the Scaled Agile blog says too much red yarn means too many dependencies on its board, and that the fix may be to restructure teams. Proposing a cleaner interface shows judgment beyond managing.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Ownership | Waited for the other team | Named the owner and date early | Agreed the date and a fallback with both teams |
| Action | Complained or blamed | Escalated with a clear request | Escalated with options and a recommendation |
| Result | Vague or negative | A clear outcome for the project | Outcome plus a change to the process |
| Depth | Only managed the delay | Re-sequenced own work | Asked whether the dependency should exist |
| Communication | Long setup, short action | Action is most of the answer | Calm tone toward the other team |
Three variants of this question
Tell me about a time you were blocked by another team.
The same story works. Lead with what you needed and how you unblocked it, and keep the focus on your action. See common interview questions for neighboring wording.
How do you manage dependencies across teams?
Answer as a process, then support it with the story: name each dependency, give it an owner and a date, review status regularly, and agree who to escalate to. An answer without a real example sounds theoretical.
What if the other team refuses or re-prioritizes?
Show disagreement without damage: ask for the reason, bring facts and options, and commit to the decision once it is made. Amazon's published principles describe challenging decisions respectfully even when uncomfortable (Amazon).
Common mistakes
- "The other team was disorganized and late." (wrong) It blames and shows nothing you did. (right) "Their date slipped, so I brought my manager two options."
- "I just kept following up." (wrong) Follow-up without a decision is waiting. (right) "I asked for a decision by Friday and gave the cost of each option."
- "There was no way to plan for it." (wrong) It shows no early mapping. (right) "We wrote the dependency down in week one with an owner and a date."
- "We delivered, so the story is done." (wrong) It has no Result detail. (right) "We launched four days late instead of three weeks, and I added a check-in to planning." The four days are illustrative.
Follow-up questions
What if you have no story with a dependency?
Use a project where you needed a review, data, access or an approval from another group. Smaller dependencies still show the same habits.
How do you say you reduced a dependency?
Say what you changed: a clearer interface, a self-service tool or a shared owner. Then say what that removed from the next plan. See how to answer interview questions for structuring that line.
How do you talk about people on the other team?
Describe their constraints neutrally and credit their help. The interpersonal communication page covers tone in more depth.
What would you ask the interviewer about this?
Ask how teams here track shared work and who decides when priorities collide; the questions to ask an interviewer page has more.
- Name the dependency, its owner and its date early.
- Make it visible in a shared record, not only in conversation.
- Keep the story on your own action and escalate with options.
- Spend most of the answer time on Action, and close with a result and a change.
- At Staff level, ask whether the dependency should exist.
Sources
- ART Planning Board - Scaled Agile Framework glossary — Scaled Agile, Inc., 26 Oct 2026
- PI Planning - Scaled Agile Framework — Scaled Agile, Inc., 15 Mar 2026
- SAFe Program Dependency Board Retrospective — Scaled Agile, Inc., 11 Jun 2021
- How do I create structured interview questions? — US Office of Personnel Management, 26 Oct 2026
- Using the STAR method for your next behavioral interview — MIT Career Advising and Professional Development, 26 Oct 2026
- Amazon's Leadership Principles — Amazon, 26 Oct 2026
- Internal dependency (PMBOK classification) — BVOP, 26 Oct 2026
- PMBOK Guide 5th edition, chapter 6: dependency determination — 4SquareViews, 30 Mar 2013
- How To Manage Dependencies Across Teams — Workhint, 26 Oct 2026
