Book Summary: The Staff Engineer’s Path by Tanya Reilly
TLDR: The Staff Engineer’s Path by Tanya Reilly helps define the role of staff engineer and provides a plan for succeeding in the role. She does this by exploring what she calls the three pillars of the technical track (big-picture thinking, project execution, and leveling up).
If you are a senior engineer looking to grow your career, I highly recommend this book.
My Key Takeaways
Key Ideas
- Big-picture Thinking
- Spend time consuming information so you have the context across multiple teams.
- Be the glue that helps the team move forward and avoid local maxima.
- Project Execution
- Prioritization – your time is finite. Be deliberate about choosing a primary focus.
- Projects – the agreement & making decisions is often the work.
- Leveling Up
- Scale yourself by writing and growing others.
- Be a responsible leader and role model – your actions influence others, your feedback does too.
Actions
- Make time to build context across your organization.
- Get consent not agreement – ask “can anyone not live with this”?
- Lean into feedback & comments – it makes you better. It’s uncomfortable but that’s what growth feels like.
Big-Picture Thinking
- Gather Context
- Make time for gaining this context – talk with others, make time for reading (plans, RFCs, etc).
- Know your customers for your org and know your peers.
- Be the Glue
- Teams can get stuck in local maxima, solving for their own problems without the proper context of the greater organization. By having this context you can consider goals of multiple teams and solve for that rather than a specific use case which teams might tend to solve for (“it’s easier, why can’t we just. etc”). Teams alone might solve for their problems specifically.
- Handle Ambiguity
- Projects often get stuck because you’re dealing with ambiguity: unclear direction; messy, complicated humans; or legacy systems whose behavior you can’t predict.
- Staff engineers often take on ambiguous, messy, difficult problems and do just enough work on them to make them manageable by someone else. Once the problem is tractable, it becomes a growth opportunity for less experienced engineers (sometimes with support from the staff engineer).
Project Execution
- Alignment – “the agreement is the work”
- Ideas don’t matter, execution does.
- There are plenty of good ideas – the gap is getting folks to agree on what to do.
- Weigh up solutions, make case for what to do, and take the risk by making a decision.
- Balance a project’s time, budget, and scope. You’ll sometimes also hear this framed as “Fast, cheap, good: Pick two.”
- Deciding – Seek Consent not consensus
- Take a tactic from the Internet Engineering Task Force (IETF), whose principles of decision making famously reject “kings, presidents, and voting” in favor of what they call “rough consensus,” positing that “lack of disagreement is more important than agreement.”
- Rather than asking, “Is everyone OK with choice A?” ask, “Can anyone not live with choice A?”
- Decisions constrain possibilities and make it possible to make progress. Not deciding is in itself a decision to maintain the status quo.
- There will always be trade-offs. Be clear what you’re optimizing for when you make decisions.
- Take a tactic from the Internet Engineering Task Force (IETF), whose principles of decision making famously reject “kings, presidents, and voting” in favor of what they call “rough consensus,” positing that “lack of disagreement is more important than agreement.”
- Impact of project – Put the users first
- Whether you built it to spec or not, if you didn’t make your user happy, you built the wrong thing.
- You need to measure success from your users’ point of view.
- Ask internal users: Don’t mentally fill in what you wish they’d said; listen to their actual responses.
- Definition of Done
- Define “done” Before you start the work, agree on what the end state will look like.
- Be clear on what success on the project will look like and how you’ll measure it.
- When you are done, spend time promoting and selling the project to the rest of org.
- Tech Debt
- Software gets maintained for much longer than it takes to create it, so don’t build code that’s hard to maintain.
- “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
- Try to make things as simple as you can.
- Prioritizing
- At the staff engineer level everything you do has a high opportunity cost, so your work needs to be important.
- Your time is finite. Be deliberate about choosing a primary focus. Programming will often not be the best use of your time.
- Make peace with taking no action- you can’t do it all. Make a ticket and let it go sometimes.
- Defend your time – the number of demands will increase while time stays the same. Be deliberate about what you work on and clear when/why you can’t do something else
- If you’re dealing with a big problem, try to make it smaller. If you’re dealing with a small problem, keep it small. When someone brings you a fraught situation, stay calm.
Leveling Up
- Communication
- The more senior you become, the more you will rely on strong communication skills. Almost everything you do will involve conveying information from your brain to other people’s brains and vice versa. The better you are at being understood, the easier your job will be.
- Write
- Write things down. Be clear and opinionated. Wrong gets corrected, vague sticks around.
- You can send information into the future by writing things down. This includes decision records that explain what you were thinking.
- If you’re struggling to begin a conversation with someone, an easy starting point is to ask a question, take an interest in what they work on, or (genuinely) compliment something you admire about them.
- It’s fine to use a few extra words or even repeat yourself if it means avoiding ambiguity.
- Ask questions. Understand why they’re telling you.
- Find opportunities for others – don’t do everything yourself. Give folks a chance to grow. Note this may mean letting someone struggle for a little bit as they learn.
- Understand the impact of your feedback
- Before you offer your thoughts, think about whether the other person is asking for them. Think too about whether you even have enough context to tell them something that’s both helpful and nonobvious. If you’re not sure whether your advice will be welcome, ask them.
- It can help to ask “Do you need space to vent or are you looking for advice?”
- When you’re less experienced, it can be hard to calibrate the advice you’re given. Some things are vitally important, some are nice to have, and some are just personal preference. Annotate your advice so it’s clear.
- This advice works for RFCs too: if your first comment is that the author is solving the wrong problem, it’s not helpful to leave a hundred technical suggestions.
- Role Model – your attitude/behaviors help shape the culture – so be the person you want to see in your org.
- Peer Feedback
- When giving feedback, really think – what could your colleague do better? How could they become more awesome?
- If you can’t think of anything, ask yourself why they aren’t one level more senior (or two!), and give them advice on behaviors they should focus on to get there.
- Three aspects of responsibility: taking ownership, taking charge, and creating calm.
- Your Career is continual learning.
- Charity Majors – CTO of Honeycomb:
- “If you want a sustainable career in tech, you are going to need to keep learning your whole life… Make sure that you a) know yourself and what makes you happy, b) spend your time mostly in alignment with that. Doing things that make you happy gives you energy. Doing things that drain you are antithetical to your success.”
- 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.
- Make it a habit to learn on the job – spend that extra 10-15 minutes to step back and consult the docs or look something up that’s a little fuzzy. Make it a habit.
- Charity Majors – CTO of Honeycomb:
- Embracing Feedback
- Lean into feedback/ comments – it makes you better. It’s uncomfortable but that’s what growth feels like.
- Each comment is an opportunity to make your solution better, so take them seriously even if you don’t use them.
- Your solutions are not you and they don’t define you. Criticism of your work isn’t criticism of you.
Conclusion
- Staff engineering roles are ambiguous by definition. It’s up to you to discover and decide what your role is and what it means for you.
- The metric for success is whether other people want to work with you.
- My Summary:
- [Big Picture] Spend time consuming information so have the context across multiple teams and the org.
- [Project Execution] Your time is finite. Be deliberate about choosing a primary focus. Projects – for many, the agreement/ making decisions is the work.
- [Leveling Up] Scale self by writing and growing others. Be a responsible leader and role model – your actions influence others, your feedback too.
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 The Staff Engineer’s Path (Amazon Associates link)
- Check out Tanya’s blog
Additional Resources
- Staff Engineer by Will Larson
- https://kind.engineering/
- Resources for Writing a Technical Vision:
- Fundamentals of Software Architecture by Mark Richards and Neal Ford
- Chapter 4 of Making Things Happen by Scott Berkun
- The canonical book on strategy is Good Strategy/Bad Strategy by Richard Rumelt
- “OPP (Other People’s Problems)” by Camille Fournier
- Yonatan Zunger’s observation that every project needs core technical skills, project management, product management, and people management.
- The Pragmatic Programmer
- Resources for Technical Writing:
- Vanesssa Van Edwards – How to Network