The platform team you depend on has just deprioritised your dependency, and their director outranks yours. How do you get your feature delivered?

Find out what displaced you

The first move is not a response, it is a question, and the answer changes everything that follows. A platform team drops a commitment for a small number of reasons, and they are not equally negotiable. An incident or a regulatory deadline has consumed their capacity, in which case the constraint is real, temporary and knowable in duration. They lost people, in which case it is real and open-ended. Another consumer with a louder sponsor got in front of you, in which case it is a prioritisation decision that can be revisited. Or they never believed in your requirement — the interface was awkward, the use case looked like a special case, they suspect you will come back with three more changes — in which case what you have is a design disagreement wearing a scheduling costume, and arguing about the schedule will not touch it.

You get this by asking directly and without heat: what moved, when did it move, and what would have to change for our item to come back. Ask it of the engineering lead rather than the director, because the lead knows the real answer, and because arriving at the director first is the move that makes the fourth explanation permanent.

Shrink the ask until it fits

Most dependencies are specified far larger than the need. You asked for a general capability with an admin interface and audit events; what your feature requires might be a single read endpoint returning three fields, with no backfill and no user interface. That is a different conversation, and it is often the difference between a quarter of their roadmap and two days of one engineer's time.

So decompose your dependency into what you need to ship, what you need to ship well, and what you asked for because it seemed sensible to ask while you were there. Then offer to do the work yourself in their codebase against their review, which many platform teams will accept and few product managers offer. The objection you will hear is the maintenance burden rather than the build, and that objection is answered by owning the on-call for the endpoint, or by agreeing that it is explicitly private to your caller and unsupported for anyone else.

Build the version that does not need them

Before any escalation, work out what you can ship with no help at all, and what that version costs. This has two uses. It occasionally turns out to be good enough, and it always improves your position, because a request accompanied by an alternative is a decision while a request without one is a demand.

A worked version, with every input stated. Suppose the feature is a spend dashboard for finance users, and the dependency is a platform aggregation service. The unblocked alternative is to query the transactional database nightly and cache a rolled-up table yourself. Say the build is 8 engineer-days against your team's capacity of 40 engineer-days in the sprint, so a fifth of the sprint. The data is up to 24 hours stale rather than live. You estimate ongoing maintenance at half a day a month, and you expect to delete the whole thing when the platform service lands, which the other team currently puts two quarters out — call it 6 months, so 3 engineer-days of maintenance thrown away plus the original 8, an 11-day write-off. Against that, the feature is the reason two named renewals cited a gap, and staleness of a day is acceptable for a monthly finance review by their own description of the workflow.

Those numbers make a case that no amount of advocacy makes: eleven days of eventual waste to unblock a renewal argument, versus waiting six months. State the assumptions as assumptions. An interviewer is grading whether the arithmetic is visible, not whether the figures are impressive.

Escalate a decision, not a feeling

If you do need to go up, the form matters more than the merits. What fails is the version that describes the other team's behaviour: they committed and then dropped it, they are not treating us as a customer, their priorities are wrong. Every sentence of that invites the receiving director to defend their organisation, and you have converted a scheduling problem into a status contest you cannot win from below.

What works is a short note that contains the business consequence, the two options, and your recommendation, with the other team's constraint stated sympathetically and accurately. For example: the platform aggregation service has moved to Q4 because their team absorbed the payments incident work, which we understand. That leaves us two options for the finance dashboard. We can build a nightly cached table ourselves for eight days of our sprint capacity and about eleven days of eventual throwaway work, shipping in three weeks. Or we can hold the feature to Q4, which leaves the gap open through both renewals. We recommend the first, and we would need nothing from the platform team beyond a review. If leadership prefers the second, we will tell the two accounts this week.

That message can be forwarded without embarrassing anyone, it makes the cost of waiting explicit, and it gives the executive something to approve in one line. It also quietly demonstrates that you did the work before asking for help, which is the actual thing being graded.

The relationship is the asset, not this feature

The failure a candidate cannot see is that winning this escalation can cost more than losing it. You will depend on that team again next quarter and the one after, and a team that has been escalated over will meet your next request with process: formal intake, written requirements, a queue position. That is entirely rational of them and it doubles your lead time forever.

So spend the escalation only when the feature genuinely warrants it, tell the other team you are raising it before you raise it, and let them see the wording. And treat the underlying cause as the thing to fix: a dependency that vanished without warning means you had no standing visibility into their plan. The durable answers are boring ones — being present at their planning, having your dependency written into their commitments rather than agreed in a corridor, and knowing the date at which an unconfirmed dependency becomes a replan rather than a hope.

Arrive at the escalation with the dependency shrunk, an unblocked alternative costed, and a recommendation the executive can approve in a sentence. A request with no alternative attached is a complaint, and it spends credibility you will need for the next dependency.