Book notes: Staff Engineering: Leadership beyond the management track

These are my notes on Staff Engineering: Leadership beyond the management track by Will Larson.

Key Insights

• Staff-plus roles archetypes:
  1. Tech lead.
  2. Architect.
  3. Solver.
  4. Right hand.
• What do Staff engineers actually do?
  1. Setting technical direction.
  2. Mentorship and sponsorship.
  3. Providing engineering perspective.
  4. Exploration.
  5. Being glue.
• It is normal to end some days feeling like you haven't accomplished anything.
• Your work maintains an aloof indifference to your sacrifice rather than rewarding it.
• Look for low effort-high impact work.
• Durably useful engineering strategy and vision are the output of iterative, bottom-up organizational learning.
• Synthesize 5 design docs into a strategy, extrapolate 5 strategies into a vision.
• Design docs (RFC):
  • When:
    • Project capabilities will be used numerous times in the future.
    • Big impact on users.
    • Work takes longer than a month.
  • Start from the problem: The clearer the problem statement, the more obvious the solution.
  • Gather and review together, write alone.
• Specific statements create alignments; generic statements create the illusion of alignment.
• Best strategies feel too obvious.
• Vision:
  • Reconcile strategies, extrapolate how their trade-offs will play out over the next two to three years.
  • Assume everything is going to go well, but don't assume infinite resources.
  • Don't expect load of excitement:
    1. Vision is for people writing strategies and these are few.
    2. Great visions are so obvious that it bores.
• At a well-run and successful company, most of your previous technical decisions won't meet your current quality threshold.
• Architect's decision degrade the further they get from doing real work on real code in real process.
• Your career depends more on being easy to involve than being technically correct.

TOC

• Chapter 1 - Overview
• Chapter 2 - Operating at Staff
• Chapter 3 - Getting the title where you are
• Chapter 4 - Deciding to Switch Companies

Overview

• Staff-plus roles archetypes:
  1. Tech lead:
     • The most common type.
     • Lead one team or a cluster of teams.
     • Scope complex tasks, coordinate teams to solve it and unblocks them.
     • Keep cross-team relationships.
     • Roadmap shuffling.
  2. Architect:
     • Responsible for the success of a specific technical domain.
     • Intimate business knowledge and technical constraints.
     • Either deep in codebase or no coding at all.
  3. Solver:
     • Moved from one high execution risk problem to the next.
     • Problem identified and prioritized by the org.
     • Require little org-level chiropractices.
     • Individual vs team.
  4. Right hand:
     • Least common.
     • Senior org leader without direct managerial responsibilities.
     • Borrow authority from senior leader.
     • Dive into a fire, edit the approach, delegate execution to the most appropriate team, go to the next fire.
     • Problem are never purely technical.
• What kind of work energizes you?
• What do Staff engineers actually do?
  1. Setting technical direction.
  2. Mentorship and sponsorship:
     • What does sponsorship look like?.
  3. Providing engineering perspective.
  4. Exploration.
  5. Being glue.
• Time frames are longer than dev work.
• It is normal to end some days feeling like you haven't accomplished anything.
• Advantages:
  1. Allow you to bypass informal gauges of seniority:
     • Do not need to recurrently prove yourself, which will free time and energy.
     • More respected from the outset.
  2. Being in the room:
     • To provide input for important decisions.
  3. Compensation.
  4. Access to interesting work:
     • But not always.

Chapter 2 - Operating at Staff

• Work on what matters:
  • Your work maintains an aloof indifference to your sacrifice rather than rewarding it.
  • Look for low effort-high impact work.
  • Avoid snacking: low effort-low impact work that is "just" psychologically rewarding.
  • Stop preening: low impact-high visibility work.
  • Stop chasing ghost: low-impact high-effort:
    • Ghosts from previous org.
    • When joining a new company, first understand context before making changes.
• What work?
  1. Existential issues: company going through an existential risk.
  2. Work where there is room and attention:
     • Teaching a company to value (pay attention) something it does not care about is the hardest sort of work you can do, and it often fails.
  3. Foster growth of your team.
  4. Edit: small, quick changes that shift a project's outcome with little effort.
  5. Finish things:
     • Push project to finishing line, by helping rescope or remove roadblocks.
  6. Things that only you can do.
• Writing engineering strategy:
  • Durably useful engineering strategy and vision are the output of iterative, bottom-up organizational learning.
  • If you have rehashed the same discussion three times, it is time to write a strategy.
  • When the future is too hazy to identify investments worth making, it is time to write another vision.
  • Technical Decision-Making and Alignment in a Remote Culture.
  • Synthesize 5 design docs into a strategy, extrapolate 5 strategies into a vision.
• Design docs (RFC):
  • When:
    • Project capabilities will be used numerous times in the future.
    • Big impact on users.
    • Work takes longer than a month.
  • Start from the problem: The clearer the problem statement, the more obvious the solution.
  • Keep template simple.
  • Gather and review together, write alone.
  • Prefer good to perfect.
• Strategy docs:
  • Look for controversial decision that came up in multiple designs.
  • Guide trade-offs and explain rationale.
  • A Framework for Responsible Innovation.
  • How Big Technical Changes Happen at Slack.
  • In Good Strategy, Bad Strategy terms:
    • Strategy doc == diagnosis + guiding principles.
    • Design doc == coherent action.
  • Advise:
    1. Get started.
    2. Write the specifics:
       • Write until you start to generalize.
       • Specific statements create alignments; generic statements create the illusion of alignment.
    3. Be opinionated.
    4. Show your work.
• Best strategies feel too obvious.
• Strategies worth writing:
  1. When should we write a design doc?
  2. Which DBs do we use for which cases?
  3. How should we stage migration from monolith to microservices?
• Vision:
  • Reconcile strategies, extrapolate how their trade-offs will play out over the next two to three years.
  • Advice:
    • Grounded on serving your business and your users.
    • Be ambitious, but not audacious.
    • Assume everything is going to go well, but don't assume infinite resources.
    • Stay concrete and specific.
    • One or two pages long.
  • Don't expect load of excitement:
    1. Vision is for people writing strategies and these are few.
    2. Great visions are so obvious that it bores.
  • Measure successful vision by comparing design docs before/after it.
• Managing technical quality:
  • At a well-run and successful company, most of your previous technical decisions won't meet your current quality threshold.
  • Approaches, from cheaper to most complex:
    1. Fix hot spots:
       • Unless your company is creating problems faster than you are able to fix hot spots.
    2. Best practices:
       • Limit to 1 new practice at a time.
       • Steps:
         1. Document the approach.
         2. Experiment with few engaged teams.
         3. Sand down rough edges.
         4. Improve doc.
         5. Go to (2).
       • See Accelerate recommendations.
    3. Leverage points:
       • When you want to roll out more than one practice at a time.
       • Leverage points: prevent gross quality failures and reduce the cost of future quality investments.
       • 3 most typical:
         1. Interfaces between systems: encapsulate implementation.
         2. Stateful systems: Failure modes, consistency behaviour, performance.
         3. Data models: Prevent invalid states, evolve over time.
    4. Technical vectors:
       • Architect's decision degrade the further they get from doing real work on real code in real process.
       • Technical vector: where technical decisions point to, hopefully towards the vision.
       • Tools:
         1. Direct feedback.
         2. Refine engineering strategy.
         3. Enforce in workflows and tooling.
         4. Train during onboarding.
         5. Use Conway's law.
         6. Curate technology change with architecture reviews or similar.
    5. Measure technical quality:
       • Some examples in page 61.
       • Be detailed in your definition of quality.
    6. Technical quality team:
       • aka Dev Productivity, DevTools, Product Infra.
       • 1 for each 15 devs.
       • For success:
         • Trust metrics over intuition.
         • Keep intuition fresh: team embedding.
         • Treat it as a product.
         • Do fewer things, but better: Tool quality will impact the whole org.
         • Don't hoard impact: Decentralized approach.
    7. Quality program:
       • Hire a Technical Program Manager.
       • Org wide change.
       • Approach on page 66.
• Stay aligned with authority:
  • Don't surprise and don't get surprised by your manger.
  • Feed them context:
    • Bring problems to inform them, make it clear that is not to solve them.
• To lead, you have to follow:
  • Leader:
    1. Has a vision on how things should be.
    2. Sees how things are.
    3. Takes action to narrow (1) and (2).
    4. This approach only creates early success.
  • Most effective leaders spend more time following than they do leading:
    1. Follow if you disagree just in a minor way.
    2. Follow other trustworthy leaders.
    3. Make your feedback comments explicitly optional (non-blocking).
• Learn to never be wrong:
  • At the same time:
    1. Have a deep perspective on technology and architecture.
    2. Remain skeptical of yourself.
  • Meetings with multiple failed reframings almost always end with scheduling another meeting.
    • Ask three good questions before sharing your perspective:
      • Good questions are asked with the desire to learn, and they are specific.
  • Your career depends more on being easy to involve than being technically correct.
• Create space for others:
  • A good discussion is one that it turns out you didn't need to attend.
    • When you make a key contribution, think what needs to happen for someone else to make it next time.
  • In meetings:
    • Ask questions.
    • Pull people not participating.
    • Be the one taking notes (less time to speak).
  • Sponsor other to do "your" work.
• Build a network of peers:
  • Regulars with previous managers/colleges.
  • Blogging/public speaking.
  • Internal networks.
  • Ambient networks: follow interesting people in Twitter.
• Present to executives:
  • Always for planning, status reports or resolve misalignment.
  • Goal is always to extract as much perspective from the executive as possible.
    • Never to change their mind.
  • Barbara Minto, The Pyramid Principle:
    • The clearest sequence to present your ideas is always to give the summarizing idea before you give the individual ideas being summarized.
  • Recommended doc structure:
    1. Situation: relevant context.
    2. Complication: why situation is problematic.
    3. Question: what is the core question to address.
    4. Answer: what is the best answer.
  • Mistakes to avoid:
    1. Never fight feedback.
    2. Don't evade responsibility or problems.
    3. Don't present a question without an answer.
    4. Avoid academic-style presentations.
    5. Don't fixate on your preferred outcome.
  • Share early drafts with executives attending the meeting asking for feedback.

Chapter 3 - Getting the title where you are

• Opportunities are not evenly distributed across the company.
• Promotion packets:
  • Write them before, so it becomes a map to accomplishing your goal.
  • Template:
    1. What staff project?
       • Your role, project impact, complexity.
       • Links to design documents.
    2. High-leverage ways you have improved the org.
    3. People mentored and through what.
    4. Glue work.
    5. Which teams/leaders are familiar with and advocate for your work.
  • Process:
    1. Answer why you are doing it.
    2. Take it easy, it takes time.
    3. Bring your manger into the fold:
       • Make her aware of your goal.
       • Ask for feedback, guidance.
    4. Write your promotion packet.
    5. WAit two days and edit.
    6. Edit with trusted peers.
    7. Edit with manager:
       • Ask for gaps nad how to address them.
    8. Review periodically with manager.
• Find a sponsor.
• Staff project is usually not required, but worth pursuing for personal growth and ease the promotion.
• Must get into the meeting where important decision are made. You need:
  1. Bring something useful that is different:
     • Expertise, detailed knowledge, similar past experience.
  2. Sponsor.
  3. Make your sponsor aware that you want to be there.
• Folks evaluate leaders on how aligned their teams are with their approach.
• Being visible.

Chapter 4 - Deciding to Switch Companies

• Salary Negotiation.

Comments

[Manuel Odendahl]

I absolutely loved this book. Thanks for such thoughtful notes. While I got the title of Staff Engineer at my last job, I was utterly unable to function as such, and had to leave. This book helped me articulate that.