Staff Engineer: Leadership Beyond the Management Track

by Will Larson

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. In earlier roles, you may have tried to influence decisions towards technology choices you were motivated by; in senior positions, you’re accountable to the business and organization first and yourself second.

You’re far more likely to change your company’s long-term trajectory by growing the engineers around you than through personal heroics. The best way to grow those around you is by creating an active practice of mentorship and sponsorship.

If you have a problem and believe that your title is the only thing holding you back, I want to reassure you that focusing on developing your approach and skills will be far more impactful than the title. The title will get you over the ledge once you’re close, but it’ll never do as much work as you’d expect.

If you’re continuing to advance in your career, then even as your time available for work shrinks, the expectations around your impact will keep growing. You can try sleeping less or depriving yourself of the non-work activities you need to feel whole, but you’ll inevitably find that your work maintains an aloof indifference to your sacrifice rather than rewarding it. Only through pacing your career to your life can you sustain yourself for the long-term.

Taking the time to understand the status quo before shifting it will always repay diligence with results.

We only get value from finishing projects, and getting a project over the finish line is the magical moment it goes from risk to leverage. Time spent getting work finished is always time well spent.

things that simply won’t happen if you don’t do them are your biggest opportunity to work on something that matters, and it’s a category that will get both narrower and deeper the further you get into your career.

To write an engineering strategy, write five design documents, and pull the similarities out. That’s your engineering strategy. To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future. That’s your engineering vision.

A good design document describes a specific problem, surveys possible solutions, and explains the selected approach’s details.

You should write design documents for any project whose capabilities will be used by numerous future projects. You should also write design documents for projects that meaningfully impact your users. You should write a design document for any work taking more than a month of engineering time.

Particularly as you become more senior, it’s toxic to push every design to meet the bar of your own best work. Focus on pushing designs to be good, rather than fixating on your own best as the relevant quality bar.

Good strategies guide tradeoffs and explain the rationale behind that guidance. Bad strategies state a policy without explanation, which decouples them from the context they were made. Without context, your strategy rapidly becomes incomprehensible–why did they decide this?–and difficult to adapt as the underlying context shifts.

Specific statements create alignment; generic statements create the illusion of alignment.

On writing a strategy document

Good strategies are opinionated. If they aren’t opinionated, then they won’t provide any clarity on decision making.

As we leave behind the idea of strategy as demonstrations of brilliance, we can start to write far more of them, and we can write them more casually. If it ends up not being used, you can always deprecate it later.

Visions should be ambitious, but they shouldn’t be audacious. They should be possible, but the best possible version if possible. Do write what you could accomplish if every project is finished on time and without major setbacks. Don’t write what you think would be possible with infinite resources.

Adopting a single new practice at a time also forces you to think carefully about which to prioritize.

Effective interfaces decouple clients from the encapsulated implementation. Durable interfaces expose all the underlying essential complexity and none of the underlying accidental complexity.

A good data model is rigid: it only exposes what it genuinely supports and prevents invalid states’ expression. A good data model is tolerant of evolution over time. Effective data models are not even slightly clever.

an organization that allows any tool is an organization with uniformly unsupported tooling.

No matter how you decide to measure technical quality, the most important thing to always remember when running your quality program is that the program isn’t the goal. The goal is to create technical quality.

When it comes to complex systems and interdependencies, moving quickly is just optics. It’s methodical movement that gets the job done.

Retire your remaining expectations that the company is designed to set you up for success. Now you are one of the people responsible for setting the company, your team, and your manager up for success.

roughly management is a specific profession, and leadership is an approach one can demonstrate within any profession.

If you only see the gap without acting on it, you might be a visionary, but you’re inert. If you take action without a clear view of the goal, many will consider you a leader, but your impact will be random, arbitrary, and inefficient. Combining both with some luck is likely to take you a long way in your career, and these are characteristics common in folks I’ve worked with who successfully navigate the transition into Staff-plus engineering or senior management roles.

continued growth requires learning to incorporate your worldview into the worldviews of those around you, accelerating overall progress around you even if it means tolerating a detour from your vision.

To become a senior technical leader, you must build a deep perspective on technology and architecture. To operate as such a leader, you must then develop an equally deep pragmatism and agnosticism to technical religion to remain skeptical of yourself. This can feel like a paradox, but it’s the line you’ll need to walk every day.

In a potentially contentious meeting, ask three good questions before you share your perspective, and you’ll see the room shift around you.

Shift your contribution towards asking questions. Asking the right questions helps avoid missteps, but also makes it easier for more folks to contribute

If you see someone in the meeting who isn’t participating, pull them into the discussion. It works best to pull exactly one person at a time into the discussion. It gets confusing when you open it up broadly to everyone or even just try to pull two or three people at once

If a piece of feedback won’t meaningfully change a project’s success, then consider not giving it. If it’s useful but not critical, potentially make a private suggestion rather than pulling a meeting into your orbit

One of the biggest signs of respect for your coworkers is listening to them and then changing your mind afterward. If senior leaders don’t change their mind, then soon everyone will correlate bluster with success

Everyone has worked with a terrible executive at some point in their career, but most executives aren’t awful. Almost all executives are outstanding at something; it’s just that often that something isn’t the topic you’re communicating about with them. When you combine that lack of familiarity with your domain with limited time for the topic at hand, communication is a challenge.

The foundation of communicating effectively with executives is to get a clear understanding of why you’re communicating with them in the first place.

When you’re communicating with an executive, it’s almost always one of three things: planning, reporting on status, or resolving misalignment. Although these are distinct activities, your goal is always to extract as much perspective from the executive as possible.

Controlling the sequence in which you present your ideas is the single most important act necessary to clear writing. The clearest sequence is always to give the summarizing idea before you give the individual ideas being summarized.

A great meeting with executive leadership is defined by engaged discussion, not addressing every topic on the agenda.

A frequent piece of advice given to new leaders is to “never bring your manager a problem without a solution.” That’s not generally great advice, but if you present a problem to an executive without a proposed answer, then in the back of their mind, they’re wondering if they need to hire a more senior leader to supplement or replace you. You can’t create alignment in the room unless you have a proposal for folks to align behind.

You can only change a system with sponsorship from within.

Staff-plus titles are leadership positions. It’s uniquely challenging to gain a leadership position if the existing leadership team doesn’t identify with you as a potential member.

Learn to speak clearly: if folks don’t understand your proposal, then it doesn’t matter how good it is. Keep in mind that it’s your obligation to be understood, not the obligation of everyone else to understand you.

Visibility is a transient currency. Learning and developing yourself is a permanent one; focus on the latter once you’ve done the minimum to clear the former’s cliff.

The most useful general learning for me was becoming comfortable with uncertainty. Sustained success in senior roles depends on your ability to adapt and grow as the needs of the organization change.

He told me to write my performance review in the third person. The idea being that you’re more likely to praise others, and be less critical, when giving them a review. It’s pretty simple, but has been super useful to me.

Communication and building narratives are key. Make sure to write … A LOT. When thinking through problems or ideas, write it down (even if you don’t intend to share them).

I think a lot of what gets someone to Staff is noticing problems and acting on solving them proactively, instead of letting them go.

get used to writing things down and repeating them to others. Writing down thoughts, plans, reasoning, and standards is the way you will scale yourself. When you document something you make it easy for anyone to access it and read in the future, it is easier to reference.

As a concept, I’m skeptical of that kind of singularly focused project and worry that they can put folks into a hero mindset when we really want to value engineers that can build the organization, not carry it.

Nothing is more stressful for a high performer than not knowing how they’re doing! If you don’t give feedback, especially about their best work, they’ll keep changing their approach until you do give feedback (often to your regret).