Book Summary: Staff Engineer - Leadership Beyond the Management Track
TLDR: Staff Engineer: Leadership Beyond the Management Track by Will Larson demystifies what a Staff Engineer does. Through numerous interviews with current Staff+ engineers, you’ll learn about many different paths to grow into a Staff engineer and strategies to thrive at this level.
If you are a senior engineer looking to grow your career, I highly recommend this book.
The book provides interviews with many Staff+ engineers giving different perspectives on how they got there, what they do, and advice for doing well in this role. The points below are my big takeaways, not necessarily a summary of the entire book but just what stood out to me.
My Key Takeaways
Key Ideas
- Scale Yourself
- Grow yourself & grow others
- Influence
- Write more
- Prioritize for Impact
- Work on what matters
- Prioritize your time
- Get into the “room”
- Solve Problems Well
- Define the problem
- Write more
Actions
- Write more – to better clarify your thoughts & to scale yourself
- Listen more – to have context (be the glue) & better understand problems
- Handle ambiguity – accept you don’t always know the answer & you won’t always have much visible work accomplished on some days
Scale Yourself
Grow Yourself & Grow Others
- Try to become the engineer people want to work with. The higher up you go the more you will depend on other people. You will work with others, help others, and need others to sponsor your promotion. The projects you need to deliver will be larger in scope the higher up you go in your career. This means more people will be involved and you’ll need to keep these people aligned toward the same vision.
- Spend time mentoring others. When a new task is available you should be thinking, “Who could be both successful with and grown by this work?”. The higher you progress in your career, the more your job will be about growing the people around you. When someone comes to you with a problem, instead of solving it for them, ask what they think should be done.
- Listen more. Understand the folks on other teams have different contexts – their priorities and perspectives are not yours. Seek to understand their point of view. Here are some techniques to be a better listener:
- Ask for their thoughts and opinions
- Create space to listen – this means to pause and wait
- Ask 3 questions before sharing your perspective
- Ask questions with the intent to learn
- Have the attitude of “what am I missing?” – seek to understand
- Never fight feedback, don’t have a preferred outcome
- Speak clearly and concisely: Remember that it’s your obligation to be understood, and not the obligation of everyone else to understand you.
- Set up 1:1s with engineers and spend time listening
- Be the Glue (Tanya Reilly’s post). Work on having the most context of all the various teams in your part of the organization. Teams often get stuck in local maximums, they solve a problem for their specific use case. A good Staff Engineer can see this problem spans multiple teams and work with these folks to find a solution that can help everyone. Teams get stuck in local maximums because they only have the context of their team.
Influence
- Influence others, do not dictate. Have the context, ask questions, listen, give and receive feedback. Try to “coach” people into doing what you want by asking questions rather than stating “this is what we should do”.
- Nemawashi is a Japanese business informal process of quietly laying the foundation for some proposed change or project by talking to the people concerned and gathering support and feedback before a formal announcement. By aligning with stakeholders before your presentation you can reduce surprises and get folks aligned.
- Direct change through others. Trust other engineers to get the work done. You should flag issues, clear up miscommunications, and keep people aligned while they do the work.
Write more
- Write things down. It’s one of the best ways to scale yourself. You can write something once and then just point to this document rather than explaining yourself repeatedly. You can also use writing to set technical strategy or create processes. Write once, refer to forever.
- Writing helps yourself and others. You scale yourself because your ideas are more easily shared. But writing things down forces you to clarify your ideas.
- Write clearly. Present the summarizing idea first, then give your supporting ideas. The order you express your ideas matters. See my book summary on Writing Without Bullshit.
Prioritize for Impact
Work on what matters
- Spend your time on high-value work. Look for what work you can uniquely accomplish. This is the intersection of what you are good at and what you care about.
- Avoid “snacking” which is doing the low impact and easy work.
- Avoid doing low-impact but highly visible work.
- Finish projects. As engineers, we deliver value by finishing projects. Help others to finish and be sure to finish your work. Focus on one thing at a time to make progress and finish.
Prioritize your time
- Balance time between high-value work for the company and work that helps you to grow.
- Think – “Is this the best use of my time? Can someone else grow here?”
- Meetings should have a clear purpose and agenda. Define the purpose if it’s unclear by saying “just to check, our goal here is to…”.
Get into the “room”
- The “room” refers to the meetings where decisions are made. The OKR and quarterly planning meetings. Talk with your manager about your desire for Staff so you can be there for these conversations that help guide strategy and priorities.
- Make your manager’s job easier – bring solutions with any problems. Don’t evade responsibility. By putting issues on the table, you can move towards solving them together rather than hiding them.
Solve Problems Well
Define the problem
- Find the right problems. When you notice a problem, you are the “adult in the room” that needs to act on it instead of letting it go. Guard your time because you can’t solve everything but at least flag it by defining the issue and raising it with your team or the relevant stakeholders.
- Be comfortable with ambiguity. Problems that no one wants to tackle are messy. Messy problems are vague or have a wide-reaching scope. Part of your work is setting the boundaries and getting clear on the deliverable.
- Designing a solution you first start with the problem and get clear on it. Then research & listen to other perspectives, and get input. Finally, present the tradeoffs and make a suggestion. The decisions are a series of tradeoffs – explain what the tradeoffs are.
Write more
- Writing more is so important IMO it deserves two mentions. The above purpose for writing is it creates leverage by which you can scale yourself. The second point of writing is to clarify your ideas which can help you solve problems better.
- Write down a problem, think very hard, and then write down the solution. Write down as you think through a problem or idea. Do more research if can’t get things clarified in writing
- Use the SCQA structure for writing RFCs.
- Situation: relevant context.
- Complication: why the situation is problematic.
- Question: what is the core question to address.
- Answer: what is the best answer.
- Again, start from the problem. The clearer the problem statement, the more obvious the solution.
Next Steps
- Is a Staff + role something you are pursuing? Take action today by telling your manager. Be clear about your intentions, and understand that the role is different.
- Buy Staff Engineer: Leadership beyond the management track (Amazon Associates link)
- Check out Will Larson’s blog
Additional Resources – from the book
- There were a lot of book suggestions, but here are some books that stood out to me to read or re-read:
- Here are some blog posts that stood out: