Learning Materials/Leadership

Leadership for Engineers

Lead without authority and grow those around you.

Leadership in engineering isn't about titles - it's about influence, initiative, and service to others. A junior engineer leads by owning a feature end-to-end. A senior engineer leads by mentoring teammates and driving technical decisions. Principals and architects lead by shaping organizational direction and developing other leaders.

This guide explores what technical leadership means at every level, drawing on research about staff engineering archetypes, decision-making frameworks, and the difference between mentorship and sponsorship.

Leadership Without Authority

The Myth of Positional Power

The most effective engineering leaders often have no direct reports. They lead through influence, not authority. Will Larson, author of "Staff Engineer," observes that Staff-plus engineers "keep doing much of what made them successful as Senior engineers: building relationships, writing software, coordinating projects. However, that's a misleading answer. Staff engineers do those same tasks, but whereas previously they were the core of their work, now they're auxiliary tasks."

The shift is from individual contribution to organizational contribution - from writing code to multiplying others' ability to write code.

Leading from Where You Are

You don't need permission or a title to demonstrate leadership. Every engineer can lead:

Junior engineers lead by:

  • Taking ownership of a feature from start to finish
  • Documenting what they learn for others
  • Asking questions that uncover unstated assumptions
  • Following through on commitments reliably

Mid-level engineers lead by:

  • Mentoring newer team members
  • Driving technical discussions toward decisions
  • Improving team processes and tooling
  • Representing the team in cross-functional contexts

Senior engineers lead by:

  • Setting technical direction for projects or domains
  • Building consensus around architectural decisions
  • Developing other engineers deliberately
  • Bridging between technical and business concerns

Staff+ engineers lead by:

  • Shaping organizational technical strategy
  • Speaking for technology in rooms where decisions happen
  • Exploring ambiguous, high-risk problems
  • Developing senior engineers who develop others

Building Influence Without Authority

The most effective technical leaders create change without formal power. Here's how:

Build technical credibility first: People follow those they trust to be right. Ship good code, make sound technical decisions, and demonstrate you understand the systems you're trying to influence.

Create coalitions: Before proposing a change, talk to stakeholders individually. Understand their concerns. Address them in your proposal. Arrive at the meeting with allies, not just arguments.

Lead with questions, not declarations: Instead of "We should use X," try "What would it take for us to use X? What concerns would we need to address?" Questions invite collaboration; declarations invite resistance.

Make others successful: Help colleagues achieve their goals. When you've helped others succeed, they're more likely to support your initiatives.

Write things down: Documented proposals, RFCs, and decision records create artifacts that carry your thinking into rooms you're not in.

Be patient with timing: The right idea at the wrong time gets rejected. Watch for windows of opportunity - when a system fails, when priorities shift, when new leadership arrives.

Accept "not now" gracefully: Sometimes good ideas don't get adopted. If you push too hard, you burn social capital. Plant seeds, step back, and try again later.

Staff Engineer Archetypes

Will Larson's research identified four distinct archetypes of Staff-plus engineering roles. Understanding these helps clarify what leadership looks like at senior technical levels.

The Tech Lead

Tech Leads guide a team or small group of teams in their approach and execution. They're comfortable scoping complex tasks, coordinating their team toward solving them, and unblocking work along the way.

Earlier in their career they will have implemented their team's most complex technical projects, but at this point they default to delegating such projects across the team. They do this both to grow their teammates and in acknowledgement that their team's impact grows as their coding blocks shrink.

The Tech Lead is the most common entry point to Staff engineering because the day-to-day work is most similar to what you'd already be doing as a Senior Engineer.

The Architect

Architects are responsible for the success of a specific technical domain - API design, frontend stack, storage strategy, cloud infrastructure. For a domain to merit an Architect, it must be both complex and enduringly central to the company's success.

There is a toxic perception that Architects design systems in isolation, pass their designs to others to implement, and mandate their adoption, but that reciting that stereotype would slander the successful architects I spoke with.

Effective architects dedicate energy to maintaining intimate understanding of business needs, user goals, and technical constraints. They wield that insight to identify and advocate for effective approaches, leading constellations of teams despite limited organizational authority.

The Solver

Solvers are trusted agents who go deep into knotty problems, continuing until they're resolved. They're moved onto problems identified by leadership as critical - those lacking a clear approach or with high execution risk.

The Solver operates on problems already identified as organizational priorities, requiring less organizational wrangling than other archetypes. However, they generally stop working on problems once contained, which can feel transient.

The Right Hand

The Right Hand is the least common archetype, appearing as organizations reach one thousand or more engineers. They operate like a senior organizational leader without direct managerial responsibilities.

Rick Boone compared his role to the Hand of the King in Game of Thrones and Leo McGarry from The West Wing, operating with the borrowed authority of a senior leader.

Right Hands attend their leader's staff meetings and work to scale that leader's impact by removing important problems from their plate. Problems at this level are never purely technical - they involve the intersection of business, technology, people, culture, and process.

Setting Technical Direction

Joy Ebertz, Staff Engineer at Box, describes what setting technical direction looks like in practice:

I feel most impactful when I can facilitate setting a technical vision for an area and get people moving toward that vision. I think we would all agree that we want our code to be better architected than it is or improved in some way. However, I've found that often people have some vague sense of wanting better without having a clear idea of what that thing they want is. I like to help the group decide on a shared understanding of where exactly they're trying to get (it's actually okay if we never get there) and come up with a general game plan of how to get there.

Speaking for Technology

"Much as the Lorax speaks for the trees in his popular children's book, Staff engineers speak for their companies' technology. Technology cannot speak for itself and requires effective advocates on its behalf."

Folks who successfully advance technology are:

  • Pragmatic: Focus on what's achievable, not just ideal
  • Deliberate: Make conscious choices rather than reactive ones
  • Long-term focused: View progress as a trend rather than individual decisions as crises

The Shift from Personal to Organizational

One constant across all roles is that the reality of setting technical direction is far more about understanding and solving the real needs of the organization around you and far less about prioritizing technology and approaches that you personally are excited to learn about.

This is a critical shift: in earlier roles, you may have tried to influence decisions toward technologies you were personally motivated by. In senior positions, you're accountable to the business and organization first, yourself second.

Decision Making

Reversible and Irreversible Decisions

Jeff Bezos frames decisions as one-way doors or two-way doors:

Some decisions are consequential and irreversible or nearly irreversible - one-way doors - and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don't like what you see on the other side, you can't get back to where you were before. We can call these Type 1 decisions.

But most decisions aren't like that - they are changeable, reversible - they're two-way doors. If you've made a suboptimal Type 2 decision, you don't have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.

The heuristic: Make reversible decisions as soon as possible. Make irreversible decisions as late as possible.

When to Decide

For reversible decisions, your biggest risk is dragging your feet. The cost of additional information isn't worth the delay.

For irreversible decisions, your biggest risk is deciding too early. The cost to reduce uncertainty is worth the time and effort.

Use the STOP, LOP, or KNOW framework:

  • STOP: You've stopped gathering useful information
  • LOP: You're about to lose an opportunity
  • KNOW: You know what to do

"The people that waited for the unicorn didn't last."

70% Certainty

Bezos considers 70% certainty as the cut-off point where it's appropriate to make a decision. Act once you have 70% of the required information, then quickly course-correct. This is more effective than waiting for 90% certainty.

A good plan, violently executed now, is better than a perfect plan next week. - General George Patton

The Courage to Decide

Engineering leadership often means making decisions with incomplete information. Indecision is a decision - usually the wrong one. When you have sufficient information:

  1. Commit: Make the decision clearly
  2. Communicate: Explain the reasoning
  3. Course-correct: Adjust as you learn

Leaders take responsibility for outcomes, not just for the quality of their decision-making process.

Developing Others

Mentorship vs. Sponsorship

Lara Hogan's influential piece "What Does Sponsorship Look Like?" distinguishes between two forms of developing others:

Mentorship is giving advice based on your experience. It's helpful, but limited.

Sponsorship is using your position and influence to create opportunities for others.

To sponsor someone is to feel on the hook to help get someone promoted. It is raising up the name of someone to help them get more opportunities to do visible, valuable work. It is not just giving advice and mentorship. Often, you can sponsor someone without them even knowing it.

Sponsorship in Practice

Sponsorship means noticing opportunities to raise people's names:

  • Suggesting someone who could lead a new project based on their experience
  • Recommending someone to facilitate a postmortem or lead a meeting
  • Suggesting someone to write a blog post about their recent project
  • Forwarding their email summary of a project to a different audience, underscoring what was interesting
  • Mentioning or sharing someone's work in team chat that you found helpful
  • Citing something you learned from someone to a group of influential folks

Any time you can, overtly or not, help those around you see the skill set or experience of someone, that's a sponsorship opportunity. The more you get practice doing this, the more opportunities you'll see.

Effective Delegation

Growing others requires giving them real work - not just tasks you don't want. Effective delegation:

Choose the right work to delegate:

  • Work that stretches someone's skills but won't break the project if they struggle
  • Work with clear success criteria so you can verify completion
  • Work that builds skills they need for their next level

Set up for success:

  • Provide context: why does this matter? What constraints exist?
  • Clarify expectations: what does "done" look like?
  • Agree on checkpoints: when will you check in?
  • Identify support: who can help if they get stuck?

Follow through:

  • Start with more frequent checkpoints, reduce as trust builds
  • Ask how it's going rather than checking up
  • Provide help when asked without taking over
  • Review outcomes, then let them own the work publicly

Common mistakes:

  • Delegating then disappearing (abandonment)
  • Delegating then micromanaging (undermining trust)
  • Taking back work at the first sign of struggle (rescuing)
  • Only delegating grunt work (not actually developing anyone)

Re-Engaging Disengaged Team Members

Sometimes talented people disengage. Signs include reduced participation, declining quality, or "I don't care" attitudes. Before concluding someone is a "performance problem," investigate.

Possible causes of disengagement:

  • Boredom: work isn't challenging enough
  • Frustration: obstacles outside their control
  • Neglect: feeling ignored or undervalued
  • Mismatch: working on things they don't care about
  • Personal issues: life outside work is hard
  • Burnout: they've been running too hard for too long

What helps:

  • Talk one-on-one: "I've noticed you seem less engaged lately. What's going on?"
  • Listen without problem-solving immediately
  • Ask what kind of work would be energizing
  • Look for obstacles you can remove
  • Consider whether a role change would help
  • Give meaningful work that connects to their interests

The goal isn't to "fix" someone - it's to understand what's blocking their contribution and address it.

Everyone Can Sponsor

Anyone can be a sponsor. Even other members of minoritized communities. Even brand new software engineers. Even people in other departments. While it's true that managers are uniquely positioned to give promotions to people, there are plenty of other people with influence around.

Look for opportunities where names are raised:

  • "The dashboards are slow today. Is there someone who knows how to fix that?"
  • "Sara's been doing a lot of perf research recently. Ask her too."

The people we name are naturally those we're closest to, whose work we're most familiar with. It takes deliberate effort to expand that circle.

Radical Candor

Kim Scott's Radical Candor framework provides a compass for leadership communication, built on two dimensions:

  1. Care Personally: Show genuine concern for people as humans
  2. Challenge Directly: Be honest about problems and improvement areas

The Four Quadrants

Radical Candor (Care Personally + Challenge Directly): The goal. You give specific, sincere praise and kind, clear criticism because you genuinely want people to succeed.

Ruinous Empathy (Care Personally, Don't Challenge): You want to spare someone's short-term feelings, so you don't tell them something they need to know. It may feel nice, but it's ultimately unhelpful. "Praise that isn't specific enough to help the person understand what was good, or criticism that is sugar-coated and unclear."

Obnoxious Aggression (Challenge Directly, Don't Care Personally): Also called brutal honesty. You challenge someone directly but don't show you care about them personally. "Praise that doesn't feel sincere or criticism that isn't delivered kindly."

Manipulative Insincerity (Neither Care nor Challenge): The worst quadrant. "Praise that is insincere, flattery to a person's face and harsh criticism behind their back."

Caring Personally

Your entire working life you've been told to be professional. Too often, that's code for leaving your humanity at home. To build strong relationships, you have to Care Personally.

This can be as simple as showing vulnerability - admitting when you're having a bad day and creating safe space for others to do the same.

Challenging Directly

Since you learned to talk you've likely been told some version of, 'If you don't have anything nice to say, don't say anything at all.' Then you become the boss and the very thing you've been taught not to do since you were 18 months old is suddenly your job.

Challenging people is often the best way to show you care. It doesn't mean whatever you think is the truth; it means you share your humble opinions directly.

Receiving Feedback

Leaders don't just give feedback - they model receiving it well. How you respond to feedback teaches your team whether it's safe to give you feedback at all.

Good practices for receiving feedback:

  • Thank the person for the feedback, even if it stings
  • Ask clarifying questions: "Can you give me an example?"
  • Resist the urge to defend or explain immediately
  • Take time to process before responding substantively
  • Act on feedback visibly so people see it matters
  • Follow up: "I've been working on X - have you noticed a difference?"

What undermines feedback culture:

  • Becoming defensive or dismissive
  • Explaining away every criticism
  • Agreeing in the moment but never changing
  • Punishing people who give you hard feedback
  • Only accepting positive feedback

The leader who can't receive feedback creates a team that stops giving it.

When to Give Feedback

Timing matters as much as content. The right feedback at the wrong time often backfires.

Give feedback immediately when:

  • The issue is small and easily corrected
  • The person can still change course
  • Delay would allow bad patterns to reinforce
  • You're in private and there's time for discussion

Delay feedback when:

  • Emotions are running high (yours or theirs)
  • You're in a public setting
  • The person is dealing with something urgent
  • You need time to organize your thoughts
  • You're not sure your reaction is proportionate

Never delay when:

  • Safety or ethics are involved
  • The behavior is affecting others who can't wait
  • Delay would be seen as endorsement

The goal is feedback soon enough to be relevant, but not so soon that it can't be heard.

Taking Ownership

"That's Not My Job" is the Opposite of Leadership

Leadership means caring about outcomes, not just assigned tickets. When you see a gap, you have options:

  1. Fill it yourself: Just do the work
  2. Raise visibility: Make sure the right people know
  3. Propose a solution: Come with ideas, not just problems
  4. Coordinate others: Help organize a response

The anti-pattern is walking past problems because they're outside your scope.

Modeling Behavior

Want better code reviews? Write exemplary ones. Want better documentation? Document excellently.

This is leading by example rather than by mandate. The most effective leaders demonstrate the standards they want to see:

  • Write the design docs they wish others would write
  • Give the feedback they wish they received
  • Document the decisions they wish predecessors had documented

Taking Responsibility for Failures

Leaders own mistakes - their own and their team's. Blame is the opposite of leadership.

When things go wrong:

  1. Acknowledge: Accept responsibility publicly
  2. Analyze: Understand what happened without blame
  3. Address: Fix the immediate problem
  4. Adjust: Change systems to prevent recurrence

The leader who says "I'm responsible for this outcome" creates psychological safety. The leader who says "who screwed this up?" destroys it.

Servant Leadership

Serve Your Team

The best leaders remove obstacles, provide air cover, and enable others to do their best work. This inverts the traditional hierarchy - the leader exists to serve the team, not the reverse.

Servant leadership in engineering looks like:

  • Removing blockers: Clearing organizational obstacles so the team can ship
  • Providing context: Helping the team understand the "why" behind priorities
  • Creating clarity: Making ambiguous situations navigable
  • Shielding from chaos: Absorbing organizational turbulence so the team can focus
  • Celebrating wins: Acknowledging milestones and contributions

Giving Others Opportunities to Lead

Leadership includes developing other leaders. This means:

  • Delegating meaningful work (not just grunt work)
  • Providing support without micromanaging
  • Creating space for others to make decisions
  • Stepping back so others can step forward

Michelle Bu, Staff Engineer at Stripe, describes measuring impact through others:

I measure my impact based on their progress and, more importantly, the directionality of that progress and the alignment of their work to the company's goals.

Communicating Vision

Context Enables Autonomous Action

"Help others understand where you're going and why. Context enables autonomous action."

When people understand the vision:

  • They make better independent decisions
  • They don't need to escalate every choice
  • They can identify opportunities you haven't seen
  • They contribute to strategy, not just execution

Getting in the Room

Dan Na, Staff Engineer, describes the privilege and responsibility of senior technical presence:

I have a seat at the table at higher level engineering discussions that occur at a level above individual projects and teams. We have recurring staff engineering meetings where we discuss problems that span teams which are both technical and non-technical in nature.

Staff-plus engineers often get pulled into rooms where decisions are happening, giving them opportunity to inject engineering context while it's still possible to change outcomes. This requires representing all of engineering, not just your own perspective.

Level-Specific Guidance

Junior Engineers

Focus areas:

  • Demonstrate reliability through consistent follow-through
  • Take ownership of complete features, not just assigned tasks
  • Document and share what you learn
  • Ask clarifying questions that improve outcomes

Leadership mindset: "I can lead by being the most reliable person on this team."

Mid-Level Engineers

Focus areas:

  • Mentor newer engineers - teaching deepens your understanding
  • Drive technical discussions toward decisions (not just participation)
  • Identify and fix team process problems
  • Build relationships across teams

Leadership mindset: "I can lead by making everyone around me more effective."

Senior Engineers

Focus areas:

  • Set technical direction for your domain
  • Build consensus around significant decisions
  • Develop mid-level engineers deliberately
  • Translate between technical and business concerns

Leadership mindset: "I can lead by creating clarity in ambiguous situations."

Staff+ Engineers

Focus areas:

  • Speak for technology in organizational decisions
  • Sponsor and develop senior engineers
  • Tackle problems that span organizational boundaries
  • Set technical vision that guides multiple teams

Leadership mindset: "I can lead by multiplying the impact of everyone around me."

The Glue Work of Leadership

Tanya Reilly's concept of "being glue" describes essential but often invisible work: facilitating meetings, documenting decisions, onboarding teammates, coordinating across teams, and generally making everything run more smoothly.

This work is leadership, even when it's not recognized as such. High-impact organizations often have one or more Staff engineers working behind the scenes "expediting the most important work and ensuring it gets finished."

The challenge: glue work is often undervalued because it's invisible. Leaders should:

  • Make glue work visible through documentation and communication
  • Recognize and credit glue work done by others
  • Ensure glue work counts toward advancement

Career consideration: While glue work is genuine leadership, be aware that many promotion systems undervalue it. See the "Glue Work Trap" section in Teamwork for guidance on balancing glue work with visible technical contributions to protect your career while still doing this essential work.

Further Reading

Books

  • Staff Engineer: Leadership beyond the management track - Will Larson
  • An Elegant Puzzle: Systems of Engineering Management - Will Larson
  • Radical Candor - Kim Scott
  • Resilient Management - Lara Hogan
  • The Manager's Path - Camille Fournier

Articles and Resources

Related Deep Dives

TL;DR

  • Lead from where you are - juniors lead through ownership and documentation, seniors through consensus-building and mentoring, staff+ through multiplying others' impact
  • Build influence without authority - create coalitions before meetings, lead with questions ("What would it take to...?"), and make others successful first
  • Sponsor, don't just mentor - mentorship is advice; sponsorship is raising names in rooms where opportunities are assigned and feeling "on the hook" for someone's advancement
  • Make reversible decisions quickly - two-way doors need 70% certainty; irreversible decisions (one-way doors) deserve more deliberation, but waiting for 90% certainty usually means waiting too long
  • Model vulnerability - admitting "I was wrong about that approach" publicly gives everyone permission to be wrong and creates psychological safety

Ready to test your knowledge?

Put what you've learned into practice with our assessment.