Why This Competency Matters

When interviewers ask 'tell me about a time you led without authority', they are not testing whether you can give orders. They are probing four signals at once:

[ Judgement ]      Did you pick the right battle and the right approach?
[ Ownership ]      Did you take the outcome on as yours, despite no formal mandate?
[ Communication ]  Did you persuade through reasoning, not pressure?
[ Trust ]          Did the people you influenced come out willing to work with you again?

This probe shows up at every senior level and every company tier. At Big Tech it is often the explicit bar for L5 and above. At growth-stage companies it is the de facto bar for any role that crosses team lines, which by L4 onward is most of them. Even at startups, where titles are fuzzy, the question still gets asked because the work itself is mostly cross-team and mostly without formal authority.

The reason it is so universal: most consequential work in any engineering org happens across team boundaries, and the person driving it usually does not own those teams. Whether you are pushing a platform migration, getting a security fix prioritised on a peer team's roadmap, or aligning two services on a shared API, you are leading without authority. Interviewers want to know you can do this without burning bridges or stalling out.

How This Differs From 'Led A Team'

Candidates often answer this question with a story about leading their own team, which scores poorly because it tests a different competency. The distinction matters:

[ Led a team ]              You had reports or formal tech-lead status
[ Led without authority ]   You had no reports and no RACI ownership

In 'led a team', the levers available to you include 1-1s, performance feedback, project assignment, and escalation through your management chain. In 'led without authority', none of those levers exist. The person you are trying to influence does not work for you, does not have to take your meeting, and is not graded on the outcome you care about. Their priorities are set by their own manager and their own roadmap.

If your story relies on a sentence like 'I asked my report to take this on', it is not the right story for this prompt. Pick one where the people involved had no obligation to listen to you.

What Great Looks Like (Rubric)

Strong answers to this competency tend to score on six named signals. Hit four out of six and you are in the upper half of the candidate pool; hit all six and you are clearly above bar.

1. The problem you picked was actually the right problem.

Leading without authority is expensive. You spend social capital, you slow your own work, and you risk damaging a peer relationship. Strong stories show the candidate weighed whether the problem was worth that cost. 'I noticed the dashboards were a bit inconsistent' is too small. 'Our data team's incident dashboards were missing the auth service entirely, which had caused two p1s in the prior quarter to be misdiagnosed for over an hour' is the right scale.

2. You started by understanding the other side's incentives.

The peer team you are trying to influence has its own roadmap, its own constraints, and its own definition of success. Strong candidates do this work before pitching anything: a 30-minute conversation with the lead, a read of their team's OKRs, a look at their open headcount. The pitch then maps your problem onto something they already care about, rather than asking them to absorb a cost for your benefit.

3. You used data to make the case, not pressure.

The most reliable lever in a no-authority situation is a defensible quantitative case. Numbers neutralise hierarchy: a senior peer cannot wave away '$300K of customer credits issued for incidents tied to this gap' the way they can wave away 'I think this is important'.

4. You treated escalation as a last resort, used surgically.

Escalation is a tool, not a failure. Strong candidates name it explicitly: 'I had a path to escalate to my director and theirs, and I had pre-aligned with my own manager on when I would use it, but my goal was to land the change without pulling that lever'. Weak candidates either escalate too early (which damages the relationship) or never (and stall out for months).

5. The other side came out willing to work with you again.

The single highest-signal sentence in any of these stories is the closer: 'six months later, when the security team had a similar request from us, the same lead reached out to me directly to scope it'. That sentence tells the interviewer the influence was healthy, not coercive.

6. You owned the outcome regardless of how the credit landed.

In no-authority situations, the team that ships the change usually gets the credit, not the person who pushed for it. Strong candidates do not litigate this; they take the result on as theirs and let the credit fall where it falls. The interviewer reads this as maturity.

The Four Mechanisms of Influence

There are exactly four reliable mechanisms candidates use to influence without authority. Most strong stories use two or three of them in combination.

1. Data. A defensible quantitative case for the change. Cost of inaction in dollars, incident time, customer impact, or engineer hours. This is the single most portable mechanism because it works across cultures, levels, and team boundaries.

2. Relationships. The trust capital you have built with the people involved. A peer is far more likely to listen if you have helped them in the past, attended their team's design reviews, or showed up to their on-call retro. Relationship capital is real and renewable, but only if you spend it intentionally.

3. Framing. How the change is positioned. The same proposal can be framed as 'you should do this for me' (low-conversion) or 'here is a small piece of work that will make your team's incident burden visibly lower next quarter' (high-conversion). Strong candidates frame in terms of the other team's outcomes, not their own.

4. Escalation as leverage. The credible possibility of escalation, not the act of escalating. When a peer knows you have a clean path to your director and theirs, and that you would rather not use it, they often resolve the disagreement at your level. This works only if the threat is real and only if you use it sparingly.

Avoid these counterfeits, which feel like influence but score poorly:

• Pressure. 'I told them this was urgent and they had to fix it.' Reads as entitled.
• Hierarchy laundering. 'I told them my director said it had to ship.' Reads as borrowing authority you do not have.
• Going around. Scoping the work to their team without involving the lead. Reads as dishonest and burns the relationship.

Common Questions & Model Answers

The six prompts below cover roughly 90% of how this competency is probed. Each model answer is the kind of two-minute STAR answer that scores on the rubric above. Read them as templates: the structure, the level of specificity, the placement of the trade-off and the reflection.

Prompt 1: 'Tell me about a time you led without formal authority.'

Model answer (strong)

'In Q3 2023 I was an L5 engineer on the platform team at a 600-person SaaS company. We had been getting paged regularly because the auth service, owned by the security team, was not emitting structured logs to our central pipeline. Our incident tooling was useless for any auth-related page and on-call engineers were spending an average of 35 minutes manually grepping logs before they could even start root-causing. I did not own the auth service and my manager did not have a reporting line into security.

I took it on because we had had two p1s in the prior quarter where the time-to-diagnose was the dominant cost, and I had a credible path to fix it.

I started by spending 45 minutes with the security tech lead, mostly listening. Their team's quarterly priorities were a credentials rotation programme and an SSO migration, and they had no headcount for tooling work. They were not opposed to logging fixes, they just had no slack. I then pulled three months of incident data: 11 incidents tagged auth, average 35 minutes spent on log archaeology, roughly $80K in support cost across them. I drafted a one-page proposal that scoped the smallest version of structured logging that would close the gap, estimated at about three engineering days, and offered to do most of the implementation work myself if their lead would review the PR. I framed it explicitly as reducing their team's incident burden, not ours. They said yes within a day. I had pre-aligned with my own manager that if the security director pushed back I had a clean escalation path, but I never needed it.

The change shipped two weeks later. In the next quarter we had four auth-related pages and average time-to-diagnose dropped from 35 minutes to 6. Six months later, when our team needed a small change in the auth service, the same lead pinged me directly to scope it. The thing I would do differently is involve their PM in the framing earlier; I went engineer-to-engineer and left the PM to be informed second-hand, which slowed the formal scheduling by about a week.'

What lands: a real problem with a quantified cost, time spent listening before pitching, a data-backed proposal, a small ask not a large one, an offer to do the work, an explicit escalation plan held in reserve, and a closing sentence that demonstrates the relationship survived. The reflection is specific behavioural change, not a generic learning.

Prompt 2: 'Describe a project where you influenced a peer team's decision.'

Model answer (strong)

'In Q4 2022 I was a senior backend engineer at a payments startup and our analytics team was about to standardise on a new event schema across the company. Their proposal would have required our service to emit two events for every transaction (a wire and a settlement), but the way they had defined the wire event would have broken our exactly-once guarantees because the event boundary did not align with our database transaction boundary. I had no authority over the analytics team's roadmap.

I owned getting the schema right for our service before it locked.

I started by reading their proposal end to end and writing down what they were optimising for, which turned out to be query simplicity for the analytics warehouse, not transactional correctness. I then wrote a two-page response that did three things: agreed with their goal, named the specific case where their schema would produce double-counts in our service, and proposed a small adjustment that preserved their query simplicity for 95% of cases while letting our service emit a single combined event. I sent it to their lead with an explicit ask to review before the proposal locked, and offered a 30-minute pairing session to walk through it. They came back with a refinement that was actually better than mine, and the final schema shipped with our case handled cleanly.

The schema went out company-wide a month later, our service was correct on day one, and the analytics team avoided what would have been a painful retroactive fix on warehouse data. Looking back, I should have caught this earlier; their proposal had been in draft for two weeks and I only flagged it three days before lock. I now block 30 minutes a week to skim cross-team RFCs that touch my surface area.'

What lands: technical specificity (exactly-once vs. event boundary), a written response that engages their goal first, a small ask with a working session offered, the other team's expertise being credited (their refinement was better), and a process change as the reflection.

Prompt 3: 'Walk me through a time you got buy-in from a senior stakeholder.'

Model answer (strong)

'In Q2 2024 I was an L5 engineer at FintechCo and I was advocating to spend a quarter rebuilding our reconciliation pipeline. The CFO was the funding decision-maker, was sceptical about infra investment, and I had never spoken with them directly. My manager was supportive but did not have the relationship either.

I owned getting the funding case in front of the CFO in a form they could decide on.

I worked backward from what the CFO actually cared about: incident-driven customer credits, audit risk, and finance closing speed. I built an ROI doc that quantified the prior year as about $1.2M in incident cost across those three categories, broken down by source. The proposal asked for $300K in additional headcount over two quarters. I deliberately did not lead with technical content; the doc had one diagram and the rest was framed in finance language. I asked my manager to forward it to the CFO with a 15-minute meeting request, and went into that meeting having pre-read every objection I could anticipate. The CFO asked two questions, both about the audit risk number, and approved the funding within three weeks.

In the year after the funded hiring landed, our p1 incident count dropped from 14 to 5, customer credit spend went from about $400K to $90K, and the CFO mentioned the project unprompted in a board update. I learned to lead with cost-of-inaction rather than feature aspiration when pitching infra to non-technical stakeholders, and I now use the same framing for any cross-functional ask above $100K.'

What lands: an explicit translation between engineering and finance language, working backward from the stakeholder's actual decision criteria, a defensible ROI chain, anticipation of objections, and a generalised lesson the candidate now applies to other situations.

Prompt 4: 'Tell me about a time your influence attempt did not work.'

Model answer (strong)

'In Q1 2023 I was a senior engineer on the storage platform and I tried to convince a peer team to migrate off a deprecated client library that we had been planning to retire for six months. The library had two known correctness bugs and was generating about 15% of our support load. The peer team was working flat-out on a launch and the library worked well enough for their use case.

I owned the migration push and I did not succeed in getting it done that quarter.

I made three mistakes in retrospect. First, I framed the request in terms of our team's pain (15% of our support load) rather than theirs, which gave them no reason to prioritise it. Second, I made the ask too big: a full migration in one sprint, when half the value would have come from migrating just the read path. Third, when their lead said no in the first conversation, I took it as final rather than asking what would change their answer. They were not opposed in principle; they had no slack for a full migration before launch.

The library was migrated the following quarter, after their launch shipped, and the support load eventually dropped from 15% to under 2%. The thing I changed in how I work: I now lead any cross-team ask with a small, optional first step ('would you be open to migrating just the read path before launch'), which gives the other team a way to say a partial yes instead of a full no. I have used this in three subsequent migrations and it has shortened the average time-to-yes from about six weeks to two.'

What lands: an honest 'I did not succeed', three specific mistakes named without blame, an outcome that eventually landed (so the story is not a write-off), and a behavioural change the candidate now uses repeatedly.

Prompt 5: 'Describe a time you had to influence someone more senior than you.'

Model answer (strong)

'In Q3 2024 I was an L4 engineer and our staff engineer was about to greenlight a new microservice that, in my reading, was duplicating a service that already existed two team boundaries away. I was several levels below them and had only worked with them on one prior project.

I owned flagging the overlap before the design doc locked, even though it was not my call to make.

I sent them a short message: I noticed an overlap with service X owned by team Y, I had spent 30 minutes reading both, here are the three differences I see, and I am happy to be wrong if I am missing something. I deliberately framed it as a question rather than a challenge, because I genuinely was not sure I had the full picture. They came back within a day, said they had not been aware of service X, and asked if I could set up a 30-minute meeting between the three teams. After that meeting we converged on extending service X rather than building a new one, which saved roughly six engineer-weeks of duplicated work and avoided an ownership ambiguity that would have been painful long-term.

The thing I take away is that 'influencing up' is mostly about presenting the information in a way that lets the senior person make a better decision, not about winning an argument. The staff engineer thanked me explicitly for the framing, and I have used the same opener (here is what I see, I might be missing something) in every up-the-chain disagreement since.'

What lands: humility paired with substance, the framing as a question rather than a challenge, the senior person being credited with the decision, a real saved-cost number, and a generalised technique the candidate now reuses.

Prompt 6: 'Tell me about a time you had to push back on a peer.'

Model answer (strong)

'In Q2 2023 our team's tech lead and I disagreed about whether to invest a sprint in test coverage for a service we owned together. They wanted to ship a new feature first; I thought the existing 40% coverage was already costing us in escaped bugs. We were peers and there was no manager to break the tie.

I owned getting to a decision rather than letting the disagreement stall the team.

I pulled six months of incident data: of 14 production bugs, 9 had touched code paths with no test coverage, with average rollback time of 38 minutes. I did not present this as a debate. I shared the data in our 1-1, said 'I think this changes the call but I want to hear your read', and listened. Their concern was legitimate: if we slipped the feature, our customer commitment to a key account would slip too. We landed on a smaller version of both: a one-week investment in coverage on the highest-risk paths (the ones that had caused 6 of the 9 incidents), then ship the feature on the original timeline. Both of us were a little uncomfortable with the compromise, which I read as a sign that it was probably the right call.

Coverage on the high-risk paths went from 22% to 78%, and over the next two quarters we had no production incidents on those paths. The feature shipped on time. What I learned: when I am pushing back on a peer, I do better when I bring the data without pre-deciding the answer. I now intentionally separate the data conversation from the decision conversation, with at least a day in between, so neither of us feels cornered.'

What lands: a real disagreement with a real peer (not a strawman), data brought without pre-deciding, the other person's concern being honoured, a compromise that was a partial yes for both, and a process change as the reflection.

Pitfalls Specific to This Competency

Four traps that show up most often in 'leading without authority' answers:

1. The disguised 'led a team' story. The candidate tells a story where they had a reporting line, a tech-lead title, or a clear RACI mandate, and frames it as 'without authority' because the role was new or the title was informal. Interviewers catch this in follow-up. Pick a story where you genuinely had no formal lever.

2. Borrowed-authority framing. 'I told them my director needed it done.' This reads as launder-by-hierarchy and undermines the entire competency. If the director was actually involved, name them and explain how the escalation worked; if not, do not mention them.

3. The pressure-as-influence story. 'I kept pushing until they agreed.' This is not influence; it is attrition. The interviewer will read it as a relationship cost the candidate did not pay attention to. Strong stories close with the relationship being intact or improved, not just the outcome being achieved.

4. Skipping the listening step. Stories that go straight from 'I noticed a problem' to 'I pitched a solution' are missing the most important beat: understanding the other team's incentives. Even one sentence ('I spent 30 minutes with their lead before writing anything') signals that the candidate did the work.

Practice Prompts & Exercises

For each prompt below, draft a 200 to 300 word STAR answer using a real story from your career. Then run it against the six-signal rubric in 'What Great Looks Like' and mark which signals you actually hit. Most candidates will fail at least two on a first draft.

1. Tell me about a time you got a peer team to prioritise something that was not on their roadmap.
2. Describe a moment when you had to influence a decision you did not own.
3. Walk me through a cross-functional project where you were the de facto lead without the title.
4. Tell me about a time you persuaded a more senior engineer to change their mind.
5. Describe a situation where you needed buy-in from a stakeholder you barely knew.
6. Tell me about a time you tried to influence someone and it did not work.
7. Describe a time you had to push back on a peer's plan without burning the relationship.

For every story, write down two things at the end: the mechanism of influence you used (data, relationships, framing, escalation as leverage) and the closing sentence that proves the relationship survived.

Bridge / Cross-References

If you have not yet completed the relevant Foundations lessons, the following are the most useful inputs to this competency:

• star-method and story-banking give you the structure and the inventory of stories you draw from.
• crafting-compelling-stories gives you the narrative shape (hook, conflict, resolution) that the model answers above use.
• quantifying-impact is the lesson that backs up the data-as-influence mechanism. Most of the cost-of-inaction numbers in these answers come straight from that lesson's rubric.
• tailoring-stories-to-role covers level calibration: the same influence story is told differently for an L4, an L5, and a staff role.

The next lesson in this category, Taking Initiative & Ownership, picks up where this one leaves off. Where this lesson is about influencing people you do not control, that one is about acting on problems nobody asked you to solve. The two competencies overlap in roughly half of the stories candidates bank, so several of the prompts above can be reframed as initiative stories with light editing.