Take a photo of a barcode or cover
54 reviews for:
The Staff Engineer's Path: A Guide For Individual Contributors Navigating Growth and Change
Tanya Reilly
54 reviews for:
The Staff Engineer's Path: A Guide For Individual Contributors Navigating Growth and Change
Tanya Reilly
informative
fast-paced
A book I wish existed at the beginning of my career. Despite what the title says, this is a good primer for working in (tech) organizations and maps out part of the progression as a technical person within the organization. There is a lot of good but slightly disorganized tactical advice on various aspects of a tech career. Would be useful to keep in a shelf as a reference for navigating certain work situations.
informative
medium-paced
funny
informative
inspiring
reflective
medium-paced
Amazing and informative book. I’m a mid level engineer and it was really insightful to learn what opportunities are available in the non-manager track.
Also very applicable to me in my current role, so recommend to anyone who is at least a mid to read.
Also very applicable to me in my current role, so recommend to anyone who is at least a mid to read.
informative
lighthearted
reflective
medium-paced
challenging
funny
informative
inspiring
reflective
medium-paced
medium-paced
Since I know many folks will be choosing between the two, I want to start with a brief comparison to Will Larson's Staff Engineer: 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.)
Digging into more depth on The Staff Engineer's Path:
There's a common career fork for software engineers: the management path or the individual contributor path. This book aims to illuminate the individual contributor path for Staff or higher-level engineers. A Staff engineer is in a leadership role and is responsible for big picture thinking, execution (even when it's messy), and leveling up those around them. They do this on top of a solid foundation of technical knowledge.
What I liked about this book is that it provided a lot of practical advice with clear, actionable steps about how to do well as a Staff engineer. What I didn't like about this book was that it was too verbose at times. Often I found myself reading a 1-2 paragraph section where a sentence would have sufficed.
On a more positive note, the chapters on technical vision and strategy, executing projects, and finishing them contained excellent advice for anyone acting as a technical lead, regardless of title. I hope that people interested in those topics don't skip the book because they don't see a book on Staff engineering as relevant. In particular, engineering managers providing technical guidance to their team should read those chapters for themselves (and the rest to better provide career guidance).
Being a Staff engineer extends the skill expected of software engineers to include communication, leadership, navigating complexity, communicating about your work, mentorship, sponsorship, delegation, and framing problems for others. Sometimes they do individual work and sometimes they focus on supporting others and their organization.
This book dives into what it looks like to do these things well. It covers a mix of philosophical principles and pragmatic advice. The book starts by defining what a Staff engineer is in terms of scope and role. There are different styles of Staff engineers, but common threads are that they are autonomous and they are leaders.
To understand their role in an organization and how they can bring value, Staff engineers can create three "maps" that provide the context they need to be successful. The Locator Map describes where they are in the broader organization. The Topographical Map lays out the organizational hazards and culture. The Treasure Map puts goals into perspective. Together, these three maps help you understand how to successfully impact your organization by helping you understand what is impactful and how to work within your organization.
There is a chapter on how to create a technical vision and strategy. It provides a detailed description of both the process and the content of these artifacts. After that are several chapters on how to execute successfully, including how to prioritize your own limited time, how to lead big projects, and how to finish big projects. As with the chapter on creating a vision and strategy, these chapters contain a lot of practical advice and step by step guidance.
While the second and, to a large degree, the first part of the book cover what it means to be a technical leader, the third part focuses on being a cultural leader. A Staff engineer is a role model, and you need to act like one by building competence in yourself and others, being responsible for making sure the right problems are solved end-to-end, and looking ahead to build for the future. In addition to doing this through your own work, a Staff engineer will influence the organizational and company culture through helping to up level individuals and groups. They should also aim to become a catalyst for change by enabling others to help the organization improve. They can do this by offering advice, teaching others, providing guardrails that prevent mistakes, and providing opportunities for others to grow.
The book ends with a discussion on managing your career long-term. You need to understand what is important to you so that you can make decisions about if and when to change companies, how to evolve or completely shift your role, and how to make sure that your role is aligned with your goals.
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.)
Digging into more depth on The Staff Engineer's Path:
There's a common career fork for software engineers: the management path or the individual contributor path. This book aims to illuminate the individual contributor path for Staff or higher-level engineers. A Staff engineer is in a leadership role and is responsible for big picture thinking, execution (even when it's messy), and leveling up those around them. They do this on top of a solid foundation of technical knowledge.
What I liked about this book is that it provided a lot of practical advice with clear, actionable steps about how to do well as a Staff engineer. What I didn't like about this book was that it was too verbose at times. Often I found myself reading a 1-2 paragraph section where a sentence would have sufficed.
On a more positive note, the chapters on technical vision and strategy, executing projects, and finishing them contained excellent advice for anyone acting as a technical lead, regardless of title. I hope that people interested in those topics don't skip the book because they don't see a book on Staff engineering as relevant. In particular, engineering managers providing technical guidance to their team should read those chapters for themselves (and the rest to better provide career guidance).
Being a Staff engineer extends the skill expected of software engineers to include communication, leadership, navigating complexity, communicating about your work, mentorship, sponsorship, delegation, and framing problems for others. Sometimes they do individual work and sometimes they focus on supporting others and their organization.
This book dives into what it looks like to do these things well. It covers a mix of philosophical principles and pragmatic advice. The book starts by defining what a Staff engineer is in terms of scope and role. There are different styles of Staff engineers, but common threads are that they are autonomous and they are leaders.
To understand their role in an organization and how they can bring value, Staff engineers can create three "maps" that provide the context they need to be successful. The Locator Map describes where they are in the broader organization. The Topographical Map lays out the organizational hazards and culture. The Treasure Map puts goals into perspective. Together, these three maps help you understand how to successfully impact your organization by helping you understand what is impactful and how to work within your organization.
There is a chapter on how to create a technical vision and strategy. It provides a detailed description of both the process and the content of these artifacts. After that are several chapters on how to execute successfully, including how to prioritize your own limited time, how to lead big projects, and how to finish big projects. As with the chapter on creating a vision and strategy, these chapters contain a lot of practical advice and step by step guidance.
While the second and, to a large degree, the first part of the book cover what it means to be a technical leader, the third part focuses on being a cultural leader. A Staff engineer is a role model, and you need to act like one by building competence in yourself and others, being responsible for making sure the right problems are solved end-to-end, and looking ahead to build for the future. In addition to doing this through your own work, a Staff engineer will influence the organizational and company culture through helping to up level individuals and groups. They should also aim to become a catalyst for change by enabling others to help the organization improve. They can do this by offering advice, teaching others, providing guardrails that prevent mistakes, and providing opportunities for others to grow.
The book ends with a discussion on managing your career long-term. You need to understand what is important to you so that you can make decisions about if and when to change companies, how to evolve or completely shift your role, and how to make sure that your role is aligned with your goals.
medium-paced
An easy read, helped make me an informed decision about moving to a staff engineer role, and single handedly gave me the answers I needed to ace the interview. Thoroughly recommend