How did you get another team to adopt a change they had no reason to prioritize?
answer
- the ask and their competing priorities
- what you learned before asking
- reframed in their currency
- the concession that lowered their cost
- insider co-signed; outcome measured their side
basics
~20 sTests cross-boundary influence with no shared manager and no shared backlog. Answer by showing you learned what the other team was accountable for, framed the ask in their terms, lowered their cost of saying yes, and delivered a durable outcome.
how to answer
6 beats- the ask, and why it was genuinely not their problemSet this up in two or three sentences and be fair to them: state what you needed and the real reason it sat below their own work. Keep setup plus context to roughly a fifth of your airtime.
- what you learned about their world before askingName how you found out what they were accountable for — reading their tracker, sitting in their triage, doing some of their work. This beat is what separates influence from a well-written ticket.
- the version of the ask that cost them leastThe heart of the answer, with the next beat about sixty percent of your airtime. Describe the reframe into their metric and the concrete concession you paid: owning the migration, absorbing the breakage, shipping a compatibility path, moving your own date.
- the ally inside their team who carried itSay who co-signed the proposal and why you chose them, ideally the most skeptical person rather than the friendliest. An outsider's proposal in someone else's area usually needs an insider's name on it.
- what landed, measured on their side tooGive a number that team would also claim as a win, not just yours. Result and reflection close the answer in about a quarter of your airtime.
- what actually moved it, in hindsightOne sentence naming the real lever. Strong answers often admit it was not the technical artifact but the standing earned beforehand, or the concession, or the choice of sponsor.
your answer
5 story prompts- Pick a team you had no authority over and needed something durable from.
- Write down what that team was measured on at the time, in their words.
- Name the concrete concession you paid to lower their cost of saying yes.
- Identify the insider who co-signed it, and why you chose that person.
- Check the outcome is still running without you chasing anyone.
draft and rehearse your own answer in a learn session
go deeper
This probes influence across a boundary you do not control: no shared manager, no shared backlog, no leverage. The interviewer is scoring empathy for another team's priorities, willingness to pay a cost to make yes cheap, and coalition-building over escalation. A strong answer proves you can produce durable cross-team change without borrowing anyone's authority.
Our project shipped a testing harness that a sibling repository — the plugin collection, run by a different group of volunteers — did not use. They had their own fixtures, so every release we broke them and heard about it through a bug report. I wanted them on our harness, and I had no say over their repository at all. First I stopped asking. For two weeks I did their triage with them: picked up seven of their failing issues and fixed them. That is how I found out their pain was not fixtures. It was that their full matrix took twenty-six minutes and their maintainers reviewed on weekends. So I re-pitched in their currency. I built a proof of concept running their matrix on our harness in eight minutes, and I offered the thing that cost them least: we would write the migration commits and take the breakage for the first two releases, and they would only review. Then I asked their most skeptical maintainer to co-author the migration proposal rather than review mine. That is what actually carried it — a proposal from outside someone's repository needs an insider's name on it. They moved over one release cycle. Cross-repository breakage reports went from about one every release to two in the following half-year, and their matrix runs on the shared harness now. The lever was not the proof of concept. It was two weeks of unglamorous triage that bought me the standing to make the pitch at all.
The signal is paying first: doing the other group's triage before asking, then reframing the ask around the number they cared about. The named concession and the skeptic-as-co-author are what a hiring bar looks for here. Without the concession this reads as a favour rather than influence.
Twelve repositories under the same open-source umbrella each ran their own CI setup, and none of the maintainer groups answered to anyone. Median suite runtime across them was thirty-seven minutes, and new contributors bounced off the slowest ones. I could not mandate anything, so I stopped selling a tool and built a way for the decision to get made. I proposed a cross-repository working group with a one-page charter: a shared runtime budget, a common harness, and an explicit rule that any repository could opt out by writing down why. The opt-out is what made joining safe — nobody was agreeing to a precedent they could not exit. Then I sequenced it deliberately. I did not start with the largest repository. I started with two mid-sized ones whose maintainers were already frustrated, and I spent my own weeks doing their migration. When their numbers dropped, I asked them to present it on the monthly community call instead of presenting it myself; adoption travels peer to peer, not from a champion. I also paid for the boring parts: a codemod, a compatibility shim so a repository could move in halves, and office hours every other week for a quarter. Nine of the twelve moved within two quarters and the median landed at fourteen minutes. Two opted out for reasons I agreed with, and one is still holding out. What I would change is publishing the runtime budget as a public dashboard on day one. I ran on persuasion for a quarter before anyone could see a scoreboard.
The principal signal is designing the decision process rather than winning arguments: a charter with a safe opt-out, a deliberate adoption sequence, funded migration tooling, and other people presenting the win. Naming the repositories that opted out keeps it honest. Personally convincing each group instead would downlevel it.
You will rarely be asked this, and a small version is fine: you needed a fix or a review from a neighbouring team and got it by making the request tiny, specific and easy to say yes to. Show that you found out how they take requests before you asked.
Ground it in one dependency you owned. The signal is preparation: you knew their roadmap, you brought a working branch instead of a ticket, and you kept the ask smaller than the favour would have been.
Show a campaign, not a request. Name the sponsor or ally you recruited inside the other team, the concession you paid to lower their cost, and an outcome measured in a number they would also claim as theirs.
Talk about removing the need to persuade each team one at a time: a shared standard with a safe opt-out, a migration path someone else can walk without you, incentives aligned so adoption is the cheapest option, and a scoreboard everyone can see.
saying these in an interview costs you the question
- Framing the ask entirely in your own team's benefit
- Escalating to managers as the first move rather than the last
- No evidence you learned what that team was accountable for
- Describing the other team as blockers or as bureaucratic
- Result measured only on your side of the boundary
- A one-off favour presented as durable adoption
- What did you do when they said it was not on their roadmap?Do not answer with escalation. Say how you shrank the ask, moved the work onto your own side of the line, or found the release window where it was cheapest for them. If you did eventually escalate, describe how you told them first — an escalation they hear about from their manager ends the relationship you needed.
- Who was your sponsor there, and how did you pick them?Name a role, not a friend: the person whose objection would have killed it, or whoever owns the surface you are changing. Say what made them say yes, and what you gave them — co-authorship, credit at a public forum, first call on the design. Having no insider is the most common gap in this answer.
- What did you give up to get it prioritized?Have a real concession ready — owning the migration commits, taking the breakage pages, a compatibility path so they could move in halves, a later date. Candidates whose cross-team wins cost them nothing are usually describing a favour, not influence.
- How would you approach it differently if you had authority over both teams?The trap is answering "I would have just mandated it." Say what the persuasion route bought you anyway — a better design from their constraints, maintainers who now defend the change — and where you would use authority narrowly, usually to set a deadline or an opt-out rule rather than a solution.