Plenty of individual contributors go blank when an interviewer asks them to describe a time they showed leadership. They’ve never managed anyone, so they assume they have nothing to say. They usually do. The question gets asked of nearly every engineer, not just aspiring managers, and it isn’t about authority. It’s about whether you make things around you work better when nobody has asked you to.
What leadership means when you don’t manage anyone
For an engineer without direct reports, leadership tends to look like a few specific behaviors:
- Creating clarity. Turning a confusing situation into a plan people can follow: who owns what, what happens when.
- Coordinating. Getting several people or teams moving in the same direction.
- Raising the standard. Better reviews, better docs, a practice the team adopts.
- Helping others succeed. Unblocking a colleague, making a newcomer productive.
Notice what isn’t on the list: telling people what to do, or doing everyone’s work. Persuading another team to adopt your idea is a related but different story, about influence; this one is about making a group function.
Finding your own leadership stories
If nothing comes to mind, try these prompts. When did a discussion go in circles until you wrote a summary and proposed a next step? When did you notice that something important had no owner, and pick it up? When did you organize a launch, run an incident review or put together onboarding for someone new? When did a teammate do better work because of something you set up?
Each of those can be a leadership story. The size matters less than whether you saw a gap and acted on it.
Worked example: a launch nobody was coordinating
Here’s an illustrative scenario. Use the structure; the details of your own story will be different.
A new notification-preferences feature is launching across web, mobile and backend, built by three teams, two weeks from release. Several responsibilities have no owner: the rollback plan, the order in which feature flags are switched on, briefing support, and checking that email unsubscribes still work, which the company is legally required to honor. In a standup, the backend engineer (the candidate) realizes two teams each assume the other will turn on the flag.
A weak answer (illustrative):
I’m a natural leader. During a big launch I took charge, told everyone what they needed to do and made sure it all got done. Honestly, without me it would have been a mess.
“Told everyone what to do” suggests control the candidate didn’t have. “Without me it would have been a mess” takes credit from three teams. And there’s no detail about what was actually done.
Stronger version (illustrative; adapt to a situation you were really in):
We were two weeks from launching notification preferences across web, mobile and backend. In a standup I realized the web and mobile teams each thought the other was switching on the feature flag, which made me wonder what else had fallen between the teams.
That afternoon I wrote a one-page launch checklist listing every task I could think of, with an owner column, and left the unowned ones blank. There were five blanks, including the rollback plan, the support briefing and a check that unsubscribe links still worked. I set up a thirty-minute meeting with one person from each team and the product manager, put the list on screen and asked people to take the items closest to their work. Most blanks filled in the meeting. I took the rollback runbook and the support briefing myself, and the product manager took the unsubscribe question to legal.
Two days before launch I ran a dry run in staging using the checklist, which caught that the mobile flag had to go on after the backend one. The launch went smoothly apart from one known issue with older Android app versions, which support already had a note for. The three teams did the build; my part was making the gaps visible and getting them owned. The checklist became our template for later launches.
The candidate saw a gap, made it visible instead of quietly working around it, asked rather than assigned, took on some work personally, and credited the teams for the build.
Coordination isn’t control
The question interviewers often ask next is “How did you get people to do things when you weren’t their manager?” The honest answer is usually that you didn’t make them. You made the gaps visible, so it was obvious something needed doing, and you asked.
Atlassian’s Team Playbook has a Roles and Responsibilities exercise built on the same idea: list the responsibilities, agree who holds each one, and identify the ones nobody has. A blank cell in a shared document is persuasive in a way that “someone should really own the rollback plan” isn’t.
Respecting other people’s priorities matters too. If a team couldn’t take an item because of their own deadline, a strong answer says you went to their lead or the product manager with the gap as a risk, not as a complaint about that team.
Giving credit accurately
Leadership stories have a particular credit problem. The result usually belongs to a group, and your contribution was enabling it. Say both, plainly: “The three teams built it; I organized the launch plan and closed the gaps.” Claiming the launch makes you sound like you took credit for others’ work. Saying “I just helped a bit” hides the part the interviewer is trying to evaluate.
Mistakes that weaken the answer
- “I took charge.” Without authority, that usually means overstepping, or it means you didn’t describe what you actually did.
- Doing everything yourself. Staying up to write the rollback plan, the support doc and the flag script alone is heroics, and it doesn’t scale.
- Using a formal title. A story from when you were acting team lead is fine, but it doesn’t answer the “without authority” version of the question.
- Leadership as a trait. “I’m a natural leader” is a claim; the story is the evidence.
- Leaving out resistance. If someone pushed back, how you handled it is often the most interesting part.
Follow-up questions to expect
“What if a team had refused to take an item?” Raise it with their lead or the product manager as a launch risk, with a suggested owner, and keep it on the checklist as unowned until resolved.
“How did your manager react?” Ideally you kept them informed. Leadership without authority still works within the team’s structure.
“Would you do this for every launch?” A good answer talks about making it repeatable, like turning the checklist into a template so the next launch doesn’t depend on you noticing.
Interview practice: improving how the team works
A common variation: “Tell me about a time you improved a process on your team.” Suppose your team’s pull requests wait an average of three days for review. How would you tell a leadership story about fixing it?
Answer and reasoning
Start with evidence rather than frustration. You might have pulled the numbers from your code host: average time to first review, and how many PRs waited more than two days. Numbers make the problem concrete for everyone, not just you.
Then describe how you proposed a change instead of imposing one. For example, you suggested a two-week experiment in a team meeting: a daily review rotation, with one person each day responsible for first reviews, and a soft limit on PR size. Making it an experiment lowers the cost of agreeing.
Measure and adapt: after two weeks, perhaps time to first review fell to under a day, but people found the rotation disruptive on days with heavy meetings, so the team adjusted it together. End with credit and continuity: the team adopted it, and it kept running when you went on holiday, which is the real test of whether you built a process or just did the reviews yourself.
Related guides
- Behavioral and HR interview questions
- Behavioral and HR multiple-choice questions
- Behavioral: Influencing Without Authority, the persuasion side of the same question
- Explaining Project Ownership in an Interview
- Atlassian Team Playbook: Roles and Responsibilities