Scan barcode
A review by erikars
Staff Engineer: Leadership Beyond the Management Track by Will Larson
reflective
medium-paced
3.0
Since I know many folks will be choosing between the two, I want to start with a brief comparison to Tanya Reilly's The Staff Engineer's Path: Both The Staff Engineer's Path and Staff Engineer are full of practical advice about how to be an effective Staff engineer.
Larson's book focuses a bit more on the delta between a Staff engineer and other levels and includes many first hand stories from Staff engineers. Reilly's book is more of a howto guide and applies to anyone who is doing the sort of work Staff engineers do, even if they don't have that title.
Larson's book is terse while Reilly's book is verbose. Although they are nominally similar length, Larson's book is about half interviews from others which are interesting but can be skimmed.
Both are high quality overviews of what it means to be a Staff engineer. I recommend Staff Engineer for someone who wants to laser focus on what makes being a Staff engineer different. I recommend The Staff Engineer's Path for someone who wants more of a guide on how to be an excellent technical leader as an individual contributor, regardless of title. (Personally, I preferred The Staff Engineer's Path.)
(For those earlier in their career, I recommend the imperfect but thorough book The Software Engineer's Guidebook by Gergely Orosz.)
Staff Engineer helped create a shared definition of what it means to be a Staff+ engineer. The premise of the book is that what it means to be a Staff engineer doesn't need to be a mystery. The book covers a lot of ground at a high level, choosing to give a broad picture rather than a deep one.
Larson present four Staff engineer archetypes. People refer to these even outside of the context of the book. The Tech Lead is responsible for setting direction and solving problems for a specific team. The Architect sets direction of a technical area that is key to the company, making sure technical, business, and user needs are aligned. The Solver jumps between a company's most critical problems. The Right Hand works closely with a business leader and jumps in to fight fires, sticking with one just long enough to find the right owner.
Larson describes the responsibilities of a Staff engineer that cross archetypes: setting technical direction, mentorship and sponsorship, providing engineering perspective to leadership, exploring business critical areas, and being glue. They may write software and should definitely keep in touch with the concrete details of their company's systems, but writing code is no longer the primary way they demonstrate value. Staff engineers generally have more responsibility and more visibility than earlier career engineers. However, the key thing to remember is that it is different work. Whether or not it is better depends on whether or not it is work that energizes you.
Being an effective Staff engineer means taking more responsibility for what you work on and how you work on. Staff engineers are rarely given well defined projects. They will often have discretion over how they spend their time. To be effective in this role, Staff engineers need to work on things that are truly important to the company, are getting attention, and where they personally could make a real difference. They should look for opportunities to help others grow. They can also help projects be successful by finding the small edits that make a project less expensive or more impactful or finding ways to help stuck projects finish.
Staff engineers should be working on things that help the company beyond specific projects. They should be writing engineering strategy and building up technical strategy and vision. They should improve technical quality by finding ways to improve core technical problems and generate alignment through best practices, strategy, and other initiatives. This work takes leadership, and the leadership impact of Staff engineering roles goes beyond the technical. Staff engineers also need to stay aligned with authority, learn how to deal well with disagreement, create space for others, network, and communicate well with executives.
The book has a couple of sections on how to become a Staff engineer. Getting to Staff requires developing the right skills, having the right visibility, and some amount of luck, especially around a company having the need for a Staff level project that's aligned with your skill set. However, to increase the odds of becoming Staff, engineers can be intentional about creating an ongoing promotion packet that they review with their manager, finding a sponsor and being visible (including developing relationships with leaders beyond your manager). It often, but not always, involves a Staff project, a project that is complex, ambiguous, impactful, has numerous stakeholders with various opinions, and are in areas where success or failure really matters to the company. Even doing all of this, an engineer may find that they are unlikely ever to achieve Staff in their current role, so the book discusses considerations and tactics for deciding to switch roles or companies.
The book ends with a bunch of interviews with Staff engineers. The interviews were somewhat repetitive since the book pulled the best from them and incorporated it directly, but it was valuable for getting a bit more context on the individuals and their roles. Overall, I recommend skimming them and focusing your attention on the ones that are most personally interesting to you. It also includes some interesting appendices, including one on managing Staff engineers that, as a manager, I find valuable.
Overall, this book was a valuable overview of the landscape of the Staff engineer role in tech. It was very broad, and there were times I wished for more depth, but depth vs breadth is always a hard balance that will vary from reader to reader. Overall, this is a good read for anyone who is a Staff engineer (especially a new Staff engineer or one looking for a change), wants to become a Staff engineer, or wants to help others grow into a Staff engineer roles.
Larson's book focuses a bit more on the delta between a Staff engineer and other levels and includes many first hand stories from Staff engineers. Reilly's book is more of a howto guide and applies to anyone who is doing the sort of work Staff engineers do, even if they don't have that title.
Larson's book is terse while Reilly's book is verbose. Although they are nominally similar length, Larson's book is about half interviews from others which are interesting but can be skimmed.
Both are high quality overviews of what it means to be a Staff engineer. I recommend Staff Engineer for someone who wants to laser focus on what makes being a Staff engineer different. I recommend The Staff Engineer's Path for someone who wants more of a guide on how to be an excellent technical leader as an individual contributor, regardless of title. (Personally, I preferred The Staff Engineer's Path.)
(For those earlier in their career, I recommend the imperfect but thorough book The Software Engineer's Guidebook by Gergely Orosz.)
Staff Engineer helped create a shared definition of what it means to be a Staff+ engineer. The premise of the book is that what it means to be a Staff engineer doesn't need to be a mystery. The book covers a lot of ground at a high level, choosing to give a broad picture rather than a deep one.
Larson present four Staff engineer archetypes. People refer to these even outside of the context of the book. The Tech Lead is responsible for setting direction and solving problems for a specific team. The Architect sets direction of a technical area that is key to the company, making sure technical, business, and user needs are aligned. The Solver jumps between a company's most critical problems. The Right Hand works closely with a business leader and jumps in to fight fires, sticking with one just long enough to find the right owner.
Larson describes the responsibilities of a Staff engineer that cross archetypes: setting technical direction, mentorship and sponsorship, providing engineering perspective to leadership, exploring business critical areas, and being glue. They may write software and should definitely keep in touch with the concrete details of their company's systems, but writing code is no longer the primary way they demonstrate value. Staff engineers generally have more responsibility and more visibility than earlier career engineers. However, the key thing to remember is that it is different work. Whether or not it is better depends on whether or not it is work that energizes you.
Being an effective Staff engineer means taking more responsibility for what you work on and how you work on. Staff engineers are rarely given well defined projects. They will often have discretion over how they spend their time. To be effective in this role, Staff engineers need to work on things that are truly important to the company, are getting attention, and where they personally could make a real difference. They should look for opportunities to help others grow. They can also help projects be successful by finding the small edits that make a project less expensive or more impactful or finding ways to help stuck projects finish.
Staff engineers should be working on things that help the company beyond specific projects. They should be writing engineering strategy and building up technical strategy and vision. They should improve technical quality by finding ways to improve core technical problems and generate alignment through best practices, strategy, and other initiatives. This work takes leadership, and the leadership impact of Staff engineering roles goes beyond the technical. Staff engineers also need to stay aligned with authority, learn how to deal well with disagreement, create space for others, network, and communicate well with executives.
The book has a couple of sections on how to become a Staff engineer. Getting to Staff requires developing the right skills, having the right visibility, and some amount of luck, especially around a company having the need for a Staff level project that's aligned with your skill set. However, to increase the odds of becoming Staff, engineers can be intentional about creating an ongoing promotion packet that they review with their manager, finding a sponsor and being visible (including developing relationships with leaders beyond your manager). It often, but not always, involves a Staff project, a project that is complex, ambiguous, impactful, has numerous stakeholders with various opinions, and are in areas where success or failure really matters to the company. Even doing all of this, an engineer may find that they are unlikely ever to achieve Staff in their current role, so the book discusses considerations and tactics for deciding to switch roles or companies.
The book ends with a bunch of interviews with Staff engineers. The interviews were somewhat repetitive since the book pulled the best from them and incorporated it directly, but it was valuable for getting a bit more context on the individuals and their roles. Overall, I recommend skimming them and focusing your attention on the ones that are most personally interesting to you. It also includes some interesting appendices, including one on managing Staff engineers that, as a manager, I find valuable.
Overall, this book was a valuable overview of the landscape of the Staff engineer role in tech. It was very broad, and there were times I wished for more depth, but depth vs breadth is always a hard balance that will vary from reader to reader. Overall, this is a good read for anyone who is a Staff engineer (especially a new Staff engineer or one looking for a change), wants to become a Staff engineer, or wants to help others grow into a Staff engineer roles.