Staff Engineer

Staff Engineer is a concise look at leadership beyond the management track. The book was written by Will Larson who worked at companies such as Stripe or Uber. In around 150 pages he summarizes his view on Staff+ engineering and the other half of the book contains interviews with engineers from other companies. While subjective, many of the points in the book seem to be the general consensus in the industry on what Staff+ engineering should look like. Some chapters contain more substance (e.g. Work on What Matter) while others seemed to me like re-iteration of what I would expect from engineers on any other level or even just decent human beings (Get in the Room and Stay There in particular contains a few points that read to me as don’t be an duchebag).

Notes

• When advancing through the career ladder the timeframe of initiatives get longer from weeks (sprints) to months or even years.
• Shift from decision making and executing towards giving space to others and steering them in the right direction.
• A lot of it is about networking and being friends with the right people or being in the right place at the right time.
• Enging chapter also includes a few tips for managing and hiring staff engineers.

Archetypes

Tech Lead

• carry team context
• closely cooperate with product manager
• build agreements inside team

Architect

• focus on specific technical domain (e.g. API design)

Solver

• move around to solve specific burning issues

Responsibilities

• setting technical direction - advocate for technology and how it applies to the specific problems of the company
• mentorship and sponsorship - sharing experience and advice while understanding the recipients domain.¹
• providing engineering perspective - be invited into meetings to inject engineering context for critical decisions
• exploration - research topics, build proof of concepts, build generic understanding of topic to make informed decision
• being glue - doing the needed but invisible work²

Operating at staff

• work on what matters

  • avoid snacking - working on low effort low impact things when you run out of low effort high impact initiatives
  • avoid preening - working on low effort high visibility work
  • existential issues - the first place to look for work is exploring whether the company is experiencing an existential risk
  • work where there’s room and attention - work on things that will become critical in the future
  • foster growth - dedicate time to grow the team around you
  • edit - once you have the context you might be able to contribute small changes that actually push existing project by a lot
  • finish things - help where things are not getting buy in (and should) or when they need to be taken over the finish line

• engineering strategy³

  • why? allows teams to move quickly and with confidence, e.g. the team doesn’t need to do week of research on database storage because the chosen few that are used in the company are already part of the engineering strategy

• managing technical quality

  • fix hot spots causing immediate problems
  • adopt best practices that are known to improve quality
  • prioritize leverage points that preserve quality as the software grows, e.g. good data model, well defined API, etc.
  • align on techical vectors - the initiatives in the team and accross team should lead to shared goal
    • give feedback, encapsulate your approach in workflow and tooling
  • do fewer things but do them better

• listening through questions, i.e. asking good questions that open further discussion, the question has to be well intended with the purpose of learning more and the other party must feel safe to answer it

• discussions

  • shift your contribution towards asking questions
  • pull people that aren’t participating into the discussion
  • take notes (duh)

• decisions

  • write down the problem, think hard, write down the solution framework
  • circulate early, i.e. get input early in the decision-making process
  • separate style from substance, i.e. stop giving style feedback because everyone has different writing style and idea of the document structure. Instead, focus on the substance.
  • be open to changing your mind

• presenting to executives

  • situation: the context of the problem
  • complication: why is the current situation bad
  • question: what is the core question to answer?
  • answer: what is your best solution/answer to the posed question?

Info

Title: Staff Engineer: Leadership beyond the management track
Author: Will Larson
ISBN10: 1736417916
ISBN13: 9781736417911