A guide with discussion prompts for Tanya Reilly's The Staff Engineer's Path .
The Staff Engineer's Path (2022) is one of the few books that talk about what it's like to continue growing on an individual contributor path rather than a people management path. Will Larson's Staff Engineer is one of the others, and both have been published only in the last two years. Both books have been some of the most important ones that I've read in 2023.
I run the engineering book club at my current company, Attentive . For the pace of our book club, we committed to reading 2 chapters every 2 weeks. I personally appreciate having multiple discussions over time, I find I better retain content that way. These are the exact discussion prompts I used over the few months of reading the book, so they're colored by my personal experience and the current culture at Attentive. All prompts are wholly my own and are free to use by all.
Author's website: No Idea Blog .
Resources mentioned in the book: resource list .
Foreword, introduction
- Intro: the book is divided into sections for the three pillars: big-picture thinking, [project] execution, and leveling up [others]. Which of these are you most looking forward to reading about & discussing? In what area do you think you're the weakest?
Chapter 1
The author says engineering job titles matter, for a number of reasons. Do you agree?
- What do you think of your organization's individual contributor career ladder? Does it do a good job describing a gradient of career skills? Do you think there are any missing intermediate titles? Do you think there are any hidden glass ceilings that are challenging to be promoted past?
Staff Engineer responsibilities are ambiguous, by design. Have you struggled with ambiguity in your role, and how have you dealt with it?
If you're always coding, then you won't be able to focus on other types of tasks and skills. Do you make time for learning & practicing other skills? Do you have techniques that have been effective for you?
Chapter 2
The more time you spend in your domain, the more bias you develop for its organizational importance, as well as developing a blindness to some of its recurring problems. Do you regret any unique solutions your team has that, in hindsight, would have benefited from a generalized solution? Does your team own complex and organizationally important components that other teams seemingly trivialize?
Do you find it difficult to make cross-team decisions or get cross-team traction on ideas? Have you found effective ways to combat this in your organization?
- Can you attribute this difficulty to any of the cultural points in the book (secret or open [information sharing], oral or written [decision making], top-down or bottom-up [decision making], fast change or deliberate change, back channel or front door [communication], [over-]allocated or available [developer time], liquid or crystallized [status & promotion])?
There are many pitfalls for your team and your interactions with other teams if there aren't shared goals in your organization. Do you know what your organization's goals are? Could you succinctly describe them to someone outside your organization?
- Does your organization do a good job of sticking to these goals? What short-term goals have distracted your team, or almost distracted your team?
Chapter 3
Do you know what your organization's technical vision is? Do you know what steps the technical strategy has laid out to get there? How did you help contribute to either?
Many individual contributors do not write technical vision & strategy docs frequently, but the author quotes Patrick Shields who says "you need to learn to play amateur basketball before you drop into the NBA." How do you practice skills & responsibilities at titles above yours?
- (This is related to the above prompt about difficulty getting traction on decisions.)
Chapter 4
- The example staff+ "dashboard" of needs are: energy, credibility, quality of life, skills [learning], and social capital. Which of these did you relate to? Which of these are you optimizing for right now? What needs would you add or remove from the list, based on your role & responsibilities?
- The book has a strong message of being deliberate about how & where you spend your time & energy, including a warning against "snacking " too often (Eisenhower matrix quadrant 4). Do you find yourself working on non-urgent, non-important work for quick wins and fast feedback?
- Do you find that back-burner work (wishlist items, quality of life improvements, etc.) takes up a lot of mental space for you, eating into your time? What kind of work have you had to "torch" off your back-burner, even if it was emotional to do so?
- A friend of the author's said "you don't get to [a high title, such as VP of engineering,] without knowing how to defend your time." What are your techniques for defending your time?
Chapter 5
- The book describes leading a multi-team project with multiple unknowns as overwhelming, but projects of smaller scope can be just as overwhelming to different engineers. What strategies do you use to break down projects and make them more approachable and less overwhelming?
Chapter 6
- The author details a lot of reasons why an outside person or team may be blocking a project, many of them being unseen stressors on those people. A lot of paragraphs encourage taking an empathetic approach, ensuring to not diminish their challenges and instead ask questions for understanding. What job stressors have you or your team had that you found challenging to convey to others depending on your work?
- "Unassigned" work is generally the result of new work that needs to happen that doesn't obviously fit one team's responsibilities better than another. Even if the work is blocking a larger project, teams may be concerned about the cost of long-term ownership of something new. What unassigned work like this have you seen in your past projects? How was it resolved?
- Even after achieving a project's goals, it may be challenging to call the project "done, done." A suggestion to combat this is to define what "done" looks like at the start of the project. What projects have you had that lingered on past their deadline because they weren't "done"? What kept them from being considered done (e.g. rollout period, technical cleanup, writing runbooks. etc.)?
Chapter 7
- It's likely that you have had (and still have) career role models that have shaped you, whether they know it or not. What habits, behaviors, phrases, or mindsets did you learn from them that you still carry to this day?
Chapter 8
- What is the best advice you've received in your career? What was the advice giver's relationship to you? Was it solicited? What was the worst advice you've received?
- Building education materials is a way to scale your ability to teach. What onboarding material, how-to guides, or classes have you created that withstood the test of time? What do you think made them so long-lasting? How were you able to measure their impact?
- Sometimes guard rails can go too far and make people feel limited. Have you felt this in the past, or now? Have you seen guard rails get dismantled? How did that come about, and how was it received?
- Sponsorship is far more active than coaching and mentoring, and generally less well understood. Have you had a sponsor in your career that significantly impacted you? How did they amplify, boost, connect, or defend you with their political power? Have you been able to be a sponsor to someone?
Chapter 9
- One suggestion the author gives is to track some number of key job satisfaction points over time, to be able to plot a trend line. Do you do this, or something like it? Is it effective for you?
- It's easy to forget that the 4-5 years it can take to become "senior" is not a long time in one's career. Do you have a personal story where you realized there is still so much that you don't know, especially after being promoted to a senior developer?
