Scan barcode
erikars's review against another edition
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.
elainewlin's review
3.0
I like the tips for operating as a staff engineer and the variety of interviews. One problem I found is that the book repeats itself and has too many external links to resources. The first half of the book repeats chunks of interviews. Some sentences reference 2-3 external links, so they're hard to understand. Before reading this book, it would be useful to read Tanya Reilly's piece on glue work and Lara Hogan's piece on mentorship vs. sponsorship because they are mentioned quite often.
naleagdeco's review
5.0
This book is a very valuable one to read if one is at the senior level and is wondering how they should move forward with their career. I'm not 100% sure if if it has motivated me to pursue or to decline pursuing a formal staff engineering role, but as I find myself ad-hoc filling in organizational and process gaps at my company, out of professionalism and a desire to grow, I do appreciate a book that maps out the potential ramifications and potential structured ways to do this.
In many ways, I think any senior engineer should read this book even if they decide they don't want to change their job title. The ability to recognize the organizational and process gaps that this book discussess, as well as foramlizing the need for performing the glue and collaboration and non-heads-down work that the stereotypical developer tries to shrug off onto others, was a very useful framework for me to wrap my head around as I navigate my career. Even I decide that I'm fine where I am, I think that this book allows me to adopt aspects of this seeming staff model even as a mere senior engineer in the near term.
I felt many strong feelings, both in agreement and in opposition to the book, as I read it. I suppose that's the point; I don't like a lot of the directions this book points in, but it's very possible that I have to accept that this is the current evolution of the software development industry, especially as the current pandemic/remote-work trend brought NY/Bay-Area-Engineering-Culture out to the rest of the areas where software developers work. In that sense, I'm glad this book at least gives me a bunch of things to anticipate and grapple with should I decide to go down this path.
I originally thought that the interview sections at the end would be a giant denoument, and I went over each person's story much quicker than I did the first part of the book, but there are some gems in how people talked about their particular individual experiences that both clarified what I did not want my future to move towards, as well as comforted me by knowing that there were anxieties or seemingly unideal daily work patterns that were more common than I was anticipating. In that sense, the stories were a nice grounding to balance out the theoretical ideal that the first half maps out.
I am very happy at how many links this book supplies for further reading. This book, if nothing else, serves as a starting point into a large curated set of worthwhile writing on the industry.
In many ways, I think any senior engineer should read this book even if they decide they don't want to change their job title. The ability to recognize the organizational and process gaps that this book discussess, as well as foramlizing the need for performing the glue and collaboration and non-heads-down work that the stereotypical developer tries to shrug off onto others, was a very useful framework for me to wrap my head around as I navigate my career. Even I decide that I'm fine where I am, I think that this book allows me to adopt aspects of this seeming staff model even as a mere senior engineer in the near term.
I felt many strong feelings, both in agreement and in opposition to the book, as I read it. I suppose that's the point; I don't like a lot of the directions this book points in, but it's very possible that I have to accept that this is the current evolution of the software development industry, especially as the current pandemic/remote-work trend brought NY/Bay-Area-Engineering-Culture out to the rest of the areas where software developers work. In that sense, I'm glad this book at least gives me a bunch of things to anticipate and grapple with should I decide to go down this path.
I originally thought that the interview sections at the end would be a giant denoument, and I went over each person's story much quicker than I did the first part of the book, but there are some gems in how people talked about their particular individual experiences that both clarified what I did not want my future to move towards, as well as comforted me by knowing that there were anxieties or seemingly unideal daily work patterns that were more common than I was anticipating. In that sense, the stories were a nice grounding to balance out the theoretical ideal that the first half maps out.
I am very happy at how many links this book supplies for further reading. This book, if nothing else, serves as a starting point into a large curated set of worthwhile writing on the industry.
drubin87's review
5.0
Such a great read. The 2nd half of the book can feel a little repetitive as it's interviews with different engineers from different companies and many have the same things to say but this just re-enforces the message.
Highly recommended for any senior engineer trying to grow into the next step that isn't keen on Management track.
Highly recommended for any senior engineer trying to grow into the next step that isn't keen on Management track.