Tell me about influencing a decision across teams where you had no authority.
- 1 min — the cross-team problem and why you lacked authority
- 2 min — data you brought, RFC, the dissenter and how you addressed their concern
- 1 min — what you built vs the team
- 1 min — adoption numbers, the holdout, the regret
Influence without authority is built from making the other team's problem smaller: shared data, a cheap first step, and credit that flows to them. The interviewer wants the mechanism, not charisma.
Good AI-platform examples: getting several product teams onto a shared LLM gateway, a common tracing format, or PII redaction before logging.
Staff answers show a pattern that scaled — an RFC, a paved road, a migration kit — and an honest account of the team that didn't come along and why.
What the answer sounds like at each level
Persuaded a neighbouring engineer or team to adopt a library or practice.
Moved several teams with data and a migration path they could take cheaply.
Created a paved road with an RFC, benchmarks and ownership model that stuck across an org, and handled the holdout honestly.
Follow-ups the interviewer will push
1What would you have done if the search team refused?
Let them stay on a documented exception with an expiry date, keep their traffic visible in cost reports, and revisit when the gateway had a feature they needed. Forcing it would have cost more trust than it saved.
2How did you measure success?
Share of LLM traffic through the gateway, cost attributable per feature, and incidents absorbed by fallback — all three reported monthly to the platform director.
Red flags interviewers listen for
- Influence by escalation: 'I got my director to tell them'.
- All credit to self; teams portrayed as obstacles.
- No mention of what it cost the other teams to adopt.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Mechanism | Data, a cheap first step, addressing the dissenter's specific concern with evidence. |
| Scope | Several teams, measured adoption, a durable artefact (RFC, library). |
| Self-awareness | Names a real gap in their own execution. |
Getting five teams onto one LLM gateway
Illustrative exampleFive product teams were calling three model providers directly with their own keys. Finance couldn't attribute ~$180k/month of LLM spend, and a key leaked in a client bundle once. I was on the platform team; none of the five reported to me.
Move all five to a shared gateway with per-team budgets, rate limits and fallback within one quarter, without a mandate.
I started with the data each team lacked: I pulled 30 days of provider invoices and showed each team its own cost per feature, which none of them had. I wrote a two-page RFC and asked each team's lead to comment before it was final. The loudest dissenter was the search team's lead, who worried about added latency on a p95-sensitive path. Instead of arguing, I benchmarked the gateway on their traffic replay: +6 ms p50, +11 ms p95, and prompt-cache routing that cut their p95 by 140 ms. I built the client library and migration PRs myself for the first two teams; two engineers on my team of four did the rest.
Four of five teams migrated in 10 weeks; 96% of LLM traffic went through the gateway, spend became attributable per feature, and fallback absorbed a 47-minute provider outage with no user-facing errors. The fifth team migrated the next quarter. I'd do one thing differently: I under-invested in the on-call story for the gateway, and the first incident page went to a team that didn't know it was now on the critical path.