When a Critical Dependency Slips
Final Prep · Cross-functional Collaboration — a critical component owned by a remote or external team is severely slipping and threatens your launch; how you manage the stakeholders and get the project back on track.
This question separates leaders who manage a plan from leaders who manage reality. A weak answer either escalates instantly (throwing the other team under the bus) or absorbs the slip in silence and hopes it recovers. A strong answer shows you get to ground truth fast, distinguish a real slip from a schedule wobble, work the problem with the owning team before escalating, protect your launch with options rather than ultimatums, and escalate cleanly and early when the data says you must. Answer in CARL shape — Context, Actions, Results, Learnings — and spend most of your words on the Actions.
What this question is really testing
Whether you can lead through influence rather than authority. The team that is slipping does not report to you, may be in another timezone, and may have its own competing priorities. The interviewer wants to see that you can build a shared picture of reality without blame, create pressure through transparency rather than politics, and make a hard call — wait, work around, cut scope, or move the date — with a clear head. It also tests whether you protect the relationship: you will need this team again, so how you handle the slip matters as much as whether you hit the date.
How to answer- Get to ground truth first. Talk directly to the owning team’s engineers and lead, not just the status dashboard — understand whether it is a one-time slip, a systemic under-scope, or a priority conflict, because the fix differs for each.
- Quantify the impact in shared terms. Translate the slip into what it costs the joint launch — the gated milestone, the downstream teams, the customer commitment — so the conversation is about the mission, not about fault.
- Work the problem jointly before escalating. Offer help — lend an engineer, cut the interface to a smaller contract, unblock a dependency they have — and co-own a recovery plan with explicit checkpoints.
- Build fallback options in parallel. Prepare a stub or degraded-mode path, a scope cut, or a phased launch so you are never single-threaded on someone else’s recovery.
- Escalate early, with data and a recommendation. If the recovery plan misses a checkpoint, escalate to both managers together — not to win, but to force a priority decision — and bring options, not just a complaint.
- Ground truth over dashboard status — you talk to people, not tickets.
- Impact framed around the shared mission, not blame.
- Genuine offers of help before any escalation.
- Parallel fallback options so the launch is never single-threaded.
- Escalation that is early, data-backed, and carries a recommendation.
A worked example (CARL)
Context. On the Ads Events / AIMS storage team we were launching a new low-latency read path for an events product, and it depended on a schema-and-throughput change owned by a remote ingestion team two timezones away. Their piece was on the critical path — without it our launch gate could not pass — and about five weeks out their status quietly moved from green to yellow, then their weekly update slipped a milestone with no explanation. Two downstream teams were sequencing their own work behind our launch, so a slip on our side would cascade.
Actions. I resisted the urge to fire off an escalation email and instead set up a direct working session with their tech lead and the two engineers actually doing the work — scheduled in the overlap window of our timezones so it was a real conversation, not an async ping. What I learned changed everything: it was not a one-off slip, it was a priority conflict. Their team had been pulled onto a separate reliability effort, and our change had lost an engineer to it. So the problem was not engineering, it was prioritization, and that told me the fix had to happen at the manager level — but not yet, and not as a fight. First I made the impact undeniable and shared: I wrote a one-page brief that translated their slip into concrete downstream cost — the gated launch, the two teams queued behind us, and the customer-facing commitment — and I framed it as “our joint launch is at risk,” not “you are late.” Then I looked for ways to buy the date back on our side of the fence: I offered to lend one of my engineers who knew the ingestion schema to pair with theirs, and I proposed cutting the interface contract down to the minimum our launch actually needed, deferring the richer version to a fast-follow. In parallel — and this is the part I care most about — I built a fallback so we were never hostage to their recovery: a degraded-mode read path that used the existing ingestion format, slower but launchable, that would let us hit the gate with reduced scope if their change did not land. We co-owned a written recovery plan with two checkpoints. When the first checkpoint slipped, I escalated exactly as I had told them I would — a joint note to both managers, with the impact brief, the recovery plan, the options, and a clear recommendation to either restore the engineer for two weeks or approve our reduced-scope launch. Because I had escalated with data and options rather than blame, the conversation was about priority, not about fault, and it resolved in one meeting.
Results. The two managers restored the engineer for a focused two-week push, and with my lent engineer pairing on the schema, the reduced-contract version landed in time to pass the launch gate. We shipped roughly on the original date with slightly trimmed scope and fast-followed the richer interface a few weeks later. The downstream teams stayed on their sequence. Just as importantly, the ingestion team came out of it as a stronger partner — because I had led with help and transparency, not politics, they trusted us on the next joint project.
Learnings. Two things. First, a status dashboard tells you that something slipped; only talking to the people doing the work tells you why, and the why determines whether the fix is engineering, scope, or prioritization. Second, always build the fallback in parallel — the reason I could escalate calmly and negotiate from strength was that I was never actually dependent on a single outcome. Optionality is what turns a crisis into a decision.
Common follow-ups
When exactly do you escalate versus keep working it yourself?
How to answer- Escalate on a missed checkpoint, not a feeling. Agree checkpoints up front so escalation is triggered by objective data, not frustration.
- Escalate to decide, not to blame. The purpose is to force a priority call that is above both teams’ pay grade — frame it that way.
- Escalate early enough that options still exist. A late escalation is just a status report on a failure; an early one preserves choices.
- Bring a recommendation. Never escalate a naked problem — bring the two or three options and say which one you would pick and why.
How do you keep the relationship intact when you have to escalate over their head?
How to answer- No surprises. Tell the owning team the escalation is coming and why, before it lands — ideally co-author it so it is a joint ask for help.
- Frame it as priority, not competence. Make clear the issue is contention for their time, not their engineering — that is almost always true and it protects trust.
- Lead with help first. If you have already offered engineers and scope cuts, the escalation reads as “we tried everything” rather than “they failed.”
- Close the loop generously. Credit the team publicly when they recover, so the lasting memory is partnership, not the escalation.
What if there is no viable fallback and their piece is truly required?
How to answer- Then the date is the variable. If scope cannot flex and there is no workaround, be honest early that the date must move — hiding it only compounds the cost.
- Re-baseline with the downstream teams. Give the teams queued behind you the new reality immediately so they can re-plan — the cascade is worse than the slip.
- Invest to remove the single point of failure. Treat the hard dependency as a risk to fix — fund a second path or shared ownership so you are not this exposed next time.
- Make the priority tradeoff explicit to leadership. If their team genuinely cannot deliver, that is a resourcing decision for leadership, framed with the full downstream cost.
How do you spot a slip early instead of at the last checkpoint?
How to answer- Track leading indicators, not just the final date. Watch diff velocity, design-doc sign-off, and the color trend of weekly updates — yellow that persists is a red in disguise.
- Build a lightweight joint cadence. A short weekly cross-team sync on the shared critical path surfaces trouble before it hits a milestone.
- Instrument the interface. Agree on a concrete integration checkpoint (a working stub, a contract test) well before the final date so drift is visible.
- Build the personal channel. A direct relationship with their lead means you hear “we’re worried” informally, long before it shows up in a status.
- GSD — pull the joint milestones, the dependency’s status trend, and the re-baselined plan after the slip.
- Design docs — pull the interface contract you cut down and the fallback / degraded-mode design.
- Cross-team sync notes — pull the working-session record where you got to ground truth on the priority conflict.
- Workplace posts / escalation thread — pull the impact brief and the joint escalation with options and recommendation.
- Oncall / launch-gate dashboards — pull the gate criteria and the evidence that the reduced-scope path met them.