Leadership Stories

Leadership without a title

In NZ tech interviews, when they ask about leadership, they are not asking whether you have managed a team of 20 people. They want to know if you can drive outcomes without relying on authority. This is sometimes called "influence without authority" or "leading from the IC track."

The best leadership stories come from everyday engineering work: proposing a technical direction, mentoring someone, aligning teams on a standard, or taking ownership when nobody else will. You have done these things. The challenge is recognising them as leadership and learning to tell them well.

Five types of leadership stories

1. Driving technical direction

This is about proposing and championing a technical change that improved the team or organisation.

Common scenarios:

• Writing an RFC or design document for a new approach
• Proposing a migration from one technology to another
• Introducing a new practice (testing strategy, observability, CI/CD)
• Identifying and addressing technical debt

Story example: RFC for API versioning

I noticed that our team and two other teams were independently building breaking changes into shared APIs without coordination, causing integration failures every sprint. I drafted an RFC proposing a versioning standard with semantic versioning for all internal APIs, a deprecation policy, and a shared changelog. I circulated it to all three teams, collected feedback over two weeks, revised it twice, and presented the final proposal at an engineering all-hands. The standard was adopted company-wide. API-related incidents dropped from an average of 3 per sprint to zero over the following quarter.

Why this works: You identified a problem nobody else was addressing, you proposed a structured solution, you built consensus across teams, and you can point to measurable improvement.

2. Mentoring and growing others

This is about investing in someone else's growth and creating lasting impact beyond your own code.

Common scenarios:

• Onboarding a new team member effectively
• Pair programming with junior engineers
• Code review as a teaching tool
• Helping someone navigate a promotion or career decision
• Creating learning resources for the team

Story example: Pair programming culture

When I joined the team, code reviews were contentious. Comments felt like criticism, and junior engineers dreaded submitting PRs. I proposed a weekly pair programming session where a senior and junior engineer would work on a real task together. I started by pairing with each junior myself, demonstrating how I think through problems, ask questions, and make decisions. I made my own mistakes visible during pairing to normalise the learning process. Within two months, three other senior engineers had started doing the same. PR review turnaround time dropped by 40% because reviewers already had context from pairing. More importantly, two junior engineers told me in their quarterly reviews that pair programming was the single most helpful thing for their growth.

Why this works: You did not just mentor one person; you shifted a team dynamic. You led by doing, not by mandating. The result includes both metrics and human impact.

3. Cross-team influence

This is about aligning multiple teams or stakeholders around a shared goal when you have no authority over them.

Common scenarios:

• Getting buy-in from another team on a shared standard
• Coordinating a cross-team migration or rollout
• Resolving competing priorities between teams
• Building a shared library or platform that multiple teams use

Story example: Shared component library

Three frontend teams were independently building the same UI components, each with slight variations. This caused visual inconsistency and tripled the maintenance burden. I proposed creating a shared component library. Rather than just building it myself, I invited one engineer from each team to a working group. We met weekly for an hour to agree on component APIs, review contributions, and plan migration of existing code. I specifically chose not to dictate the architecture, instead facilitating discussions and letting each team feel ownership. I did take responsibility for the CI pipeline, documentation site, and versioning strategy since those were cross-cutting concerns that needed someone to own them. After three months, the library had 30 components and was used by all three teams. Design consistency issues in QA dropped by 60%.

Why this works: You recognised a systemic problem, built a coalition, facilitated rather than dictated, and still took ownership of the glue work that nobody else wanted to do.

4. Taking ownership in ambiguity

This is about stepping up when the path is unclear and nobody is directing traffic.

Common scenarios:

• A production incident where no one knows who is responsible
• A new project with unclear requirements
• An organisational change that creates confusion
• A technical problem that spans multiple teams' domains

Story example: Owning the grey area

We had a recurring issue where customer data sync between our CRM and our application would silently fail, causing support tickets. The CRM was owned by the sales ops team, the sync job was owned by the platform team, and the application was owned by my team. Each team assumed it was someone else's problem. I volunteered to investigate end-to-end. I spent two days tracing the full data flow, documented every failure point, and created a shared dashboard showing sync health. I then set up a 30-minute meeting with one engineer from each team where I walked through my findings and proposed a simple fix: adding idempotency keys and retry logic to the sync job, plus alerting when sync lag exceeded 5 minutes. The platform team implemented the fix with my guidance, and sync failures dropped from about 15 per week to under 1.

Why this works: You did not wait for someone to assign this to you. You stepped into the gap, did the unglamorous investigative work, and coordinated a fix across organisational boundaries.

5. Building team processes

This is about creating or improving the systems that make teams effective.

Common scenarios:

• Introducing or improving retrospectives
• Setting up CI/CD, monitoring, or alerting
• Creating runbooks or on-call procedures
• Improving the hiring or onboarding process
• Establishing team working agreements

Story example: Retro that actually changed things

Our team had retrospectives every two weeks, but nothing ever changed. People would raise the same issues repeatedly and feel unheard. I proposed a new format: each retro would end with exactly two action items, each with a specific owner and a deadline. I also introduced a "retro of the retro" at the start of each session where we would check whether last sprint's action items were completed. If they were not, we would discuss why before moving on. I volunteered to facilitate the first four retros to model the new approach. Within two months, the team had completed 14 out of 16 action items. The biggest win was automating our test data setup, which had been complained about for six months but never addressed. Team satisfaction scores in our quarterly survey went from 3.2 to 4.1 out of 5.

Why this works: You improved how the team works, not just what the team builds. You made the change sustainable by building accountability into the process itself.

Story crafting framework

Use this framework to turn a raw experience into a polished leadership story.

Step 1: Identify the leadership moment

Ask yourself: "What would NOT have happened if I had not been there?" If you cannot answer that, it might not be a strong leadership story.

Step 2: Find the tension

Every good story has tension. What was the challenge, the risk, or the resistance you faced? Stories without tension are boring.

• Technical tension: "The system was failing and we did not know why"
• People tension: "The team disagreed on the approach"
• Organisational tension: "No one owned this problem"
• Time tension: "We had two weeks to deliver a four-week project"

Step 3: Show your thinking

Do not just describe what you did. Explain WHY you made the choices you did. This shows your judgment, which is what they are really evaluating.

• "I chose to write an RFC rather than just implementing it because I needed buy-in from three teams"
• "I started with the smallest possible pilot because I had learned from a previous failure that big-bang rollouts do not work"
• "I paired with her rather than just reviewing her code because I could see the feedback was not landing in written form"

Step 4: Land the impact

End with results that matter. Quantitative is best, but qualitative impact on people or processes is also powerful.

Tailoring for seniority levels

The same story can be told differently depending on the level you are interviewing for.

Intermediate (mid-level)

Emphasise: taking initiative within your team, learning from senior engineers, growing from IC to someone who helps others.

"I noticed that our test suite was flaky and slowing down the team. I spent two days investigating, identified the three most problematic tests, fixed them, and documented the patterns to avoid. Test suite reliability went from 80% to 98%."

Senior

Emphasise: influencing beyond your immediate work, mentoring, making decisions with trade-offs, driving technical direction.

"I noticed that flaky tests were a systemic problem across three teams. I proposed and led a cross-team working group to establish testing standards. I wrote a shared testing utilities library and facilitated knowledge-sharing sessions. Across all three teams, test reliability improved from 80% to 97%."

Staff / Principal

Emphasise: organisational impact, changing how the company works, enabling other leaders, thinking in systems.

"I identified flaky tests as a symptom of a deeper problem: teams did not have a shared understanding of testing strategies, and our CI infrastructure did not support reliable test isolation. I wrote an engineering-wide RFC proposing a testing philosophy, invested in CI improvements with the platform team, and created a testing guild that met monthly. Over six months, company-wide test reliability went from 80% to 96%, and mean time to merge dropped by 30%."

Practice prompts

Use these to rehearse your leadership stories:

1. "Tell me about a time you influenced a technical decision across teams"
2. "Describe a situation where you took ownership of something outside your job description"
3. "How have you helped someone on your team grow?"
4. "Tell me about a process or practice you introduced to your team"
5. "Describe a time you led a project without being the formal leader"

For each one, identify which story from your bank fits best, then practice telling it in under 3 minutes using the STAR framework.