Book notes on "The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change" by Tanya Reilly

These are my notes on The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change by Tanya Reilly.

Must-read for anybody interested on growing in the individual contributor track.

Be the engineer that everyone wants to work with. Tanya Reilly, this book

Key Insights

Staff engineer pillars

Staff eng roles come in a lot of shapes, but not all orgs will need all kinds of staff engs.
Senior is a “tenure” level: you don’t need to go further.
Whenever there is a feeling of “someone should do something here”, there is a reasonable change that the someone is you.
Autonomous: Find your own problems to work on.
Know why the problem you are working on is strategically important, and it is not, do something else.
Not necessary to provide solution but to ensure there is agreed-upon, well-understood solution that solves the problem.
Feedback loops will be months.
Write down a “what do I do here?” doc to ensure expectations/focus in shared with manager and peers.
Vision/Strategy is not always needed:
- It is a big project.
- Getting the people to agree is the work.
None of the options can make everybody happy:
- Rather than asking “Is everyone ok with option A?” ask “Can anyone not live with option A?”
- Not deciding is a decision, usually not a good one.
You have to make peace with walking past things that are broken or suboptimal.
Do what is important for the company, but also what is important for you.
Notice when you are doing busy work because you are tired, and find a way to rest instead.
Put non meetings in the calendar too:
- Not “make time” but specific items.
The usual reason why a project is difficult is that you are dealing with ambiguity.
Number one tool for project success: writing things down.
As a project lead, you will fill any roles that you don’t have someone in them.
Recruit people that are optimistic, good at conflict resolution and comms.
Better wrong than vague: chance to change direction early.
If it seems trivial, it is because you do not understand it.
Writing code is rarely the highest leverage thing you can spend time on.
- Coding gives you a depth of understanding that is hard to gain otherwise.
Something will always go wrong:
- Take it as an opportunity to learn.
Techniques to get unstuck:
1. Understand and explain.
2. Make the work easier.
3. Get org support.
4. Make alternative plans.
Supporting an untrained person through making a change in a difficult codebase takes more effort than doing it yourself.
Three bullet points and a call to action:
- Three bullet points detailing the issue at hand.
- One and only one call to action.
Blocked by:
- A decision: make a guess and document it with an ADR.
No talk about implementation until all agree about the problem.
Don’t just tell people that the solution exists: you need to keep telling them.
If the project is not in good shape by the end of it, it will never be.
People assume that you know what you are talking about, so be careful with what you say.
Values is what you do.
The degree to which other people want to work with you is a direct indication of how successful you’ll be in your career as an engineer.
Do not accept a management role until you are a solid senior engineer.
Radiating intent (instead of seeking permission or asking for forgiveness).
Attributes of a staff engineer:
1. Competent.
2. Responsible.
3. Remembers the goal:
  - SW is a means to a goal, not a goal itself.
  - There is always a budget.
4. Look Ahead.
Don’t jump to give advice, sometimes the mentee just need to vent or get empathy on the situation.
If you cannot think on what to improve, ask yourself why they aren’t one level more senior.
You cannot be an expert in everything.
Every job should help you grow towards your long-term goals and meet your immediate needs.
Keep a weekly record of your job signals.
Staying in one place for long gives you the feedback loop that comes from seeing the consequences of your actions.

Introduction

Both paths need many of the same skills.
Pillars:
1. Big-picture thinking.
2. Execution.
3. Leveling up others.
When acting as a role model, you need to be right.

Staff engineer pillars

Part I - The Big Picture

Chapter 1 - What would you say you do here?

Staff eng roles come in a lot of shapes, but not all orgs will need all kinds of staff engs.
Senior is a “tenure” level: you don’t need to go further.
Big picture:
- Good decisions need context:
  - Gathering context requires time and effort.
- Managers, as the people responsible for assigning headcount to technical initiatives, need to be part of major tech decisions.
Project management:
- Unstuck.
- Tech quality.
- High level system design.
Whenever there is a feeling of “someone should do something here”, there is a reasonable change that the someone is you.
https://kind.engineering/.
Programming will often not be the best use of your time:
- Enough work to make problems manageable by someone else:
  - Growth opportunity for less experience devs.
Autonomous: Find your own problems to work on.
Not necessary to provide solution but to ensure there is agreed-upon, well-understood solution that solves the problem.
Who you report to influences:
1. Support you receive.
2. Information you can access.
3. How you are perceived.
4. Scope: domain, teams:
  - Too broad:
    - Lack of impact: distracted with side-quests.
    - Become a bottleneck: take part on every decision.
    - Decision fatigue.
    - Missing relationships: not enough regular contact.
  - Too narrow:
    - Lack of impact.
    - Opportunity cost: working on less important stuff.
    - Overshadowing other engineers: no room for other engs to solve problems.
    - Over-engineering: too much time on your hands.
Ensure your scope is aligned to your preference of broad vs deep work.
4 disciplines in any job:
- Core tech skills.
- Product management.
- Project management.
- People management.
Consider how much you want to code.
Feedback loops will be months.
Know why the problem you are working on is strategically important, and it is not, do something else.
4 staff eng archetypes.
Write down a “what do I do here?” doc to ensure expectations/focus in shared with manager and peers:
- Overview.
- Goals.
- Sample activities.
- What success looks like?

Chapter 2 - Three Maps

Locator map:
- Where are you in the org, and what is outside your bubble.
- Put your work in a bigger context.
- To make good decisions, you’ll need to be able to see from others point of view.
- Risk of focusing only on your context:
  1. Prioritizing badly:
    - Your problems seem more important and special.
    - It is unusual to find a problem that is genuinely brand now.
  2. Losing empathy:
    - Think other domains are simpler.
    - Overestimate what others know from your domain.
  3. Tuning out the background noise:
    - Stop noticing some problems because you get so used to them.
  4. Forgetting what they work is for:
    - Lose connection with the company’s goals.
Topological map:
- Discover existing “dangers” and paths:
  - How leaders prefer to work.
  - How decisions are made.
  - “Shadow org” charts.
- Issues without one:
  1. Your good ideas don’t get traction.
  2. You don’t find the difficult parts until you get there.
  3. Everything takes longer.
- Understand your org:
  - Culture:
    - Open or secret?
      - Open information can lead to more drama.
    - Oral or written?
    - Top-down or bottom-up?
    - Fast change or deliberate change?
      - Tightly connected to oral/written.
    - Back channels or front doors?
    - Allocated or available?
      - If there are plenty of available people, changes are that a competing novel grassroots initiatives are about to start.
    - Liquid (meritocracy of sorts) or crystallized (structured hierarchy and promotion)?
- Points of interests:
  1. Chasms between teams/orgs:
    - Difficult to communicate, make decisions and resolve disputes.
  2. Fortresses:
    - Well-intended gatekeepers, but stop projects/change from happening.
    - Avoid a battle, even if you might win.
  3. Disputed territory:
    - When two or more teams need to work closely together, their projects can fall into chaos if they don’t have the same clear view of where they are trying to get to.
  4. Uncrossable desserts:
    - Unwinnable battles.
  5. Paved roads, shortcuts and busy ways around.
- You need to be technically correct and convince the right people.
- Figure out where decisions are happening:
  - You can influence higher up decisions by making sure relevant information reaches via your reporting chain.
  - Ask to join but show how it will make the org more likely to achieve its goals.
  - Figure out shadow org chart:
    - Connectors: people that know everybody.
    - Old-timers.
- Be a bridge.
Treasure map:
- Where and why.
- Destination and stop points.
- Long term view.
- If only short term vision:
  1. Harder to keep everybody going in the same direction.
  2. Not finish big things.
  3. Accumulate cruft.
  4. Competing initiatives.
  5. Engineers stop growing:
    - Small project problems != big project ones.
- If the map is not clear, create a new one.
- Trail map:
  - Tell the story of the work.
  - Every small task become part of a bigger story.

You learn some parts of the map through everyday learning, but you need to be deliberate for others.
Hiking example: easy to find out what you miss by looking at others:
- They had learned to pay attention adn they know what they were looking for.
Habit of paying attention:
- Take notes.
- What? Anything that helps you or others:
  - Have context.
  - Navigate your org.
  - Progress towards your goals.
Techniques for seeing the bigger picture:
1. Taking an outsider view:
  - A new person to the team/org can always see the problems.
2. Befriend other staff eng to understand from their point of view what your team/group looks like.
3. Befriend non-eng to learn what is important for business.
4. Understand your customer.
5. Understand what already exists inside and outside your org before creating something new.
The VOID report: incidents newsletter.
Raw signal: management and leadership newsletter.

Chapter 3 - Creating the Big Picture

Tech vision:
- Describe future as if all work to get there had been done.
- Any scope:
  - Smaller scopes should inherit from larger ones.
Tech strategy:
- Plan of action: how to achieve your goals, and navigating past the obstacles.
- Good/Bad strategy:
  1. Diagnosis: distill the situation to its most essential characteristic.
  2. Guiding policy: short and clear signpost, marking the direction forward.
  3. Coherent action: specific based from diagnosis/guiding policy.
    - They are a time commitment.
  - Strategy should draw on your advantages.
  - Strategy is realistic and within your org constraints.
Vision/Strategy is not always needed:
- It is a big project.
- Getting the people to agree is the work.
The approach:
- Good strategy is boring to write about:
  - Should be obvious.
- Join existing initiatives.
- Find a sponsor:
  - Ensure your plan fix some of their problems.
  - Elevator pitch.
- Choose your core group:
  - Makes you accountable.
  - Small (2-4), committed to 8-12 hours per week.
  - Consider bringing those who will oppose the most.
  - Keep a broader set of allies informed and engaged.
- Set scope:
  - How much of the ord you plan to influence.
- Make sure it is achievable:
  - Cut scope.
  - Be prepared to give up.
- Make it official.
The writing:
- Questions:
  - What is great as it is?
  - What is important?
  - What will future you wish that present you had done?
- Reviewers will be biased by what is already in the doc:
  - Mitigations:
    - Talk more before writing.
    - Make clear what parts you don’t feel strong about.
- Interviews final questions:
  - What else should I have asked you?
  - Is there anything important I missed?
- None of the options can make everybody happy:
  - Rather than asking “Is everyone ok with option A?” ask “Can anyone not live with option A?”
  - Decide upfront who is the tiebreaker.
  - Not deciding is a decision, usually not a good one.
  - Document any decision, including trade-offs and reasons.
Alignment:
- Stay aligned with your sponsor, at minimum in the major checkpoints.
- Nemawashi: by the time of voting, you should know the result.
- Vision or strategy that not everyone knows is of little value.
- Find a one-liner slogan.
- What is the difference between your document being yours and the organizations?
  - Belief.
  - Staffing the work, second.

Part II - Execution

Chapter 4 - Finite Time

You have to make peace with walking past things that are broken or suboptimal.
Do what is important for the company, but also what is important for you.
- Consider:
  - Energy:
    - Your current level and what the project will consume.
    - Different people need different levels of energy for the same project.
    - How many things are you already doing? Limit WIP.
    - Does this kind of work give you or take energy?
    - Are you procrastinating?
      - Notice when you are doing busy work because you are tired, and find a way to rest instead.
    - Is this fight worth it?
      - Compare with other work.
  - Quality of life:
    - Do you enjoy this work?
    - How do you feel about the project’s goals?
  - Credibility:
    - Does this project use your technical skills?
    - Does this project show your leadership skills?
  - Social capital:
    - It this the kind of work that your company and your manager expect at your level?
      - Making your reporting chain successful gives them social capital that they can spend to help you.
    - Will this work be respected?
    - Are you squandering the capital you have built?
  - Skills:
    - Each project will increase or decrease these.
    - Will this project teach you something you want to learn?
    - Will people around you raise your game?
Everything you commit to have an opportunity cost.
Put non meetings in the calendar too:
- Not “make time” but specific items.
Don’t allocate 100% of your time:
- Spikes in work will spill to your personal life.
Increase your skills in three ways:
1. Deliberately learn something: take a class, buy a book, take a toy project.
  - Unlikely to happen at work.
2. Work with someone more skilled.
3. Learn by doing: most common.
What if it is the wrong project?
- If it is temporal, maybe do it.
- Let others lead: mentorship opportunity.
- Resize it.
- Say no.

Chapter 5 - Leading Big Projects

A great project lead has:
- Perseverance.
- Courage.
- Willingness to talk to other people.
The usual reason why a project is difficult is that you are dealing with ambiguity.
Big project == several months + multiple teams.
Number one tool for project success: writing things down.
Ambiguity is the nature of the work.
To make a project less overwhelming at the beginning:
1. Write things down: ideas, leads, rumors, to-dos, …
2. Talk to your sponsor: understand what they want to achieve.
3. Find at least one person that you can be open and unsure with.
4. Give yourself a win: small steps.
5. Use your strengths.
Building context:
1. Goals: why are you doing this project?
2. Understand customers:
  - Working with PMs, ask for their advice.
3. Success metrics.
4. Stakeholders.
5. Figure out fixed constraints.
6. Risks and mitigations.
7. History of the project:
  - Respect what came before.
  - Where it did come from?
  - How was it announced?
  - Who has already tried? What they left behind?
8. Team.
Project structure:
- Define roles:
  - Specially important if multiple senior people are involved.
  - To avoid overlaps and cracks/orphaned work/responsibilities.
  - RACI matrix:
    - Responsible: doing the work.
    - Accountable: only one per task.
    - Consulted.
    - Informed.
  - As a project lead, you will fill any roles that you don’t have someone in them.
- Recruit people that are optimistic, good at conflict resolution and comms.
- Scope and milestones:
  - People don’t act with a sense of urgency until there is a deadline that they cannot avoid thinking about.
- I have met almost nobody who is good at time estimation.
- Estimating should take into account other teams that you depend on:
  - If you ask those teams for last minute changed, you are disrupting the time estimation of other projects.
- Set rituals, comm channels, dev practices.
- Kick off meeting.
Driving the project:
- Avoid the lake! by Kripa Krishnan.
1. Explore:
  - Get to the point where you can concisely explain what different teams in the project want in a way that they’ll agree is accurate:
    - Loads of talking and listening.
  - Build elevator pitch: reduce it to its most important aspects.
2. Clarify:
  - Give mental models for what you are all doing:
    - Hook your model to the person’s existing knowledge.
    - Analogies and metaphors.
  - Glossary: ubiquitous language.
  - Graph/pictures.
3. Design:
  - A written design is a very cheap iteration, Cian Synnott.

We are built for novelty and excitement, not for careful attention to detail. Discipline is something we have to work at. Atul Gawande, The Checklist Manifesto

RFC:
- The implementation should serve the goal; it should not be the goal.
- Design section:
  - Readers should understand what you intend to do, and should be able to tell you whether they think it will work.
  - Better wrong than vague: chance to change direction early.
  - Avoid passive voice:
    - Dr. Rebecca Johnson: If you can insert ‘by zombies’ after the verb, you have passive voice.
  - If it seems trivial, it is because you do not understand it.
  - Any part of your solution that involves humans changing their workflows or behaviour will be difficult and needs to be part of the design.
  - Figure the hard parts earlier.
  - Name who will be on call for any new system.
Coding:
- Writing code is rarely the highest leverage thing you can spend time on.
- Coding gives you a depth of understanding that is hard to gain otherwise.
- Avoid being in the critical path.
- Set example (design, patterns, …).
Communicating well is key for delivering a project in time.
If your project is stuck, don’t hide it: ask for help.
Something will always go wrong:
- Take it as an opportunity to learn.

Chapter 6 - Why Have We Stopped?

Techniques to get unstuck:
1. Understand and explain.
2. Make the work easier.
3. Get org support:
  - Show it is an objective.
  - Show value.
  - Escalate.
4. Make alternative plans.
Supporting an untrained person through making a change in a difficult codebase takes more effort than doing it yourself.
Three bullet points and a call to action:
- Three bullet points detailing the issue at hand.
- One and only one call to action.
Blocked by:
- A decision: make a guess and document it with an ADR.
- A single “please click this button”:
  - Might be a big queue of “just click this button”.
  - The other person is responsible for the result.
- Unassigned work:
  - Rollup the context to make it explicit.
  - Volunteer to mentor/advise/join the team that will own it.
- By a huge crowd of people:
  - Like a migration.
  - Be a bridge
    - The team pushing for the migration to do as much work as possible.
    - Make the new way the default:
      - Consider adding some friction to the old way.
You are stuck:
- Don’t know where you’re all going:
  - No agreement. Too many disparate voices, all interested in the problem:
    1. Clarify roles:
      - Leader is the final decision maker.
    2. Choose strategy:
      - No talk about implementation until all agree about the problem.
      - Don’t try to solve everything neither please everyone.
    3. Choose stakeholder:
      - Reorient the project around getting something to someone.
      - Vertical slices.
- You don’t know how to get there:
  - Path is unknown but not unknowable.
  - Articulate the problem.
  - Revisit your assumptions:
    - Have you already assumed a specific solution?
  - Step away from the problem for a few days.
  - Look for prior art, including outside IT.
  - Connect with the community.
  - Start small.
  - Look at the problem from a completely different angles.
  - Ask for help.
- You don’t know where you stand:
  - Is the work still necessary?
  - Less comms or interest from leadership.
  - Go and ask.
  - You will not get what you want if you don’t ask for it.
Team thinks project is done but problem is not solved:
1. “Finished” but not usable yet:
  - Agree on a definition of done.
  - Be your own user.
  - Celebrate only once users are happy.
2. Done but nobody uses it:
  - Don’t just tell people that the solution exists: you need to keep telling them.
  - Make it easy to find.
3. Built on shaky foundations:
  - If the project is not in good shape by the end of it, it will never be.
  - Set a culture of quality.
  - User stories out of bugs and incidents.
  - Negotiate ring-fencing resources for technical work.
Reasons to stop:
- Further investment is not worth the cost.
- You learn that it will not work.
- Project cancelled by higher management:
  - Even if it is for good reasons, you will feel bad about it.
  - Be the one telling the team.
- You finished! Celebrate!

Part III - Leveling Up

Chapter 7 - You’re a Role Model Now (Sorry)

People assume that you know what you are talking about, so be careful with what you say.
You are a role model: how you behave is how others will behave.
Values is what you do.
The clearest indication of what the company is what gets people promoted.
Attributes of a staff engineer:
1. Competent:
  1. Technically:
    - You can learn a lot from books but there is no substitute for doing it yourself.
    - Do not accept a management role until you are a solid senior engineer.
    - Beware if you are only learning how your company operated, but nothing technical.
  2. Self-aware:
    - What you cant do.
    - How long will take.
    - What you don’t know.
    - Your own context (which will be different from others).
  3. High standards:
    - Seek constructive criticism.
    - Own your mistakes:
      - Communicate clearly and quickly.
      - Set to fix it.
  4. Be reliable: finish what you start.
2. Responsible:
  1. Take ownership:
    - Radiating intent (instead of seeking permission or asking for forgiveness).
    - Make decisions.
    - Ask “obvious” questions: make the implicit explicit.
    - Glue work.
  2. Take charge:
    - Redirecting colleagues to more valuable work.
    - Take control of a mess/incident.
    - Drive meetings:
      - Take notes.
      - Ensure agenda.
      - Keep it focused.
    - Speak up when you see behavioral problems.
  3. Create calm:
    - Make big problems small.
    - Keep small problems small.
    - Be consistent.
    - Take time off.
3. Remember the goal:
  - SW is a means to a goal, not a goal itself.
  - There is always a budget.
4. Look Ahead:
  - Don’t optimize for now at the cost of future velocity or capability.
  - Announce intention to deprecate old systems.
  - Continually make your environment better.
  - Faster safer deploys.
  - Document.
  - Build the expectation of failure into your products.
  - Optimize for maintenance, not creation.
  - Keep it simple: spend at least the same amount of time on possible second solution as you will in the first one.
  - Build with decommission in mind.
  - Create future leaders.
The degree to which other people want to work with you is a direct indication of how successful you’ll be in your career as an engineer. Be the engineer that everyone wants to work with.

Chapter 8 - Good Influence at Scale

Three tiers of influence:
- Individual.
- Group.
- Catalyst: your influence continue even after you step away.
- Do the first two first, only go broader if value is clear.
4 forms:

	Individual	Group	Catalyst
Advice	Mentoring, sharing knowledge, feedback	Tech talks, documentation, articles	Mentorship program, tech talk events
Teaching	Code reviews, design review, coaching, pairing, shadowing	Classes, codelabs	Onboarding curriculum, teaching people to teach
Guardrails	Code review, change review, design review	Processes, linters, style guides	Frameworks, culture change
Opportunity	Delegating, sponsorship, cheerleading, ongoing support	Sharing the spotlight, empowering your team	Creating a culture of opportunity, watching with pride as your superstar junior colleagues change the world

Advise:
- Should be tailored to the person receiving it.
- Mentorship:
  - Sharing your experience so others can leverage on it:
    - Might not be useful/applicable.
  - Don’t jump to give advice, sometimes the mentee just need to vent or get empathy on the situation.
  - Set objectives for mentorship.
- Be kindly honest.
- Peer reviews:
  - 2 audiences:
    - Person who asked for feedback.
    - Their manager.
  - If you cannot think on what to improve, ask yourself why they aren’t one level more senior.
- Encourage people to write things down.
Teaching:
- Code reviews:
  - Careful to not destroy somebody’s confidence and growth mindset.
  - Call out the good as well as the bad.
Guardrails:
- Encourage autonomy, exploration and innovation:
  - They will not stop you going over the edge.
- Reviews:
  - Should the work exists?
  - Does it solve the problem?
  - Will it handle failure?
  - Understandable?
  - Fits the bigger picture?
  - Do the right people know about it?
Opportunity:
- Finding people the experience that they need to grow.
- Delegation:
  - Give them a messy, unscoped project with a bit of a safety net.
  - When you delegate, you are not going to get a clone:
    - Good as long as they achieve the goals.
- Sponsorship:
  - You are investing your time and social capital in their growth.

Chapter 9 - What’s Next?

Expand your perspective by reading, attending conferences and asking others about their journey.
You cannot be an expert in everything.
If the work fills you with dread or exhausts you, instead of exciting you, look for a different path to your goal.
How to network by Vanessa Van Edwards.
Build visibility.
The most time-efficient way to build skills, visibility and contacts is as part of your job. You’ll get better at whatever you spend time on.
Every job should help you grow towards your long-term goals and meet your immediate needs.
Keep a weekly record of your job signals:
1. Are you growing/learning?
2. Are the skills transferable?
3. Would you recruit friends to your company?
4. How is your confidence? How capable you feel?
5. How stressed you feel?
Staying in one place for long gives you the feedback loop that comes from seeing the consequences of your actions.
What to do next:
- You may just want to use your current skills and keep doing much the same job until you retire.
- Promotion.
- Work less:
  - If you weren’t able to avoid working overtime at five days a week, why you think you can stick to working four?
- Change internal team.
- New specialization.
- Management.
- Find/invent your own niche:
  - Learn what your strengths are, and then finding “holes that are shaped like you”.
- Same job, different employer.
- Change jobs and level up or down.
- Your own start-up.
- Go independent.
- Change careers.

Book notes: The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change