Tell me about a time you needed to drive a change across multiple teams, but had no formal authority over any of them. How did you get it done?

This question probes whether you can create real momentum through influence, credibility, and making the change genuinely easy to adopt — rather than through positional power you don't have, which is exactly the situation most DevOps and platform work actually happens in (you're rarely anyone's manager, but you're constantly asking teams to change how they work). A strong answer shows you understood other teams' actual incentives and constraints, built credibility through concrete evidence rather than just asking nicely, and made the change low-friction enough that adoption didn't require anyone doing you a personal favor.

DevOps and platform engineering roles are structurally full of exactly this situation: rolling out a new security scanning requirement, standardizing a deployment pattern, migrating teams off deprecated infrastructure — all frequently require many different teams to change their behavior, and the person driving it is rarely their manager. The interviewer is checking whether you have a real toolkit for this beyond "I asked people to do it and hoped."

Did you understand what the other teams actually needed, not just what you needed from them? A strong example shows genuine effort to understand each team's own constraints and incentives — a team resisting isn't usually being difficult for its own sake, they usually have a real reason (a deadline, a technical constraint, a past bad experience with a similar ask) that's worth understanding before trying to persuade them.

Did you build credibility through concrete evidence rather than authority? Effective influence without formal power usually comes from something concrete: a working prototype, data showing the actual benefit, a pilot with one willing team that then became a reference case for others — "trust me, this is better" rarely works as well as "here's a team that tried it and here's what happened."

Did you make adoption genuinely easy, not just theoretically correct? The strongest examples usually involve reducing the actual friction of adopting the change (good documentation, migration tooling, being available to help directly) rather than just being right about why the change should happen — this mirrors the golden-path platform-engineering principle: the right answer being technically correct doesn't matter if it's painful to adopt.

Honest acknowledgment of what didn't go smoothly. A credible answer usually includes some real friction along the way — a team that pushed back hard, a piece of the plan that had to change based on feedback — rather than a story where everyone immediately agreed once you explained your excellent reasoning.

Structure the answer with the actual stakes (why this change mattered), the specific approach you took to build buy-in across teams without formal authority, concrete actions (not just conversations — what did you actually build or provide to make this easier), and an honest account of the outcome including any resistance you had to work through.

• The interviewer is assessing your ability to drive change through influence and credibility, not whether you have or want formal authority.
• Strong answers show genuine understanding of other teams' actual constraints, not just your own reasoning for why the change is correct.
• Building credibility through concrete evidence (a working pilot, real data) is usually more effective than persuasion alone, and reducing actual adoption friction matters as much as being right.
• Honest acknowledgment of real resistance or friction along the way is more credible than a story where everyone agreed immediately.

• Google SRE Book: Postmortem Culture