GeneralAdvanced Premium

Leadership Without Authority

The senior+ signal. Can you drive cross-team work, mentor, and build consensus when nobody reports to you - or do you only execute when given a mandate?

About this theme

Leadership without authority is one of the most discriminating signals at senior, staff, and principal levels. Almost every meaningful engineering project involves people you don't manage - partner teams, peers on your own team, stakeholders in product or design, vendors, customers. The interview question is whether you can move work forward through influence, technical credibility, and clear communication, or whether you stall the moment you don't have a formal mandate. Strong candidates tell stories where they (a) built shared context with people who had different priorities, (b) earned trust through cheap proof points before asking for big commitments, (c) navigated explicit disagreement without escalating prematurely, and (d) recognized when influence wasn't going to work and escalated cleanly. Weak candidates tell stories where they "just convinced everyone" without describing how, or stories where the work succeeded because the candidate had de facto authority (their manager backed them, the project was already a top priority, etc.). This theme is heavily tested at Google (staff+ rounds), Meta (E5/E6), Stripe (senior+), and any company evaluating you for technical leadership scope.

What interviewers are evaluating

→Did you actually have to influence, or did you have implicit authority via your manager / project priority?
→Did you build shared context before asking for commitment, or did you push your conclusion?
→Did you earn credibility with concrete proof points (prototype, data, scoped pilot), or just argument?
→When people disagreed, did you investigate their reasoning, or label them as blockers?
→Did you mentor or grow others as a side effect, or only extract their effort?
→When influence wasn't working, did you escalate cleanly - or either give up or go around?
→At senior+ levels: did you scope the work so others could own pieces, or did you bottleneck on yourself?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you led a project where you had no formal authority over the people involved.
?Describe a situation where you had to drive consensus across teams with different priorities.
?Tell me about a time you mentored a peer or junior engineer who wasn't reporting to you.
?Walk me through how you got buy-in for a technical change that crossed team boundaries.
?Describe a time you had to influence a more senior engineer or stakeholder to change direction.
?Tell me about a time you tried to influence and it didn't work. What did you do?
?Describe a project where you had to coordinate work across people who didn't agree on the goal.

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: Cross-team migration through influence

Prompt: "Tell me about a time you led a project where you had no formal authority over the people involved."

Situation: About a year ago at a fintech, I noticed our four backend teams were each implementing their own retry / idempotency logic for outbound webhooks. Three of the four had subtle bugs that were causing duplicate notifications to merchants. There was no platform team, no designated owner, and no roadmap line item for fixing it. I was a senior engineer on one of the four teams.
Task: I wanted to consolidate this into a shared library, but I had zero authority over the other three teams, no mandate from leadership, and no extra headcount. The other three teams had their own roadmaps that didn't include this work.
Action: I started narrow. Step 1: I built the shared library inside my own team's scope as a refactor of our existing logic, with the design explicitly extracted into a small library. That was a week of work I could justify under my own team's bug fixes. Step 2: I wrote a one-page doc - 'webhook retry: where we are, what's broken, what a shared library could look like' - with the four duplicate-notification incidents from the prior 90 days, the library API I'd already built, and three options ranging from 'each team adopts when they next touch retry code' to 'platform-blessed mandatory adoption.' I deliberately didn't recommend an option; I asked for input. Step 3: I scheduled 30-minute 1:1s with one senior engineer from each of the other three teams. I led with their incidents, not my solution. Two of them said 'yes, this hurts, please' immediately. The third pushed back - their team had different latency requirements and the shared library defaults wouldn't work. Instead of arguing, I asked her to walk me through her use case. She was right; the library needed a configurable backoff policy. I went back, added it, and asked her to review the API. She did, suggested two more changes, and became an advocate. By the time I asked for an EM-level meeting, three of the four teams had reviewed the library and one had volunteered to adopt it on their next retry-touching change. I framed the meeting not as 'should we do this' but 'here's the path - what's missing?' EMs agreed to a 6-month adoption plan, no team needed to drop existing roadmap work, and the engineer who'd pushed back was named co-owner with me. I mentored two junior engineers from other teams through their first contributions to the library.
Result: All four teams adopted within 5 months. Duplicate-notification incidents dropped from ~3/quarter to zero in the next year. The library was open-sourced internally and picked up by two more teams I'd never spoken with. The pushback engineer and I co-led a follow-on consolidation effort. I learned a transferable pattern: build the proof, ask for input not approval, integrate the strongest critic as a co-owner.

Why this works

What makes this strong: (1) Genuinely no formal authority - no mandate, no headcount, no roadmap slot. (2) Sequenced influence: prototype first, ask second, propose third. Earned credibility before asking for commitment. (3) The strongest critic became a co-owner - that's the textbook senior pattern. (4) Mentored junior engineers as a side effect, not as the goal. (5) Quantitative outcome (zero duplicate-notification incidents) and a transferable lesson. (6) Acknowledged that the library shape changed because of the pushback - the candidate updated, didn't just persuade.

STRONG

Strong: Influence didn't work, escalated cleanly

Prompt: "Tell me about a time you tried to influence and it didn't work. What did you do?"

Situation: On a previous team, I was the senior engineer on a system that depended on a partner team's API. I'd flagged for two months that their error-handling contract was under-specified - they returned 500s for transient errors and 400s for client errors, but used 500s for some genuinely client-side problems. This made our retry logic incorrect in a way that was already causing low-volume bugs.
Task: I'd raised it twice in design reviews and once in a written doc. Each time, the partner team's tech lead acknowledged it but their roadmap was full. I had no authority over their roadmap.
Action: I had to decide: keep pushing peer-to-peer, escalate, or work around it. I tried one more peer-level approach: I scoped the fix on their side concretely - it was about 2 days of work and I offered to do it myself if their team would code-review and own the rollout. The tech lead declined, citing review burden and on-call coverage of an unfamiliar code path. That was a reasonable answer; I'd run out of peer moves. I then escalated, but cleanly. I wrote a one-page doc with: (1) the specific bug pattern in production with two recent examples, (2) the customer impact (~30 misclassified errors/week), (3) the three resolution paths with cost estimates (their team fixes, my team works around, joint fix), (4) explicitly: 'I've discussed with [partner tech lead] and we've reached an honest impasse on prioritization. I'd like a decision on which path to take.' I shared it with my EM, copied the partner tech lead, and asked for a 30-minute meeting with both EMs. I told the partner tech lead before the meeting: 'I'm escalating because I'm out of moves at our level - I want to be transparent that this isn't going around you.' In the meeting, the EMs aligned on the joint fix - their team would do the bulk of the work, my team would write tests and own the migration. The partner tech lead later told me she appreciated that I'd been direct about the escalation.
Result: Joint fix shipped 6 weeks later. The misclassification bugs went to zero. More importantly, the working relationship with the partner team got stronger - the partner tech lead and I co-designed two more features after that. I learned that 'clean escalation' is a skill: name what you've tried, name the impasse honestly, propose options not blame, and tell the other party before you escalate. That pattern has worked for me three more times.

Why this works

What makes this strong: (1) The candidate didn't pretend influence always works - that's the rare honest signal. (2) Genuine peer attempts before escalation (multiple raises, offered to do the work). (3) Clean escalation pattern, including telling the partner before escalating. (4) Result includes the relationship outcome, not just the technical fix. (5) Captured a transferable technique. This story would land at staff+ levels because it shows the candidate knows when influence ends and escalation starts.

WEAK

Weak: 'Everyone agreed with me'

Prompt: "Tell me about a time you led a project where you had no formal authority."

Situation: I was a senior engineer and I noticed an opportunity to improve our deployment process across teams.
Task: I had to convince the other teams to adopt my proposal.
Action: I wrote a doc, presented it in a meeting, and most people agreed it was a good idea. We rolled it out across the teams.
Result: The deployment process improved and everyone was happy.

Why this is weak

Why this is weak: (1) No specifics about the influence work - 'most people agreed' suggests either implicit authority or an uncontested proposal. (2) No pushback story. Real cross-team work has friction; if there was none, the candidate either wasn't actually leading without authority or isn't telling that part. (3) No mention of the people involved, the trade-offs they cared about, or how the candidate adjusted. (4) Generic outcome with no metric. Bar Raisers will probe and the lack of substance will surface.

Common pitfalls

×Stories where the candidate had de facto authority (their manager championed it, the project was already prioritized). That's not leadership without authority.
×Skipping the proof-point step. Strong stories include a cheap concrete artifact (prototype, doc, data) the candidate built before asking others to commit.
×'Everyone agreed.' Real cross-team work has at least one substantive disagreement. If your story has none, you're missing the part interviewers want.
×Framing influence as winning. Strong stories include moments where the candidate updated their proposal based on others' input.
×Stopping at 'I convinced them' without describing the mechanics. Senior interviewers want the technique, not the outcome.
×Failing to mention what you'd do if influence hadn't worked. Strong candidates know the escalation path and can describe when they'd use it.
×Junior-coded stories. If the cross-team scope is two engineers from a partner team for a week, that's collaboration, not leadership without authority. Senior+ stories involve multiple teams and meaningful duration.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'how did you decide who to talk to first?' - have a rationale. 'Started with the strongest critic / the team most affected / the most respected senior engineer' are all credible.
→If asked 'what if they had said no?' - your story should already include either a real no or a contingency. If neither, acknowledge that you didn't face a hard no in this story.
→If asked 'how did you balance this with your day job?' - real influence work has cost. Be specific about how you scoped it (X% of time, weekend prototype, traded off Y).
→If asked 'when do you escalate?' - have a heuristic. 'When peer-level options are exhausted and the cost of waiting exceeds the cost of escalation' is a strong frame.
→If asked about the people you mentored - have specifics. Names, what they learned, what they own now. Vague 'I helped them grow' reads as filler.
→If asked 'what would you do differently?' - the strongest answers identify a sequencing mistake (e.g., 'I'd talk to the strongest critic first, not last').

Related behavioral themes

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Conflict

General

The most universal behavioral question. Tested everywhere. The signal is in how you investigate the disagreement, not in how you 'won.'

Ambiguity

General

Tested at Google, Anthropic, OpenAI, and any senior+ loop. Strong candidates show how they get curious; weak candidates show how they get anxious.

Companies that test this theme

Google

L5 Senior Software Engineer

Google

L6 Staff Software Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →

About this theme

What interviewers are evaluating

→Did you actually have to influence, or did you have implicit authority via your manager / project priority?

→Did you build shared context before asking for commitment, or did you push your conclusion?

→Did you earn credibility with concrete proof points (prototype, data, scoped pilot), or just argument?

→When people disagreed, did you investigate their reasoning, or label them as blockers?

→Did you mentor or grow others as a side effect, or only extract their effort?

→When influence wasn't working, did you escalate cleanly - or either give up or go around?

→At senior+ levels: did you scope the work so others could own pieces, or did you bottleneck on yourself?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you led a project where you had no formal authority over the people involved.

?Describe a situation where you had to drive consensus across teams with different priorities.

?Tell me about a time you mentored a peer or junior engineer who wasn't reporting to you.

?Walk me through how you got buy-in for a technical change that crossed team boundaries.

?Describe a time you had to influence a more senior engineer or stakeholder to change direction.

?Tell me about a time you tried to influence and it didn't work. What did you do?

?Describe a project where you had to coordinate work across people who didn't agree on the goal.

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: Cross-team migration through influence

Prompt: "Tell me about a time you led a project where you had no formal authority over the people involved."

Situation: About a year ago at a fintech, I noticed our four backend teams were each implementing their own retry / idempotency logic for outbound webhooks. Three of the four had subtle bugs that were causing duplicate notifications to merchants. There was no platform team, no designated owner, and no roadmap line item for fixing it. I was a senior engineer on one of the four teams.
Task: I wanted to consolidate this into a shared library, but I had zero authority over the other three teams, no mandate from leadership, and no extra headcount. The other three teams had their own roadmaps that didn't include this work.
Action: I started narrow. Step 1: I built the shared library inside my own team's scope as a refactor of our existing logic, with the design explicitly extracted into a small library. That was a week of work I could justify under my own team's bug fixes. Step 2: I wrote a one-page doc - 'webhook retry: where we are, what's broken, what a shared library could look like' - with the four duplicate-notification incidents from the prior 90 days, the library API I'd already built, and three options ranging from 'each team adopts when they next touch retry code' to 'platform-blessed mandatory adoption.' I deliberately didn't recommend an option; I asked for input. Step 3: I scheduled 30-minute 1:1s with one senior engineer from each of the other three teams. I led with their incidents, not my solution. Two of them said 'yes, this hurts, please' immediately. The third pushed back - their team had different latency requirements and the shared library defaults wouldn't work. Instead of arguing, I asked her to walk me through her use case. She was right; the library needed a configurable backoff policy. I went back, added it, and asked her to review the API. She did, suggested two more changes, and became an advocate. By the time I asked for an EM-level meeting, three of the four teams had reviewed the library and one had volunteered to adopt it on their next retry-touching change. I framed the meeting not as 'should we do this' but 'here's the path - what's missing?' EMs agreed to a 6-month adoption plan, no team needed to drop existing roadmap work, and the engineer who'd pushed back was named co-owner with me. I mentored two junior engineers from other teams through their first contributions to the library.
Result: All four teams adopted within 5 months. Duplicate-notification incidents dropped from ~3/quarter to zero in the next year. The library was open-sourced internally and picked up by two more teams I'd never spoken with. The pushback engineer and I co-led a follow-on consolidation effort. I learned a transferable pattern: build the proof, ask for input not approval, integrate the strongest critic as a co-owner.

Why this works

STRONG

Strong: Influence didn't work, escalated cleanly

Prompt: "Tell me about a time you tried to influence and it didn't work. What did you do?"

Situation: On a previous team, I was the senior engineer on a system that depended on a partner team's API. I'd flagged for two months that their error-handling contract was under-specified - they returned 500s for transient errors and 400s for client errors, but used 500s for some genuinely client-side problems. This made our retry logic incorrect in a way that was already causing low-volume bugs.
Task: I'd raised it twice in design reviews and once in a written doc. Each time, the partner team's tech lead acknowledged it but their roadmap was full. I had no authority over their roadmap.
Action: I had to decide: keep pushing peer-to-peer, escalate, or work around it. I tried one more peer-level approach: I scoped the fix on their side concretely - it was about 2 days of work and I offered to do it myself if their team would code-review and own the rollout. The tech lead declined, citing review burden and on-call coverage of an unfamiliar code path. That was a reasonable answer; I'd run out of peer moves. I then escalated, but cleanly. I wrote a one-page doc with: (1) the specific bug pattern in production with two recent examples, (2) the customer impact (~30 misclassified errors/week), (3) the three resolution paths with cost estimates (their team fixes, my team works around, joint fix), (4) explicitly: 'I've discussed with [partner tech lead] and we've reached an honest impasse on prioritization. I'd like a decision on which path to take.' I shared it with my EM, copied the partner tech lead, and asked for a 30-minute meeting with both EMs. I told the partner tech lead before the meeting: 'I'm escalating because I'm out of moves at our level - I want to be transparent that this isn't going around you.' In the meeting, the EMs aligned on the joint fix - their team would do the bulk of the work, my team would write tests and own the migration. The partner tech lead later told me she appreciated that I'd been direct about the escalation.
Result: Joint fix shipped 6 weeks later. The misclassification bugs went to zero. More importantly, the working relationship with the partner team got stronger - the partner tech lead and I co-designed two more features after that. I learned that 'clean escalation' is a skill: name what you've tried, name the impasse honestly, propose options not blame, and tell the other party before you escalate. That pattern has worked for me three more times.

Why this works

WEAK

Weak: 'Everyone agreed with me'

Prompt: "Tell me about a time you led a project where you had no formal authority."

Situation: I was a senior engineer and I noticed an opportunity to improve our deployment process across teams.
Task: I had to convince the other teams to adopt my proposal.
Action: I wrote a doc, presented it in a meeting, and most people agreed it was a good idea. We rolled it out across the teams.
Result: The deployment process improved and everyone was happy.

Why this is weak

Common pitfalls

×Stories where the candidate had de facto authority (their manager championed it, the project was already prioritized). That's not leadership without authority.

×Skipping the proof-point step. Strong stories include a cheap concrete artifact (prototype, doc, data) the candidate built before asking others to commit.

×'Everyone agreed.' Real cross-team work has at least one substantive disagreement. If your story has none, you're missing the part interviewers want.

×Framing influence as winning. Strong stories include moments where the candidate updated their proposal based on others' input.

×Stopping at 'I convinced them' without describing the mechanics. Senior interviewers want the technique, not the outcome.

×Failing to mention what you'd do if influence hadn't worked. Strong candidates know the escalation path and can describe when they'd use it.

×Junior-coded stories. If the cross-team scope is two engineers from a partner team for a week, that's collaboration, not leadership without authority. Senior+ stories involve multiple teams and meaningful duration.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'how did you decide who to talk to first?' - have a rationale. 'Started with the strongest critic / the team most affected / the most respected senior engineer' are all credible.

→If asked 'what if they had said no?' - your story should already include either a real no or a contingency. If neither, acknowledge that you didn't face a hard no in this story.

→If asked 'how did you balance this with your day job?' - real influence work has cost. Be specific about how you scoped it (X% of time, weekend prototype, traded off Y).

→If asked 'when do you escalate?' - have a heuristic. 'When peer-level options are exhausted and the cost of waiting exceeds the cost of escalation' is a strong frame.

→If asked about the people you mentored - have specifics. Names, what they learned, what they own now. Vague 'I helped them grow' reads as filler.

→If asked 'what would you do differently?' - the strongest answers identify a sequencing mistake (e.g., 'I'd talk to the strongest critic first, not last').