For years, companies have rewarded their most effective engineers with management positions. But treating management as the default path for an engineer with leadership ability doesn't serve the industry well--or the engineer. The staff engineer's path allows engineers to contribute at a high level as role models, driving big projects, determining technical strategy, and raising everyone's skills.
This in-depth book shows you how to understand your role, manage your time, master strategic thinking, and set the standard for technical work. You'll read about how to be a leader without direct authority, how to plan ahead to make the right technical decisions, and how to make everyone around you better, while still growing as an expert in your domain.
By exploring the three pillars of a staff engineer's job, Tanya Reilly, a veteran of the staff engineer track, shows you how
Take a broad, strategic view when thinking about your work Dive into practical tactics for making projects succeed Determine what good engineering means in your organization
Five stars, undisputed. It's one of those few precious non-fiction books where it's more than clear that the author is a real expert who didn't have to struggle when collecting the ideas for the book :)
What did I like most about this book: * good, logical organization * no Cpt. Obvious mode * useful, practical mental models * the book is peppered with valuable references * just meat, no fluff * models presented are flexible and adaptable - there are no strong/opinionated dependencies on frameworks or career progression models
The best way to quantify the quality of such a book is the number of notes taken - I don't remember making that many for approx. 2 years :D
This book is excellent. I just finished it and already want to go back and reference sections to help me think about my role and career.
I found Will Larson’s Staff Engineer book enjoyable and a good intro to the role, but this book is much better for practical knowledge and information on how to excel as a senior & staff+ engineer.
My only real complaint is I wish I had this book to read 10 years ago when I was an early senior engineer.
Quite a good one. While reading I was constantly comparing it to Will Larson's "Staff Engineer", and still can't say I have a definite winner. Both are quite short and easy to read, so if you have time - read both, otherwise probably any of them would be good. Regarding content of the book itself: I. "The Big Picture" - good overview of some "high-level" / "high-impact" activities you're now expected to do, and things you probably haven't done before, like writing some technical visions / strategies, that would be quite different from usual design docs. II and III - these are still good, though probably not that much "staff-specific". It depends, obviously, but usually senior engineers are expected to lead on projects (maybe not spanning 3+ teams, but several smaller "pods" - quite possible), write design docs etc. Advice on building / improving engineering culture are also applicable to any role - as all engineers are probably doing code reviews and commenting on design docs.
One thing that also been "memorable" to me, author's warnings on "glue work" and delegating - perception of this work depends on the level (staff doing glue work can be seen as "showing leadership", while mid-level engineer might not be given such credit), and expectations need to be discussed with manager, to make sure that we're aligned on how much "individual contribution" is expected.
Exquisite guide for senior/staff/principal engineers in navigating the workplace dynamics and demonstrating leadership outside of traditional manager roles. Tanya Reilly reinforces frameworks and models with practical guidance in executing complex projects, exerting influence without direct authority, and overall systems thinking. Excellent desk reference. I wish I read this earlier in my career.
I don't think there's currently a better book than this for its purpose. If you're a software engineer looking for advice, tools and relevant stories on how to grow in the technical space while having to deal with all the human aspects of the work (project management, coaching and mentoring, discussing the next goals of your team...), this book is for you.
I like how clear and concise the author is, while also aiming for completeness. This is accomplished by adding A LOT of references to websites, blog articles and other books that might cover more deeply the specifics of a certain topic, while also adding the relevant summary so that you can start working on the ideas. This makes the book really accessible and light to read, while also being very dense and interesting in content.
Finally, I love how the author shows actual care for human relationships and care. Her comments and advice are totally up to date in matters like diversity and inclusion, and there are many details I really appreciate she brings up so that I can take them into consideration.
This is an excellent reference manual for any day I need to remember how to do my work or how to plan for the next thing. I definitely encourage other software engineers to also take this book and become with it better professionals (and people, which for what matters, are practically equivalent things).
I loved this book. Not only does it have the clearest explanation of the Staff+ role that I've seen communicated so far, it is also great at providing frameworks that are widely applicable for doing the job. I also loved that it has helped me discover other cool resources and people I should follow.
This is an extremely good book. I was reading an early release at Oreilly site, and suspect that a final release will contain at least a one chapter more.
The only similar stuff I've read on the topic was "Becoming the Tech Lead" by Gary Weinberg. Both of the books are very deep, but the current one is very well organised, and very up-to-date.
Has some useful, actionable advice for many levels of the software engineering ladder but much of the book is laundry lists of obvious things that I found myself frequently skipping over.
Paradigm Shifting Book on Career Growth & Long-term Impact in the Tech Industry
According to Sandro Mancuso, there are 4 kinds of books we have read to advance our careers:
1- Technology-specific books are very valuable but they expire. 2- Conceptual books are the books that give us the foundation to advance in our careers. 3- Behavioral books are the books that make us more efficient when working in teams and organizing ourselves. 4- Revolutionary books (some call them classics) are the ones that changed the way we work.
We should favor conceptual and behavioral books for long-term career progression, starting with the revolutionary ones and read technology-specific books for short and medium-term plans.
Tanya's book is a technology-agnostic, conceptual & behavioral book at the same time and to me already revolutionary. It has all the elements to change the way we work as an industry.
I read the early release of this book on O’Reilly back in April and I have been catching up on every new chapter as Tanya wrote them. I have accumulated hundreds of notes and highlights useful not only to Staff Engineers, but to Directors of Engineering like myself and to be honest to any Engineering Leadership role.
Well-articulated, useful, and surprisingly succinct for a "how to" book. After you "learn how to do the work" what comes next? As all engineers will note, you can have more impact if you can scale. If you can create dominoes of positive feedback loops, culture, and capabilities throughout your teams and organizations, you might be a staff engineer (or on your way). There are some great tips in here for how to unblock work for others, navigate competing priorities as an individual and as a contributor within a business. This book can help you understand what some of the opportunities and skills might look like at your job and how to be deliberate about seeking them out. Should note also, these are skills likely good to have as you advance in any career, so don't drop sleep on this book just because you aren't an engineer.
Расстроен тем, что потратил время на эту книгу. Книга называется staff engineer, хотя рассказывает о похождения engineering manager: опять нам рассказывают, что важно направлять людей вокруг, а не что-то делать со своей экспертизей.
В общем, кому читать: миддлы, которые хотят понять как работают их тимлиды, и как эффективно взаимодействовать.
Кроме того, есть ещё и претензии к самому формату: куча ссылок на более цельные посты (за них спасибо!), отступления в которых не даётся утверждений для текущей главы.
На фоне Become an Effective Engineering Manager - очень слабо. Рекомендую вместо этой книжки прочитать её.
Мені дуже довго бракувало такої книги. Вона буде корисною всім, хто досягнув впевненого рівня володінням інженерними навичками і хто тепер замислюється про майбутнє своєї кар'єри, адже ніхто окрім вас самих не зможе дати відповідь на це запитання. Акцентом книги є так важливий для будь якого інженера аспект індивідуального внеску, (individual contribution) який часто слугує головним рушієм рішення продовжувати займатися розробкою програмних продуктів та систем адже безпосереднє створення продуктів і споглядання результатів своєї праці є надзвичайно надихаючим.
Часто так виходить, що нетехнічні книги, написані інженерами, приносять велику насолоду їх читати. Звичайно є виключення, але ця книга є особливо гарним прикладом. Текст випромінює послідовність та ясність думок, рясніє корисними посиланнями та цілісністю побудованого наративу. Без перебільшення, книга може бути корисною не тільки у контексті програмної інженерії, але і у контексті інженерії як просто домену різних технічних професій.
Будь який інженер чи інженерка на початку їхньої карʼєри мають на меті досягти високого рівня автономності завдяки розвитку гнучких навичків (softskills) та не менш високого рівня кваліфікації та здатності виконувати складні технологічні задачі завдяки накопиченому досвіду та знань (hardskills) їхнього домену. Наступним перед ними стоїть вибір: або залишатися там де вони є, або ж рухатися у менеджмент. Звичайно, коли у людини є такий запит взагалі кудись рухатися, бо відсутність такого запиту є цілковитою нормою і багатьох безспосердня інженерна робота і виконання поставлених завдань є всецілою працею, що приносить вдоволення та наповнення. Та це не весь наявний вибір. Книга досліджує лідерських інженерний карʼєрний шлях, що йде паралельно шляху менеджера. Порівнюючи з останнім, про який написано тисячі і тисячі книг, шлях інженера-лідера є менш досліджений, незважаючи на те, що посади, які відповідають цьому шляху, є досить поширеними на всьому спектрі інженерних компаній. Серед таких посад є Tech Lead, Team Leads, Architects, Staff Engineers, Principal Engineers тощо.
Ця книга є дуже вагомим внеском у роз'яснення такого шляху. Він розглядається як тіло, що стоїть на трьох ногах: уміння бачити більшу картину, уміння бути рушієм виконання проектів, уміння покращувати навички інженерів навколо. Ці три стовпи відображають і саму структуру книги, яка дає багато гарних порад, спостережень, ділиться очікуваннями які інженер має мати від середовища у якому він знаходиться і навпаки, що має очікувати середовище від інженера.
Незамінна книга для будь кого, хто 5+ років у програмній чи будь якій інженерії
This book definitely falls under my long-term reference handbooks bucket.
Tanya did a fantastic job first breaking down what it means to be a Staff Software Engineer and then outlining how to navigate this position. The guidance here isn't restricted to SWE positions but pretty much any senior-level role that involves working with other individuals to influence organizational challenges.
I was initially hesitant to read this book given that the software engineer path is not something I'm personally going to continue, hence this was to identify anti-goals. Surprisingly, this helped me identify some goals I still need to work towards before parting ways with this path and provided a loose guide for any senior-level position I choose to pursue.
The book can get verbose and feel repetitive but I chose to speed-read this as part of a book club so I would highly recommend discussing this with your peers. The
This is a fantastic book for anyone who has grown into a senior engineer within an organization and is looking for ways to make a positive impact. Overall, I would rate this book as one of the best for engineers, just behind "Designing Data-Intensive Applications."
For any fellow Engineer out there still figuring what means to be in Staff+ a position I couldn't recommend this book enough.
It contains a myriad of helpful information on how to be effective and ensure you leverage your skills to impact the Engineering culture of the company.
Пам’ятай, що ти приклад для наслідування, вмій ефективно вирішувати блокери, синхронізуй роботу декількох команд.
Найбільше сподобався принцип - radiate intent. Оголошуй те, що збираєшся зробити. Таким чином ти даєш можливість втрутитись іншим і береш на себе відповідальність за результат.
I didn’t like it as much as the Manager’s Path. I think that the staff role has evolved in the past few years beyond these archetypes. I think the senior role has also expanded to include these considerations.
It’s a great resource and I can see why my mentor recommended it. However, I’m not sure if I really learned anything new.
This is not a book you read once. It's a bible worth coming back to, and reference! See my highlights!
Staff ENG = big-picture thinking + execution of projects + leveling up the engineers you work with.
Key takeaways:
1. The Transition to Staff Engineer requires a shift in your focus: as a staff engineer, your success is no longer measured solely by the code you write but by the impact you have on the team and the organization.
2. Driving Technical Strategy - Long-Term Thinking: Develop a clear understanding of the company’s technical landscape and ensure decisions align with strategic goals. - Balancing Trade-offs: Understand and navigate trade-offs between short-term deliverables and long-term scalability or maintainability. - Stay up to date with industry: see how they solve problems, and what innovations they bring. - Well-written technical strategy heuristics: captures mitigations for all risks of the proposed change, has completed lengthy checklists or capacity estimates, or replies to huge numbers of document comments with acceptable answers. - any big effort that doesn’t have high-level support is unlikely to succeed - Be clear on what success on the project will look like and how you’ll measure it. Leading a project means deliberately driving it, not just letting things happen. Smooth your path by building relationships and deliberately setting out to build trust. Write things down. Be clear and opinionated. Wrong gets corrected, vague sticks around. There will always be trade-offs. Be clear what you’re optimizing for when you make decisions. Communicate frequently with your audience in mind. Expect problems to arise. Make plans that assume there will be changes in direction, people quitting, and unavailable dependencies. - Resources for writing vision and strategy: * How to Set the Technical Direction for Your Team: https://jlhood.com/how-to-set-team-te... * Technical strategy power chords: https://leaddev.com/technical-directi... * Getting to Commitment: Tackling broad technical problems in large organizations: https://leaddev.com/technical-directi... * A survey of engineering strategies: https://lethain.com/survey-of-enginee...
3. Relationships are key! - Staff+ ENG needs to be excellent at Cross-functional collaboration by collaborating effectively with other teams and stakeholders to drive alignment and remove roadblocks. - Mentorship: Act as a mentor to other engineers, fostering growth and building a culture of knowledge sharing. - work that matters to the people in your reporting chain is work that builds social capital - Managing up includes understanding your boss’s priorities, giving them the information they need, and solving the problems that are in their way—in other words, helping them be successful. Their success gives them social capital that they can spend to help you.
4. Decision-Making - Owning Decisions: Take responsibility for tough technical decisions, and be prepared to justify and stand by them. Wrong Is Better Than Vague. Wrong gets corrected, but vague sticks around. - Clarity and Communication: Clearly articulate complex technical concepts to different audiences, ensuring alignment. - Know where decisions are made, by who, and who the key influencers of these decisions are. Know the “shadow org chart” (unwritten structures through which power and influence flow). Admin might be your best resource for that!
5. Influence and Impact - Leadership Without Authority: You lead through influence, collaboration, and technical vision rather than direct managerial authority. What makes a great project lead? It’s rarely genius: it’s perseverance, courage, and a willingness to talk to other people. The leader’s job is to “aggressively delegate.” - Driving Change: Use your position to advocate for meaningful change in technical practices, tooling, or culture. - Measuring Impact: Focus on outcomes (e.g., team efficiency, product reliability) rather than outputs (e.g., lines of code). - Your social capital and peer credibility are “bank accounts” that you can pay into and spend from. - When writing guidelines strive to keep balance. If you write nothing down, most people hate that and complain that they don’t know how to do anything. If you write down guidelines, people interpret them as law and argue that they’re wrong because they don’t cover edge cases. And if you write down every edge case, you end up with a three-ring binder of policy and legalese, and it probably still won’t cover every situation. And everyone still hates it!
6. Handling Ambiguity - Problem Identification: Be proactive in identifying and solving vague or undefined problems. Whenever there’s a feeling of “someone should do something here,” there’s a reasonable chance that the someone is you. Staff engineers often take on ambiguous, messy, difficult problems and do just enough work on them to make them manageable by someone else. - Adaptability: Stay flexible and adapt as priorities shift or challenges emerge. Be prepared to ignore your scope when there’s a crisis: there is no such thing as “not my job” during an outage, for example.
7. Managing Yourself - Avoid Overcommitment: Prioritize effectively and delegate when necessary to prevent burnout. Everything you commit to has an opportunity cost. Some of us allow low-priority other-people work to preempt even the most high-priority things we were planning to do. Pay attention to how people you admire say no. You won’t succeed unless you can defend your time. - The first rule of prioritization: No snacking (https://www.intercom.com/blog/first-r...) - Continuous Learning: Stay curious and continually develop both technical and soft skills. Learn also from people less senior than you! - Understand your work in context: know your customers, talk with peers outside your group, understand your success metrics, and be clear on what’s actually important. - You are responsible for choosing work that aligns with your life and career needs as well as advancing your company’s goals. - Five metrics for evaluating your job health: https://cate.blog/2021/11/29/5-signs-... 1. Whether you’re learning 2. Whether you’re investing in transferable skills or navigating dysfunction 3. How you feel about recruiting other people to your team 4. How confident you feel 5. How stressed you feel
8. Defining Success - Team Empowerment: Your success is reflected in the success of your team—enable them to shine. - Legacy: Leave behind systems, processes, and knowledge that outlast your tenure.
9. Navigating Challenges - Conflict Resolution: Approach disagreements constructively, seeking win-win solutions. - Handling Failure: Learn from mistakes, and encourage a culture of experimentation and resilience.
10. Pivot quickly! - Scaling Your Influence: As organizations grow, staff engineers must scale their impact by fostering autonomy and decentralizing decision-making. - Adapt to New Phases: Roles and expectations will evolve as the organization matures or pivots. When goals change => possibly your focus should change too!
You are responsible for your career and choices. There are a lot of options about what to optimize for. Know what’s important to you. Be deliberate. You’ll increase your access to opportunities with skills, visibility, relationships, and experiences. Everything is learnable if it’s worth the time investment. Check in with yourself occasionally and make sure your role is still giving you what you need. Look at what’s good as well as what’s not working. There are excellent reasons to spend a long time with one employer. There are excellent reasons to move around too. Either way, you have several options for paths onward. Software has a massive influence on the lives and livelihoods of just about everyone on earth. Take the responsibility seriously.
Good non technical book, for those interested in advancing their careers without becoming managers.
Here are my reading notes:
* how good is your job for you? ** q: stress vs health ** q: you would not even think about recruiting friends to your company vs you are enthusiastic about that ** q: are you only learning how to solve the current company's mess vs building transferrable skills ** q: are you stagnating vs growing? ** q: is your confidence in your skills being eroded vs growing
* standards for compliance: ** SOCKS ** GDPR ** HIPAA
* how does a project affect your: ** energy ** quality of life ** credibility ** social capital ** skills
* "overtone window" - in politics, it's a concept describing what kinds of topics are socially acceptable to talk about in public
* "nimawashi" - before asking people to vote on an issue, convince them all privately to do so, and what to vote on
* thedecider.app - site for helping to make decisions based on criteria such as ** the decision being urgent or not ** the impact being big or not ** consequences being clear or not ** etc.
* types of org cultures (westrum organizational typologies) ** pathological: everyone's in it for personal power. Messengers get shot. Failure leads to scapegoating ** bureaucratic: it's all about rules. Messegers get ignored. Plan ahead, follow rules! Failure leads to justice ** generative: high trust, cooperative. Messengers get trained. Failure leads to inquiry
* Maps: ** locator map: where you are in the company ** topographical map: learning the terrain...where is it easier to go through? (and people to avoid) ** treasure map: where to end up
* 4 types of staff engineers: ** team leads (in charge of technical direction but also people management for a single team) ** architects (influencing the technical direction for multiple teams) ** solvers (they jump into really hard problems) ** right-hands (they add managerial bandwidth)
* levels.fyi - website comparing engineering and mgmt (salary?) levels across different organizations
The Staff Engineer's Path is a good book for anyone looking to advance their career in tech. It is well-written, easy to follow, and packed with valuable insights and advice.
“The Senior level is your anchor: the levels below are for people to grow their autonomy; the levels above increase impact and responsibility.”
Alot of people enter software development because they don’t want their primary job task to consist of interacting with people. However, career progressions often define management as the next step after being a senior developer. To those who don’t want to be with people full-time, this hierarchy can make a dead end. In recent years, the pathway of a staff engineer has opened up. Staff engineers are in charge of the technical direction of their team and pushing hard projects foward, but they do not have direct reports. In such a system, managers deal with people issues and do not have to be technical masters themselves. In this book, Tanya Reilly explains in clear words what this position is about to encourage companies to adopt the pathway and individuals to contribute uniquely as individual contributors.
Many times, technical books, even on non-technical topics, aren’t written in conversational tone. Thus, readers can be turned off by a writer’s style instead of ingesting their content. Fortunately, this book is not one of those and is pleasant to read cover to cover. Among other topics, Tanya describes what a staff engineer does, talks about possible political pitfalls, and imagines what career development looks like. The reader leaves the book with a 360-degree picture of what a role as a staff engineer might look like.
Personally, I’m not interested in the staff engineering path. I’m most interested in leading others down that pipeline. This book helped me see how to guide my colleagues towards a fulfilling career that doesn’t involve having direct reports. It certainly met that aim quite well.
Those involved in the later stages of careers developing software should read this book, regardless of their role. It’s the best snapshot of this career trajectory that I’ve read so far. It applies to both future staff developers, who might take the path, as well as managers, who might guide others down it. It can apply to other engineering and technical pathways although it has an admittedly strong bias towards software development. Reilly simply shines a bright beacon on this emerging career direction that can benefit individuals along with businesses significantly in years to come.
The book is full of gems and wisdom. Doesn't matter what is your experience level I believe you would benefit a lot by reading it. I've started recommending this book to the juniors around me and they seem to enjoy it a lot.
The unfortunate part is that it's not a book to be read from cover to cover just once. And I kinda blame it on the structure. I often felt lost and had to use the table of content to remind myself what am I reading and how I got here. The book have bunch of cute illustrations, which are frankly not that useful. One of the cases when it felt like having interactive mind map & and more interlinks would be beneficial. The topics covered are begging for the option to jump around and being able to easily zoom-in and out.
Be warned that this one would require couple of re-readings and I would recommend dead tree version instead of e-book,
A very pragmatic and career growth-oriented book, has good metaphors, lacks specific guidance and instead offers more general self-help concepts.
In the beginning it focuses a bit too much on corp politics and explaining how to find the correct asses to kiss. It’s the best for building a right mindset for a technical leadership role.
Don’t read if you’re looking for any technical skills related information because there’s none. The author however tells that right from the beginning.
Some chapters are really good, others feel like fillers that explain trivial concepts. Overall I liked the book but I feel that it could’ve been a series of much shorter blog posts.
A well rounded set of advices and scenarios aimed at helping you leverage influence without authority. Relevant, in my opinion, for different levels of seniority so don't wait for Staff badge to get to it, it's a good North Star to keep in mind. How to weight conflicting priorities, get a tech sponsor / buy-in from higher-ups, mentor your team, advance your knowledge and manage change. Also how the scope of your impact is expanding and how not to get overwhelmed. Great read. Ah, and an important note on why titles matter – if you think they don't, check your privilege.
If you have read other books around this topic, especially the wonderful "Staff Engineer: Leadership beyond the management track by Will Larson", then you won't get any wiser. It covers all the standard topics about mentorship, cross-functional collaboration, and long-term career development, which make it a useful book indeed. While it provides valuable advice, some may find that the book’s concepts are more suited to those already familiar with large-scale engineering practices, rather than those looking for detailed technical instruction. Overall, it’s a thoughtful guide for career growth.
The Staff Engineer’s Path” ir lieliska grāmata ne tikai IT profesionāļiem , kas vēlas augt par “līderiem” ( ne formāliem vadītājiem ar padotajiem). Tanya Reilly praktiski un saprotami apraksta, kā pāriet no “labākais kodētājs” domāšanas uz ietekmīgu tehnisko līderību. Grāmata skar stratēģisko domāšanu, lēmumu pieņemšanu, sadarbību un biznesa izpratni – būtiskas prasmes, kas palīdz nest vērtību organizācijai.
Nav tikai teorija – pilna ar reāliem piemēriem no industrijas un praktiskiem ieteikumiem.
Very interesting book with a lot of good practical examples. The book covers all aspects of Staff+ (IC) engineering. In addition, it has a lot of excellent references to other articles, blogs, and books. The book doesn't have to be read from beginning to end. You can read chapters in any order. I recommend reading this book if you are new to the Staff+ path. Even though this book targets Staff+ engineers, there is a lot of wisdom for any level of developers.
It’s an awesome book that all engineers should read, even if you’re not close to be promoted (or even of you don’t plan) to staff engineer, it has lots of tips for a senior developer, lots of tips of how should you tackle problems/projects/tasks. If you manage staff engineers its also a book for you! As you are helping the engineer grow in their career, it gives lots of perspectives of what a staff engineer does and where this role will be more beneficial.