Driving alignment across teams with competing priorities when no one reports to you.
This question tests whether you can move an organization you don’t control. As a senior engineering leader — especially in a horizontal infra role like ads events storage, where every product team is a dependency and none is a report — most of your leverage comes from persuasion, not position. The interviewer wants to see that you get outcomes by aligning incentives, marshalling data, and building coalitions, and that you treat escalation as a tool you use deliberately, not as an admission that your influence failed. The answer is built on the CARL shape — Context, Actions, Results, Learnings — with most of your words on the moves only you made.
The spine: find the shared goal → bring data and ROI → build a coalition → make the easy path the right path → escalate cleanly when stuck → land a measurable result.
What this question is really testing
Can you get competing teams to do something that helps the whole without the authority to order it — and do it in a way that leaves those relationships stronger, not spent.
How to answer
Reframe to a shared goal. Start by finding the outcome every team already wants — reliability, cost, launch velocity — and show how your ask is the path to their win, not a tax you’re levying on their roadmap.
Lead with data and ROI. Replace “please prioritize this” with a number: the incident hours saved, the CPU or storage dollars freed, the latency regression avoided. Objective evidence is the currency that buys priority you can’t command.
Build a coalition before the big room. Line up the influential allies — a respected tech lead, the partner PM, a friendly director — one conversation at a time, so the proposal walks into the review already supported rather than being litigated live.
Make the easy path the right path. Lower the cost of “yes” to near zero: ship the migration tooling, do the integration work yourself, provide the default config. Teams adopt what’s frictionless and resist what’s homework.
Escalate as a tool, not a failure. When a genuine priority conflict can only be resolved above you, take a crisp, data-backed decision to the shared manager with the other party, framed as “we need a tiebreak,” not “they’re blocking me.” Clean escalation preserves the relationship; a surprise ambush destroys it.
What the interviewer is looking for
Outcomes achieved through incentives and evidence, not title or volume.
Empathy for the other team’s priorities — you understood their world before asking them to change it.
Coalition-building and pre-wiring, not a single heroic pitch.
Escalation used cleanly and rarely — a deliberate instrument, not a tantrum.
Relationships intact or stronger afterward, because you’ll need them again.
A worked example (CARL)
Context. Our ads events storage tier was carrying a fast-growing, low-value log stream that three product teams wrote to by default. It was on track to blow our storage budget by roughly 30% for the half, but none of the three teams owned the cost, and each had a packed roadmap. I owned the platform’s efficiency goal; I owned none of the three teams.
Actions. I started by refusing to make it a cost argument aimed at them — that just moves a problem they don’t feel onto their backlog. Instead I pulled the data and reframed the shared goal: I showed each team that the same low-value writes were also inflating their read latency and their own on-call query times, so trimming the stream was a reliability and developer-experience win they already wanted. I built the case in Scuba — per-team write volume, the dollar cost attributable to each, and the p99 latency they’d each recover — so the conversation ran on numbers, not opinions. Before proposing anything broadly, I pre-wired a coalition: I walked the analysis one-on-one to the most respected tech lead among the three and to the partner PM who owned the roadmap tradeoff, and got them nodding before any group review. Then I attacked the cost of “yes”: rather than asking each team to do migration work, my team built a schema-sampling config and a one-line opt-in, and I offered to send the diffs myself so their side was a review, not a project. Two teams adopted within the sprint. The third had a genuine conflict — a launch that depended on full-fidelity logs for another month. I didn’t try to steamroll them; I took a crisp, one-page decision doc to our shared director with that team’s lead in the room, framed as “here are two reasonable priorities in tension, we need a call on timing,” and we got a dated exception instead of a standoff.
Results. The write volume on that stream dropped by about 60% within six weeks, we came in under the storage budget for the half instead of 30% over, and the two adopting teams saw a measurable p99 read-latency improvement they hadn’t asked for but happily took. No relationship was bruised — the team we escalated on came back the next quarter to adopt the same sampling voluntarily.
Learnings. Influence is mostly upstream work: the reframe, the data, and the coalition happen before the ask. And escalation, done with the other party and backed by a decision doc, is a partnership move, not a hostile one — it’s how you get a fast decision without spending the relationship.
Common follow-ups
What if you can’t find a shared goal — the other team just doesn’t care?
How to answer
Dig for the real incentive. “Doesn’t care” usually means you haven’t connected your ask to what they’re measured on — find their goal and map to it.
Reduce the cost to near zero. If you can’t raise their motivation, lower the effort until saying yes is cheaper than saying no.
Find the higher shared goal. Escalate the framing to the org objective both teams answer to, so the priority is set where it should be.
Know when to escalate for a decision. If it’s a real priority conflict, that’s a leadership call — surface it cleanly rather than grinding.
How do you avoid escalation being seen as going over someone’s head?
How to answer
No surprises. Tell the other party you’re going to escalate and why, before you do — ideally escalate together.
Escalate the decision, not the person. Frame it as “two good priorities in tension, we need a tiebreak,” not “they’re blocking me.”
Bring options, not a complaint. Walk in with a crisp doc and a recommendation so leadership decides fast.
Commit to the outcome. Whichever way it goes, get behind it publicly — that’s what makes escalation safe to use again.
How is influencing peers different from influencing up to leadership?
How to answer
Peers need incentive alignment. They have their own roadmaps, so the win has to be theirs too — ROI and low friction do the work.
Leaders need the decision framed. Give them the tradeoff, the recommendation, and the cost of inaction in one page; respect their time.
Both need trust and track record. Credibility from prior delivery is what makes the next ask land, up or across.
Match altitude to audience. Peers want mechanism; leaders want impact and risk — tell the same story at the right resolution.
Where to get your data (Meta)
GSD — pull from the cross-team project or goal that required alignment across owners you didn’t manage.
Scuba / Unidash — pull the cost, volume, or latency numbers that turned your ask into an objective, data-backed case.
Workplace posts — pull the announcement or proposal where you built support and made the shared goal visible.
Design-review notes — pull the record of the decision or the tiebreak that resolved a priority conflict.
The internal wiki — pull from the decision doc or one-pager you used to pre-wire the coalition.