How do you escalate a blocking external dependency?

WHAT THIS TESTS: This question assesses your maturity beyond just coding. It tests your ability to take ownership of a problem, quantify its business impact, and understand the role of an agile leader as a facilitator, not just a task-master. Interviewers are looking for evidence that you can escalate problems constructively and with data, rather than just complaining or waiting to be told what to do. It separates senior engineers who solve systemic problems from junior ones who only solve technical tasks.

A GOOD ANSWER COVERS: An excellent answer provides a structured plan with three key components. First, quantify the impact: state the cost of the block in concrete terms like story points delayed (e.g., "13 points this sprint"), feature deadlines at risk, or even engineering-hours wasted (e.g., "40 engineer-hours lost so far"). Second, document your due diligence: provide a concise summary of every action you've already taken, including links to tickets, names of people contacted, and dates of communication attempts. Third, define a clear 'ask': specify exactly what you need the leader to do. This isn't 'please fix it,' but rather 'can you use your 1:1 with the other team's EM to get ticket #XYZ prioritized?' The key difference from traditional management is that you are providing ammunition for your leader to act, not abdicating the problem to them.

COMMON WRONG ANSWERS: A frequent red flag is escalating with emotion or vague complaints, such as "The other team is always slow" or "They're ignoring us." This shows a lack of professionalism and data-driven thinking. Another mistake is showing no ownership, implying it's the Scrum Master's or EM's job to have already known about and fixed the problem. A senior engineer is expected to try resolving issues at the lowest possible level first before escalating. Finally, asking the manager to 'handle it' without providing context or a specific request is a junior-level approach that fails the test.

LIKELY FOLLOW-UPS: Expect follow-up questions like "What would you do if your EM was unable to resolve the impediment?" which tests your understanding of broader escalation paths. Another common one is "How would you work to prevent this type of dependency from blocking your team in the future?" which probes your strategic thinking about architectural solutions (like an anti-corruption layer), cross-team planning, or formalizing Service Level Agreements (SLAs).

ONE CONCRETE EXAMPLE: "Our team was blocked by the Auth service, which needed to add a new scope for our feature. After two days with no reply on their public Slack channel, we filed a ticket. A week later, the ticket was still unassigned. We calculated this blocked 2 engineers and 15 story points, putting our quarterly goal at risk. I prepared a one-page summary for our EM with the timeline of events, a link to the ticket, and the calculated impact. My specific ask was: 'Can you bring this up in the weekly engineering leadership sync to get it prioritized?' This armed my EM to advocate for us effectively."