Influence Without Authority

you changed an outcome you could not mandate

What is scored: can you get something to happen across a boundary you do not control — another team, a more senior person, an organisation that has other priorities?

This is the competency that most distinguishes senior from staff, because at staff level almost nothing you need is inside your authority.

What the interviewer is looking for

A real boundary. Another team, a skip-level, a partner org. Convincing your own two teammates is collaboration, not influence.
You understood their incentives, not just your own case. Why was this not already a priority for them? If you cannot answer that, you were not influencing, you were asking repeatedly.
You made it easy to say yes. Did the work, wrote the proposal, built the prototype, reduced their cost to near zero.
You found the right lever — data, a pilot, an ally, a forum, timing. Naming the lever is what makes this a skill rather than persistence.
A durable outcome. Something changed and stayed changed after your attention moved on.

Persistence alone does not score. "I kept bringing it up until they agreed" is attrition, and the interviewer will hear it that way.

Weak and strong, same prompt

Prompt: tell me about influencing a decision you did not control.

Weak.

"I thought we should adopt typed APIs across our services. I brought it up in several team meetings and wrote a document explaining the benefits. Eventually my manager agreed and we adopted it on new services."

Inside the team, so no real boundary. The method was assertion plus repetition. And the outcome is soft — "on new services" usually means "never retrofitted and quietly abandoned".

Strong.

"We needed the platform team to add request tracing to the shared gateway. Without it, debugging a cross-service latency problem took days. I had no authority over them and they had a full roadmap. First I worked out why it had not happened. It was not that they disagreed — three teams had asked. It was that it was a two-week job with no owner, benefiting other teams, and it would never beat anything on their own roadmap. Asking again was not going to change that arithmetic. So I changed the arithmetic. I built the integration myself against a fork of the gateway — about a week — and got it working end to end in our staging environment. Then I went to them with a merge request and a short document, and the ask was 'review this and tell me what is wrong with it' rather than 'please build this'. Their tech lead found two real problems: my approach added about 3ms to every request, and I had not handled the sampling configuration. We fixed both together — that took three days and it was genuinely collaborative, and it also meant they now had ownership of it. It shipped six weeks later. Two other teams adopted it within a quarter, and the platform team folded tracing into their standard template so it is on by default for new services now. The thing I learned: I spent the first month asking, which achieved nothing, because the obstacle was never disagreement. Now when something stalls I try to work out what the actual obstacle is before I make the case again, because usually it is cost or ownership, not persuasion."

Real boundary, diagnosed incentives, reduced their cost to almost nothing, gave them ownership rather than credit, and a durable systemic outcome.

Question bank

Tell me about a time you influenced a decision you did not own.
Describe convincing someone senior to change their mind.
Tell me about driving a change across multiple teams.
How do you get buy-in for a technical initiative?
Tell me about a time you failed to convince someone.
Describe introducing a new practice to your team.
Tell me about a time you had to build consensus among people who disagreed.

"Tell me about a time you failed to convince someone" is asked more often than candidates expect. It wants a diagnosis, not an excuse — and the best answers conclude that the other side was partly right.

Where these answers go wrong

It was your own team. No boundary, so the competency is not exercised.

Persuasion by document. Writing a compelling case is a component, not a method. On its own it usually fails, and a story that ends with "and my document convinced them" is rarely how it went.

No incentive analysis. If you never worked out why it was not already happening, you were repeating yourself. The diagnosis is the skill.

Taking the credit. Influence stories go wrong when the candidate sounds pleased about having outmanoeuvred someone. The strongest versions give the other party ownership — note that in the strong answer above, the platform team ends up owning tracing, and that is presented as the goal, not a concession.

A soft outcome. "They agreed it was a good idea" is not an outcome. What changed, and was it still true six months later?

How to say it in the interview

"I could not make the platform team prioritise it. What I could do was make it cheap for them to say yes, so I did most of the work first."

Checklist

The boundary was real: another team, a senior person, another org
You diagnosed why it was not already happening
You reduced their cost of saying yes, substantially
You can name the specific lever you used
You gave the other party ownership rather than taking credit
The outcome was durable and you can say what it looked like later
You have a story about failing to convince someone, with a diagnosis

Practice this interactively