Your team's quarter depends on an API change, a schema migration or a platform feature that another team owns. You mentioned it to their manager in a hallway, they said "should be fine", and six weeks later it isn't on their board. Now your date slips, and in the review it's your date. Once you run more than one team, a lot of your delivery risk sits in other teams' backlogs. This post covers how to surface those dependencies early, make requests the other team can actually commit to, and escalate cleanly when they can't.
Why dependencies fail
Dependencies rarely fail because the other team is careless. They fail for predictable, structural reasons:
- The ask was never a real ask. A Slack message or a mention in a meeting isn't a commitment. The other team heard "someday", you heard "yes".
- It arrived after their planning. Most teams commit capacity at the start of a quarter or planning cycle. A request that shows up in week three competes with work they've already promised someone else.
- Nobody owns it on either side. Your tech lead assumes you're tracking it; you assume the tech lead is talking to their engineers. Nobody checks until it's late.
- The scope was vague. "We need auth to support service accounts" can mean two days or two months. The other team can't size it, so they can't schedule it.
- Their incentives point elsewhere. Your need is their cost. Unless it's tied to something their management cares about, it will lose to their own roadmap every time.
Each of these has a fix, and none of them requires authority over the other team.
Find them before planning, not during delivery
The cheapest time to handle a dependency is before either team has committed its capacity. Build a short dependency pass into your planning:
- For each initiative in next quarter's plan, ask the tech lead: "What has to be true in a system we don't own for this to ship?" Look specifically for APIs, data, infrastructure, security or compliance reviews, and shared libraries.
- For each answer, name the owning team and a named person on it. "Platform" isn't an owner. "Priya, who leads the identity team" is.
- Mark each one as hard (we can't ship without it) or soft (we can work around it at a cost). Only hard dependencies need the full treatment below; soft ones need a written fallback.
- Reach out to every owning team before their planning closes, not yours.
If you find more than two or three hard dependencies on a single initiative, treat that as a design signal. Can you change the scope, build a temporary adapter on your side, or sequence the work so the dependent part comes last? The best-managed dependency is the one you removed.
Make an ask they can say yes to
A good request makes it easy for the other manager to evaluate, size and schedule. Write it down, and send it to the manager and their tech lead together. A template:
Subject: Request: service-account support in auth API, needed by <date>
What we need
One sentence describing the capability, not the implementation.
Why it matters
What it unblocks for us, and who outside engineering cares
(customer, contract, company goal).
Scope, as we understand it
The smallest version that unblocks us. What we explicitly don't need.
When
The date we need it by, and the last date it's still useful.
What we can contribute
e.g. one of our engineers can write the change for your review,
we'll write the tests, we'll update the docs.
What happens if it's not possible
Our fallback and its cost, so you can weigh it honestly.
What we need from you
A yes/no/partial by <date>, and a named contact on your team.
Three parts of this carry most of the weight:
- The smallest version. Teams say no to large, open-ended asks and yes to small, well-bounded ones. Cutting your ask to what actually unblocks you often turns a quarter of work into a week.
- What you can contribute. Offering to do the work under their review, sometimes called an inner-source contribution, is often the fastest route. It moves the cost from their capacity to their review time. Be sure they're willing to own the code afterwards; some teams will reasonably refuse changes they'll have to support.
- The fallback. Stating what you'll do if they say no removes the pressure to say yes out of politeness, which is exactly the "should be fine" that failed you last time. An honest no in week one is worth far more than a soft yes that turns into a no in week eight.
Agree how the teams will work together
Matthew Skelton and Manuel Pais, in Team Topologies, describe three ways teams interact: collaboration (working closely together for a period to discover something new), X-as-a-Service (one team consumes what another provides, with minimal back-and-forth), and facilitating (one team helps another learn or adopt something). One of their key points is that the mode should be chosen deliberately and is expected to change over time, and that collaboration is valuable but costly, so it should be time-boxed rather than left to run indefinitely.
That maps directly onto dependency requests. Before you agree a date, agree the mode:
| Mode | Use when | What you agree up front |
|---|---|---|
| X-as-a-Service | The need is clear and the other team already offers something close | The interface, the date, how you'll be told if it slips |
| Collaboration | Neither team knows the right answer yet | Who from each team, how many weeks, and what "done collaborating" looks like |
| Facilitating | You'll build it yourselves with their guidance | Their review turnaround, office hours, who approves the final change |
Most dependency friction comes from a mismatch: you expected a service, they thought they were helping you build it, or the other way round. Naming the mode out loud prevents that.
Track them where people will see them
Once agreed, dependencies need a lightweight, visible home. A shared table that both teams can read is enough:
| Dependency | Owning team / contact | Hard or soft | Needed by | Status | Fallback | Last checked |
|---|---|---|---|---|---|---|
| Service accounts in auth API | Identity / Priya | Hard | May 15 | On track | Shared API key per tenant (security sign-off needed) | May 2 |
| Events export for billing | Data platform / Tom | Soft | June 1 | At risk | Nightly batch file | May 2 |
A few habits keep it honest:
- Check weekly with the contact, not the manager. Engineers doing the work know about slips before anyone else.
- Use three states only: on track, at risk, off track. "At risk" means you're now actively preparing the fallback.
- Put the table in your status update. Your manager should see dependency risk the same week you do, not the week the date moves.
- Track the other direction too. List what other teams need from yours. Being reliable on those is what earns you goodwill when you're the one asking.
Escalate without making it personal
Sometimes the other team simply can't do it: their own priorities are legitimate and they conflict with yours. That's not a relationship failure; it's a prioritization decision that sits above both of you. Escalation is how you get it made.
Rules for escalating well:
- Tell the other manager first. "I think this needs a call from above us. Can we write it up together?" Never let them hear about it from their boss.
- Escalate jointly if you can. One short note, written by both of you, to the lowest manager who owns both roadmaps.
- Frame it as a trade-off, not a complaint. Present the options and their costs, not who's at fault.
- Escalate early. The moment a hard dependency goes to "at risk" and the fallback is expensive is the moment to raise it. Waiting to see if it resolves itself removes options.
A worked example, hypothetical:
Decision needed by Friday: Identity can't build service-account support before July without dropping SSO for the enterprise tier. Options:
A. Identity builds service accounts first; enterprise SSO moves from June to August. B. Identity keeps its plan; our partner integration launches in August instead of May. C. One of our engineers builds it under Identity's review; Identity spends about three days reviewing; both dates hold, with some risk to quality in an area we don't know well.
Priya and I both lean toward C. We need you to confirm the trade-off, since it touches both roadmaps.
That's a note a director can decide on in five minutes, and neither manager looks like they're blaming the other.
Your first step on Monday
Take your current quarter's plan and, for each initiative, write down every hard dependency, its named owner, and the date you need it. Then ask yourself one question for each: has the owning team explicitly said yes, in writing, to this scope and this date? Every "no" or "not sure" is a request to send this week.
Handling dependencies and influencing teams you don't manage are part of the stakeholder management competency area in the PTMA study guide, alongside the cross-functional collaboration and prioritization skills that make these conversations easier.