These are my notes on Staff Engineering: Leadership beyond the management track by Will Larson.
Key Insights
- Staff-plus roles archetypes:
- Tech lead.
- Architect.
- Solver.
- Right hand.
- What do Staff engineers actually do?
- Setting technical direction.
- Mentorship and sponsorship.
- Providing engineering perspective.
- Exploration.
- 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.
- When:
- 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:
- Vision is for people writing strategies and these are few.
- 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:
- 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.
- 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.
- 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.
- 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.
- Tech lead:
- What kind of work energizes you?
- What do Staff engineers actually do?
- Setting technical direction.
- Mentorship and sponsorship:
- Providing engineering perspective.
- Exploration.
- Being glue.
- Time frames are longer than dev work.
- It is normal to end some days feeling like you haven't accomplished anything.
- Advantages:
- 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.
- Being in the room:
- To provide input for important decisions.
- Compensation.
- Access to interesting work:
- But not always.
- Allow you to bypass informal gauges of seniority:
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?
- Existential issues: company going through an existential risk.
- 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.
- Foster growth of your team.
- Edit: small, quick changes that shift a project's outcome with little effort.
- Finish things:
- Push project to finishing line, by helping rescope or remove roadblocks.
- 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.
- When:
- 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:
- Get started.
- Write the specifics:
- Write until you start to generalize.
- Specific statements create alignments; generic statements create the illusion of alignment.
- Be opinionated.
- Show your work.
- Best strategies feel too obvious.
- Strategies worth writing:
- When should we write a design doc?
- Which DBs do we use for which cases?
- 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:
- Vision is for people writing strategies and these are few.
- 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:
- Fix hot spots:
- Unless your company is creating problems faster than you are able to fix hot spots.
- Best practices:
- Limit to 1 new practice at a time.
- Steps:
- Document the approach.
- Experiment with few engaged teams.
- Sand down rough edges.
- Improve doc.
- Go to (2).
- See Accelerate recommendations.
- 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:
- Interfaces between systems: encapsulate implementation.
- Stateful systems: Failure modes, consistency behaviour, performance.
- Data models: Prevent invalid states, evolve over time.
- 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:
- Direct feedback.
- Refine engineering strategy.
- Enforce in workflows and tooling.
- Train during onboarding.
- Use Conway's law.
- Curate technology change with architecture reviews or similar.
- Measure technical quality:
- Some examples in page 61.
- Be detailed in your definition of quality.
- 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.
- Quality program:
- Hire a Technical Program Manager.
- Org wide change.
- Approach on page 66.
- Fix hot spots:
- 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:
- Has a vision on how things should be.
- Sees how things are.
- Takes action to narrow (1) and (2).
- This approach only creates early success.
- Most effective leaders spend more time following than they do leading:
- Follow if you disagree just in a minor way.
- Follow other trustworthy leaders.
- Make your feedback comments explicitly optional (non-blocking).
- Leader:
- Learn to never be wrong:
- At the same time:
- Have a deep perspective on technology and architecture.
- 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.
- Ask three good questions before sharing your perspective:
- Your career depends more on being easy to involve than being technically correct.
- At the same time:
- 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.
- A good discussion is one that it turns out you didn't need to attend.
- 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:
- Situation: relevant context.
- Complication: why situation is problematic.
- Question: what is the core question to address.
- Answer: what is the best answer.
- Mistakes to avoid:
- Never fight feedback.
- Don't evade responsibility or problems.
- Don't present a question without an answer.
- Avoid academic-style presentations.
- 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:
- What staff project?
- Your role, project impact, complexity.
- Links to design documents.
- High-leverage ways you have improved the org.
- People mentored and through what.
- Glue work.
- Which teams/leaders are familiar with and advocate for your work.
- What staff project?
- Process:
- Answer why you are doing it.
- Take it easy, it takes time.
- Bring your manger into the fold:
- Make her aware of your goal.
- Ask for feedback, guidance.
- Write your promotion packet.
- WAit two days and edit.
- Edit with trusted peers.
- Edit with manager:
- Ask for gaps nad how to address them.
- 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:
- Bring something useful that is different:
- Expertise, detailed knowledge, similar past experience.
- Sponsor.
- Make your sponsor aware that you want to be there.
- Bring something useful that is different:
- Folks evaluate leaders on how aligned their teams are with their approach.
- Being visible.
Top comments (1)
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.