What do you think?
Rate this book
The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change
Managing people is difficult wherever you work. But in the tech industry, where management is also a technical discipline, the learning curve can be brutal-especially when there are few tools, texts, and frameworks to help you. In this practical guide, author Camille Fournier (tech lead turned CTO) takes you through each stage in the journey from engineer to technical manager.
From mentoring interns to working with senior staff, you'll get actionable advice for approaching various obstacles in your path. This book is ideal whether you're a new manager, a mentor, or a more experienced leader looking for fresh advice. Pick up this book and learn how to become a better manager and leader in your organization.
Begin by exploring what you expect from a manager Understand what it takes to be a good mentor, and a good tech lead Learn how to manage individual members while remaining focused on the entire team Understand how to manage yourself and avoid common pitfalls that challenge many leaders Manage multiple teams and learn how to manage managers Learn how to build and bootstrap a unifying culture in teams244 pages, Paperback
First published May 16, 2017
About the author
Camille Fournier
72 books162 followersFor the 19thC gynaecologist, see Camille Fournier.
Camille Fournier is the former chief technology officer of Rent The Runway and former vice president of technology at Goldman Sachs.
Camille Fournier is the former chief technology officer of Rent The Runway and former vice president of technology at Goldman Sachs.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 639 reviews
June 24, 2017
This book does a good job of walking you through the typical career path of a software engineer, from individual contributor all the way up to senior executive. It's a great read for all programmers and not just managers. In fact, if you're still early in your career, you'll find this book especially valuable, as it's a great outline of what to expect later in your career, and some of the things you can do to accelerate your growth.
A few of my favorite insights from the book:
* As you move from individual contributor (IC) to lead (i.e. either tech lead or manager), one of the biggest challenges is learning to balance your technical work vs the non-technical. For an IC, most of the work is technical; the higher up you go in your career, the more time you spend on communication, strategy, planning, management, and other non-technical issues. While you should rarely be 100% technical or non-technical, finding the right balance in between is hard, and it's a moving target that you'll have to watch closely throughout your career.
* The book presents a strong case for having regular one-on-ones. Very few of my own managers ever did that for me, and those that did didn't know how to run a one-on-one effectively, and I think my career suffered as a result. The ideas for one-on-ones in this book seem useful, especially on a) not using them as purely status meetings and b) on keeping a running document with notes of what you discussed in each meeting.
* Most developers are used to brainstorming, tossing out ideas, and challenging the ideas of others as a normal, healthy aspect of code reviews and design discussions. When you become a leader, people will begin interpreting the exact same feedback as marching orders, rather than one opinion amongst many. You may be used to thinking out loud and playing devil's advocate with your peers, but as a leader, if you're not careful, a few casual phrases can derail an entire project. Therefore, you need to make extra effort to make it clear when your feedback represents "must do" vs "just a couple more ideas to consider"; and sometimes, you just need to keep your mouth shut entirely.
* As a tech lead, you should ask what is the "true north" for your team? That is, what are the most important guiding principles the engineering team should be aiming for? 100% code coverage? Weekly, daily, or continuous deployment? No single points of failure? Five 9's reliability? Sub-second load times? You can't accomplish all of these at the same time; in fact, if everyone is moving towards different goals, you're not likely to succeed at any of these. Therefore, you need to get everyone pulling in the same direction by identifying your true north, making sure everyone on the team knows what it is, and using that to simplify decision making. Every time a developer is making a trade-off--should I go with X or Y?--pick the one that brings the team closer to the true north.
One interesting aspect to this book is that it does not try to offer too many answers. The author lays out what will happen, presents the challenges, and offers a few suggestions on how to meet them, but for the most part, leaves it up to you to think through everything and reflect on the best way forward. This can be a bit frustrating if you were hoping to walk away from the book with a list of tools and techniques that you can immediately apply to your work; the later chapters on senior leadership in particular contain less concrete, actionable advice than the earlier ones. However, the reality is that there are no easy, pre-baked solutions for most of these problems. The main value of the book is making you aware of those problems so that you aren't blind-sided by them and can recognize them in time to come up with your own solutions.
As always, I've saved a few of my favorite quotes from the book:
"One thing that early career engineers often don’t appreciate is how their current peers will turn into their future jobs."
"When you are persistently unhappy, say something. When you are stuck, ask for help. When you want a raise, ask for it. When you want a promotion, find out what you need to do to get it."
"Being a tech lead is an exercise in influencing without authority. As the tech lead I am leading a team, but we all report to the same engineering manager. So not only do I have to influence my peers, but I also have to influence up to my manager to ensure we are prioritizing the right work."
"Delegation is not the same thing as abdication. When you’re delegating responsibility, you’re still expected to be involved as much as is necessary to help the project succeed."
"One of the basic rules of management is the rule of no surprises, particularly negative ones."
"It’s a short step from managing a person or two to managing a whole team, but managing a team is more than just doing the job of managing the individuals. At this point, your job has changed. In fact, at every step beyond this level you will probably experience a totally different set of requirements and challenges. The hardest thing to prepare for as you advance in your career is the idea that you’re going to start doing totally different things. As much as you may want to believe that management is a natural progression of the skills you develop as a senior engineer, it’s really a whole new set of skills and challenges."
"Writing code is full of quick wins, especially for the experienced developer. You make tests pass, you see new features come to life, you get something to compile, you fix a problem. Management has fewer obvious quick wins, especially for new managers. It’s natural to feel some longing for simpler times, when it was just you and your computer and you didn’t have to deal with all these messy, complicated humans."
"Saying no to your boss rarely looks like a simple “no” when you’re a manager. Instead, it looks like the “yes, and” technique of improvisational comedy. “Yes, we can do that project, and all we will need to do is delay the start of this other project that is currently on the roadmap.” Responding with positivity while still articulating the boundaries of reality will get you into the major leagues of senior leadership. "
"Never underestimate how many times and how many ways something needs to be said before it sinks in. Communication in a large organization is hard. In my experience, most people need to hear something at least three times before it really sinks in."
"I like to describe technology strategy for product-focused companies as something that “enables the many potential futures of the business.”"
"There’s a saying in politics that “a good political idea is one that works well in half-baked form,” and the same goes for engineering processes. The processes should have value even when they are not followed perfectly, and that value should largely lie in the act of socializing change or risk to the team as a whole."
A few of my favorite insights from the book:
* As you move from individual contributor (IC) to lead (i.e. either tech lead or manager), one of the biggest challenges is learning to balance your technical work vs the non-technical. For an IC, most of the work is technical; the higher up you go in your career, the more time you spend on communication, strategy, planning, management, and other non-technical issues. While you should rarely be 100% technical or non-technical, finding the right balance in between is hard, and it's a moving target that you'll have to watch closely throughout your career.
* The book presents a strong case for having regular one-on-ones. Very few of my own managers ever did that for me, and those that did didn't know how to run a one-on-one effectively, and I think my career suffered as a result. The ideas for one-on-ones in this book seem useful, especially on a) not using them as purely status meetings and b) on keeping a running document with notes of what you discussed in each meeting.
* Most developers are used to brainstorming, tossing out ideas, and challenging the ideas of others as a normal, healthy aspect of code reviews and design discussions. When you become a leader, people will begin interpreting the exact same feedback as marching orders, rather than one opinion amongst many. You may be used to thinking out loud and playing devil's advocate with your peers, but as a leader, if you're not careful, a few casual phrases can derail an entire project. Therefore, you need to make extra effort to make it clear when your feedback represents "must do" vs "just a couple more ideas to consider"; and sometimes, you just need to keep your mouth shut entirely.
* As a tech lead, you should ask what is the "true north" for your team? That is, what are the most important guiding principles the engineering team should be aiming for? 100% code coverage? Weekly, daily, or continuous deployment? No single points of failure? Five 9's reliability? Sub-second load times? You can't accomplish all of these at the same time; in fact, if everyone is moving towards different goals, you're not likely to succeed at any of these. Therefore, you need to get everyone pulling in the same direction by identifying your true north, making sure everyone on the team knows what it is, and using that to simplify decision making. Every time a developer is making a trade-off--should I go with X or Y?--pick the one that brings the team closer to the true north.
One interesting aspect to this book is that it does not try to offer too many answers. The author lays out what will happen, presents the challenges, and offers a few suggestions on how to meet them, but for the most part, leaves it up to you to think through everything and reflect on the best way forward. This can be a bit frustrating if you were hoping to walk away from the book with a list of tools and techniques that you can immediately apply to your work; the later chapters on senior leadership in particular contain less concrete, actionable advice than the earlier ones. However, the reality is that there are no easy, pre-baked solutions for most of these problems. The main value of the book is making you aware of those problems so that you aren't blind-sided by them and can recognize them in time to come up with your own solutions.
As always, I've saved a few of my favorite quotes from the book:
"One thing that early career engineers often don’t appreciate is how their current peers will turn into their future jobs."
"When you are persistently unhappy, say something. When you are stuck, ask for help. When you want a raise, ask for it. When you want a promotion, find out what you need to do to get it."
"Being a tech lead is an exercise in influencing without authority. As the tech lead I am leading a team, but we all report to the same engineering manager. So not only do I have to influence my peers, but I also have to influence up to my manager to ensure we are prioritizing the right work."
"Delegation is not the same thing as abdication. When you’re delegating responsibility, you’re still expected to be involved as much as is necessary to help the project succeed."
"One of the basic rules of management is the rule of no surprises, particularly negative ones."
"It’s a short step from managing a person or two to managing a whole team, but managing a team is more than just doing the job of managing the individuals. At this point, your job has changed. In fact, at every step beyond this level you will probably experience a totally different set of requirements and challenges. The hardest thing to prepare for as you advance in your career is the idea that you’re going to start doing totally different things. As much as you may want to believe that management is a natural progression of the skills you develop as a senior engineer, it’s really a whole new set of skills and challenges."
"Writing code is full of quick wins, especially for the experienced developer. You make tests pass, you see new features come to life, you get something to compile, you fix a problem. Management has fewer obvious quick wins, especially for new managers. It’s natural to feel some longing for simpler times, when it was just you and your computer and you didn’t have to deal with all these messy, complicated humans."
"Saying no to your boss rarely looks like a simple “no” when you’re a manager. Instead, it looks like the “yes, and” technique of improvisational comedy. “Yes, we can do that project, and all we will need to do is delay the start of this other project that is currently on the roadmap.” Responding with positivity while still articulating the boundaries of reality will get you into the major leagues of senior leadership. "
"Never underestimate how many times and how many ways something needs to be said before it sinks in. Communication in a large organization is hard. In my experience, most people need to hear something at least three times before it really sinks in."
"I like to describe technology strategy for product-focused companies as something that “enables the many potential futures of the business.”"
"There’s a saying in politics that “a good political idea is one that works well in half-baked form,” and the same goes for engineering processes. The processes should have value even when they are not followed perfectly, and that value should largely lie in the act of socializing change or risk to the team as a whole."
August 29, 2019
A great book on navigating a career path from Individual Contributor to Manager. Doesn't go into depth on any topic, but provides a good overview. I'm adding it to the list of recommendations for new tech leads. The full list:
- The Pragmatic Programmer
- The Effective Engineer
- Peopleware
- The Manager's Path
- High Output Management
- The Five Dysfunctions of a Team
- The Elements of Style
- Crucial Conversations
- The Pragmatic Programmer
- The Effective Engineer
- Peopleware
- The Manager's Path
- High Output Management
- The Five Dysfunctions of a Team
- The Elements of Style
- Crucial Conversations
April 12, 2017
Having grown from being an engineer to manager to startup founder, this is probably the best book I’ve read on the topic of technical leadership and management, and one I wish I’d had available to me a decade ago! All those hard lessons I got from screwing up and learning from my mistakes could have been skipped if Camille’s book had existed then!
Though that dreaded word “manager” is in the title, it is not purely valuable to those who have a strong desire to engage in people management. Part of what I appreciate most about the structure is that the first chapter (which is available as a free PDF download from O’Reilly’s website) is valuable advice for individual contributors to build a better relationship with their managers.
From there, the book steps chapter-by-chapter through the increasing scopes of team ownership you can have: How to be a mentor. How to be a Tech Lead. How to manage a few people… a team… multiple teams… teams of managers of teams. Then finally “the big leagues” of VP/CTO land.
I think the book could be valuable to a wide array of folks:
Existing Engineering Managers — READ IT NOW! READ IT! YOU HAVE NO EXCUSES! Block off time on your calendar if need-be! It gives advice both strategic and tactical.
Engineers who think they might want to be an EM some day — This is the fastest way to see what the career path can look like, and get a sense for whether these are the types of problems you can see yourself being satisfied to think about some day.
Engineers who might want to start a start-up some day — Being a founder isn’t just about the technology. If you’re in any way successful, you’ll have to start to build a team and think about people problems. This will give you a framework for when you’re the boss!
Engineers who are in (or growing towards) Tech Lead roles — The first few chapters will help you understand the way your responsibilities have changed (from being responsible for your own code, to being responsible for the impact of multiple engineers) and give strategies for managing time and expectations. If you keep reading, you can also make educated decisions about if you might want to switch to engineering management in the future.
Every other engineer — Read that free first chapter so you can have better relations with your manager!
Though that dreaded word “manager” is in the title, it is not purely valuable to those who have a strong desire to engage in people management. Part of what I appreciate most about the structure is that the first chapter (which is available as a free PDF download from O’Reilly’s website) is valuable advice for individual contributors to build a better relationship with their managers.
From there, the book steps chapter-by-chapter through the increasing scopes of team ownership you can have: How to be a mentor. How to be a Tech Lead. How to manage a few people… a team… multiple teams… teams of managers of teams. Then finally “the big leagues” of VP/CTO land.
I think the book could be valuable to a wide array of folks:
Existing Engineering Managers — READ IT NOW! READ IT! YOU HAVE NO EXCUSES! Block off time on your calendar if need-be! It gives advice both strategic and tactical.
Engineers who think they might want to be an EM some day — This is the fastest way to see what the career path can look like, and get a sense for whether these are the types of problems you can see yourself being satisfied to think about some day.
Engineers who might want to start a start-up some day — Being a founder isn’t just about the technology. If you’re in any way successful, you’ll have to start to build a team and think about people problems. This will give you a framework for when you’re the boss!
Engineers who are in (or growing towards) Tech Lead roles — The first few chapters will help you understand the way your responsibilities have changed (from being responsible for your own code, to being responsible for the impact of multiple engineers) and give strategies for managing time and expectations. If you keep reading, you can also make educated decisions about if you might want to switch to engineering management in the future.
Every other engineer — Read that free first chapter so you can have better relations with your manager!
May 7, 2017
I'm somewhere between individual contributor and management in my career right now (mentoring and, at times, technical lead,) so this book was of interest to me.
I hate to say that this book was disappointing because I enjoy following the author on Twitter and have enjoyed lots of her clear, well-written blog posts about management and technical strategy, particularly ones like "how do individual contributors get stuck".
I think this book essentially tried to stretch those blog posts into an entire volume, which doesn't quite work. There is a lot of repetition of concepts, and even though the book is clearly organized according to the table of contents, it doesn't seem to follow any particular logical pattern when you're in the weeds. The ideas, while interesting, all seem to be common sense, without a firm path to implementation, and they don't have enough technical detail for me to be very interested (I realize this may be a personal preference, as I was particularly keen to know some of the details of the author's work with Zookeeper, etc, in which she was heavily involved.)
As someone who's written non-fiction before and also written about tech while trying to keep employer-specific details out of posts, I really appreciate this attempt, but I hate to say that it did not go nearly the way I was expecting it to, and I was left feeling a little flat.
I hate to say that this book was disappointing because I enjoy following the author on Twitter and have enjoyed lots of her clear, well-written blog posts about management and technical strategy, particularly ones like "how do individual contributors get stuck".
I think this book essentially tried to stretch those blog posts into an entire volume, which doesn't quite work. There is a lot of repetition of concepts, and even though the book is clearly organized according to the table of contents, it doesn't seem to follow any particular logical pattern when you're in the weeds. The ideas, while interesting, all seem to be common sense, without a firm path to implementation, and they don't have enough technical detail for me to be very interested (I realize this may be a personal preference, as I was particularly keen to know some of the details of the author's work with Zookeeper, etc, in which she was heavily involved.)
As someone who's written non-fiction before and also written about tech while trying to keep employer-specific details out of posts, I really appreciate this attempt, but I hate to say that it did not go nearly the way I was expecting it to, and I was left feeling a little flat.
May 22, 2017
Don't get discouraged by introductory tech lead chapters - these seem like written a bit "without inspiration". In fact, there are at least few better books for people who just start leading tech teams - e.g. Pat Kua's "Talking with tech leads". But Fournier's book gets significantly better once it reaches relatively less explored areas - managing technical managers, managing several teams, differentiating among various higher level technical management roles, becoming CTO.
Recommended read if you're seriously thinking about the "end-game" in software engineering industry.
Recommended read if you're seriously thinking about the "end-game" in software engineering industry.
April 7, 2018
The best book about management in software development I have ever read! A must read for managers and highly recommended even for individual contributors. It has helped me enormously!
March 2, 2019
I still don’t get what a CTO does
April 21, 2022
بعضی قواعد سرانگشتی که گفته بود را خیلی دوست داشتم. بعضی بخشهای کتاب هم بیخودی کش میداد. در کل ارزش خواندن داشت.
March 11, 2018
I recommend this book to anyone involved with software engineering management, from individual contributors - willing or not to a managing career move - to senior managers.
It gives a clear view and show countless real life situtations, from first level to CTO, with a perspective of who had experiencied all of it.
Whether or not you are looking for a management career, we as software engineers are going to live most (if not all) of the situtations described in each chapter, directly or indirectly.
From a practice perspective, this book can help you learn a lot, avoid mistakes, give you ideas to deal with several issues, handle better day-to-day situations, and the most important to me: see what happens at the other side.
I think that is one of the most important lessons for me in my current career position. Even if I would never work myself at any of those management roles, knowing what it is being in the other side will improve my relations and will help me be a better software engineer.
It gives a clear view and show countless real life situtations, from first level to CTO, with a perspective of who had experiencied all of it.
Whether or not you are looking for a management career, we as software engineers are going to live most (if not all) of the situtations described in each chapter, directly or indirectly.
From a practice perspective, this book can help you learn a lot, avoid mistakes, give you ideas to deal with several issues, handle better day-to-day situations, and the most important to me: see what happens at the other side.
I think that is one of the most important lessons for me in my current career position. Even if I would never work myself at any of those management roles, knowing what it is being in the other side will improve my relations and will help me be a better software engineer.
June 16, 2018
Extremely well written book that takes you through the career progression of a software engineer to managing a small team to VP Engineering and CTO. It talks about the roles and responsibilities of each stage of the technical as well as the techno-managerial career.
The book illustrates the various situations that you will face when you navigate your career through a product startup. Several situations and their solutions resonated with me as I have faced them myself. This is a book written by someone who has been through the hard grind of technical leadership. The advice is solid and very practical and actionable especially for tech startups.
This is a must read for every engineer as he progresses through his/her career. Highly recommended.
The book illustrates the various situations that you will face when you navigate your career through a product startup. Several situations and their solutions resonated with me as I have faced them myself. This is a book written by someone who has been through the hard grind of technical leadership. The advice is solid and very practical and actionable especially for tech startups.
This is a must read for every engineer as he progresses through his/her career. Highly recommended.
February 6, 2020
Книга про карьерный рост в разработке ПО и сопутствующие такому росту рекомендации. Есть полезные практики, советы и наблюдения. Очень хорошо зайдет начинающим менеджерам в IT.
March 25, 2020
I listened to the audiobook and thoroughly enjoyed the whole book.
This book didn't bring ground breaking / earth shattering new information to the table. But it highlighted all those little nuggets of areas you would have to deal with in various stages of your career. I kept on thinking "Exactly, I've dealt with that". She hits the nail on the head most of the time.
Other times she highlights important areas that you've forgotten/neglected and clearly states why it is important.
Reading some reviews/comments on this book, it seems your enjoyment of the book would vary, depending on the stage of your career you are at. I can see why though. If you are at the lower end of the leadership/management structure, or you are only thinking about heading in that direction at the moment, this book can make it sound quite daunting.
I'm not sure whether it is better to know upfront, or learn on the job.
But I found my self nodding my head on most of what she was saying.
It is one of those books that shouldn't only be read by managers. As there are lots of nuggets of information around how to be a better employee. How to work more effectively. How to pave your career.
I also don't believe this content only applies to software development. Yes it directly relates, but I see no reason why other departments (support, technical, etc) cannot benefit out of most of this knowledge.
She does go through quite the Role hierarchy though. Which mostly applies to very big companies. When you listen to what each role does though, you will find that a lot of the detail still applies to small companies. It would just be a single person/role handling a combination of the segregated titles. This does sometimes make you think that you might be doing too much, or have too many hats though.
The chapters are short and focused. It seems the author intended it in such a way, that you could read what applies to you, and skip others. Unfortunately this doesn't really apply to the audio version. Personally I do liked all chapters though. And it gives a great overview.
I would recommend this book to most people in my company, to get some perspective of what is expected of everyone, and how to be better at it. Like I said, most of it is either common knowledge, or things we've struggled with / experienced ourselves, and just need to be reminded about it.
This is a great addition to other books I've read (listened):
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
The Five Dysfunctions of a Team: A Leadership Fable
Turn the Ship Around!: A True Story of Turning Followers into Leaders
Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration
Drive: The Surprising Truth About What Motivates Us
Start with Why: How Great Leaders Inspire Everyone to Take Action
Rework
It Doesn't Have to Be Crazy at Work
This book didn't bring ground breaking / earth shattering new information to the table. But it highlighted all those little nuggets of areas you would have to deal with in various stages of your career. I kept on thinking "Exactly, I've dealt with that". She hits the nail on the head most of the time.
Other times she highlights important areas that you've forgotten/neglected and clearly states why it is important.
Reading some reviews/comments on this book, it seems your enjoyment of the book would vary, depending on the stage of your career you are at. I can see why though. If you are at the lower end of the leadership/management structure, or you are only thinking about heading in that direction at the moment, this book can make it sound quite daunting.
I'm not sure whether it is better to know upfront, or learn on the job.
But I found my self nodding my head on most of what she was saying.
It is one of those books that shouldn't only be read by managers. As there are lots of nuggets of information around how to be a better employee. How to work more effectively. How to pave your career.
I also don't believe this content only applies to software development. Yes it directly relates, but I see no reason why other departments (support, technical, etc) cannot benefit out of most of this knowledge.
She does go through quite the Role hierarchy though. Which mostly applies to very big companies. When you listen to what each role does though, you will find that a lot of the detail still applies to small companies. It would just be a single person/role handling a combination of the segregated titles. This does sometimes make you think that you might be doing too much, or have too many hats though.
The chapters are short and focused. It seems the author intended it in such a way, that you could read what applies to you, and skip others. Unfortunately this doesn't really apply to the audio version. Personally I do liked all chapters though. And it gives a great overview.
I would recommend this book to most people in my company, to get some perspective of what is expected of everyone, and how to be better at it. Like I said, most of it is either common knowledge, or things we've struggled with / experienced ourselves, and just need to be reminded about it.
This is a great addition to other books I've read (listened):
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
The Five Dysfunctions of a Team: A Leadership Fable
Turn the Ship Around!: A True Story of Turning Followers into Leaders
Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration
Drive: The Surprising Truth About What Motivates Us
Start with Why: How Great Leaders Inspire Everyone to Take Action
Rework
It Doesn't Have to Be Crazy at Work
August 27, 2017
Good book on the software engineering relevant parts of leadership. The author is well-read in management and leadership and seeks to supplement the existing works with a book more focused on the parts unique to software engineering. I think she does a good job pointing out the differences and similarities, but I wasn't blown away. I wish there wouldn't been more focus on managing projects, communicating with stakeholders, and prioritizing at the project-level. If you manage people and you're in software, I'd recommend reading it. It articulated some of the ideas that I've had some trouble distilling, which was quite helpful. The first couple of chapters don't do justice to the rest of the book, which I found much much more useful. I'd recommend skipping some of the first chapters. Read the first few and last few pages of those chapters to see for yourself whether you find it worth it to read the whole thing. When you get to managing 1 and multiple teams, that's when it gets more juicy.
March 9, 2021
Considero o principal guia da gestão moderna, porém é um livro que considero que todos devem ler principalmente pelos primeiros capítulos onde a autora apresenta diversas dicas e técnicas para ser um funcionário melhor. O capitulo sobre mentoria foi de fundamental utilidade para mim. Os capítulos mais focados na liderança senior me ajudaram a entender como funciona o dia a dia desse tipo de profissional e também a entender se é esse o rumo que espero para minha carreira.
June 22, 2019
Was it easy to read: Sort of. The language is not complicated at all. But each chapter is intended for a person in a certain position. So chapters that are still very far away in my career were quite difficult to get through. I think it is best to be read as author suggested – just the chapters that are currently of value for you.
What I liked about it: How practical and hands on the book is. It really gives context about culture and situations in other companies + explanations and advice how to deal with those. I am pretty sure I will get back to it every time I advance in my career.
What I disliked: That it is not designed to be read from cover to cover. Of course it wasn’t that bad - some chapters about higher managerial positions still had relevant content.
Ideas/ Quotes:
“Your relationship with your manager is like any other close interpersonal relationship. The only person you can change is yourself. You should absolutely provide feedback to your manager, but understand that she may not listen or change no matter how much you think she should.”
“The idea that the tech lead role should automatically be given to the most experienced engineer, the one who can handle the most complex features or who writes the best code, is a common misconception that even experienced managers fall for. Tech lead is not the job for the person who wants the freedom to focus deeply on the details of her own code. “
“One universal talent separates successful leaders from the pack, it’s communication skills.”
“Regular 1-1s are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time (Marc Hedlund)”
What I liked about it: How practical and hands on the book is. It really gives context about culture and situations in other companies + explanations and advice how to deal with those. I am pretty sure I will get back to it every time I advance in my career.
What I disliked: That it is not designed to be read from cover to cover. Of course it wasn’t that bad - some chapters about higher managerial positions still had relevant content.
Ideas/ Quotes:
“Your relationship with your manager is like any other close interpersonal relationship. The only person you can change is yourself. You should absolutely provide feedback to your manager, but understand that she may not listen or change no matter how much you think she should.”
“The idea that the tech lead role should automatically be given to the most experienced engineer, the one who can handle the most complex features or who writes the best code, is a common misconception that even experienced managers fall for. Tech lead is not the job for the person who wants the freedom to focus deeply on the details of her own code. “
“One universal talent separates successful leaders from the pack, it’s communication skills.”
“Regular 1-1s are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time (Marc Hedlund)”
December 4, 2019
Well structured, explaining the different levels of being a (tech) manager.
Downside: some repetitions. Not really new stuff, but a good read.
Downside: some repetitions. Not really new stuff, but a good read.
March 21, 2021
"The Manager's Path" follows a tech career from the very start through management to the very top. It gives an overview of different positions with their responsibilities, provides anecdotes from personal experience and tips how to handle various situations you might encounter.
I started reading this book 2 years ago when I took on the challenge to manage a team. At the time I felt a bit lost what my responsibilities were (it was not clearly defined) and this book helped me orient myself in my new role. It also gave me ideas how to navigate my new position. Recently, I decided to continue reading it. Even though the later part of the book covers positions that don't apply to me, it was extremely interesting to see what they encompass and what challenges people in these positions face. It gave me a new appreciation and understanding of what my managers have to do. I would recommend it even for technical people who are not interested in pursuing a career in management. I find it is important to understand the different roles in an organization, their challenges and how to communicate with each of them.
I started reading this book 2 years ago when I took on the challenge to manage a team. At the time I felt a bit lost what my responsibilities were (it was not clearly defined) and this book helped me orient myself in my new role. It also gave me ideas how to navigate my new position. Recently, I decided to continue reading it. Even though the later part of the book covers positions that don't apply to me, it was extremely interesting to see what they encompass and what challenges people in these positions face. It gave me a new appreciation and understanding of what my managers have to do. I would recommend it even for technical people who are not interested in pursuing a career in management. I find it is important to understand the different roles in an organization, their challenges and how to communicate with each of them.
July 9, 2017
Camille's book on tech management is spot on, starts pointing out the basics of management, how tech management differs from management in other fields and the many levels you can find yourself (tech lead, manager, engineering manager, VP and CTO) and stuff you should worry about at all these levels.
She covers day to day work, stuff you will most likely face, problems along the road, ways to perform self evaluation, collect feedback, find blind spots (yeah, you'll figure out people don't tell you everything) and many many more. The book is full of examples and commentary from other people in the field so there's a bunch of nice stories around as well.
The book is organized in tiers so you can focus on where you are in your career right now instead of reading the whole book but i'd recommend just doing it all, will give you a perspective on what your managers are doing and what you should do to help them as well.
Recommended!
She covers day to day work, stuff you will most likely face, problems along the road, ways to perform self evaluation, collect feedback, find blind spots (yeah, you'll figure out people don't tell you everything) and many many more. The book is full of examples and commentary from other people in the field so there's a bunch of nice stories around as well.
The book is organized in tiers so you can focus on where you are in your career right now instead of reading the whole book but i'd recommend just doing it all, will give you a perspective on what your managers are doing and what you should do to help them as well.
Recommended!
February 22, 2018
This was my first "career" book and it was better than I expected. This is great even for non-managers if you happen to land a copy of this because of the chapters devoted to being a great IC and Tech Lead. It has concise advice supplemented by stories about different stages of an engineer's career for those on the manager track all the way up to the top.
Sidenote: I didn't finish as I stopped where it was relevant to my career, but still am considering this finished (for now).
Sidenote: I didn't finish as I stopped where it was relevant to my career, but still am considering this finished (for now).
May 11, 2019
this is a really incredible book. it's one of the first ones I picked up as I was transitioning from a tech lead to an engineering manager and it was helpful not only for navigating my own role but for understanding the needs and communication patterns of everyone I work with from new engineers to directors and above.
this is not only a book for managers imo, it's a book for anyone who wants to better understand how to work with folks at all levels of an engineering organization
this is not only a book for managers imo, it's a book for anyone who wants to better understand how to work with folks at all levels of an engineering organization
June 22, 2019
Contains a very good description about the different roles and responsibilities on the typical engineering career later (from engineer to CTO). The best I've read so far actually. Also useful (albeit brief) advice and tips for getting started in each particular role.
Sometimes felt a bit to deep in US/Silicon Valley culture and their understanding of leadership to me.
Sometimes felt a bit to deep in US/Silicon Valley culture and their understanding of leadership to me.
October 18, 2020
Not particularly mind blowing but it contains a few nuggets of information on how to navigate this career path, making it a must read for Individual Contributors going the Management route.
I particularly enjoyed the Team Lead definitions and role responsibilities as well as how nicely the author manages to clearly differentiate each role from the previous one.
I particularly enjoyed the Team Lead definitions and role responsibilities as well as how nicely the author manages to clearly differentiate each role from the previous one.
August 27, 2020
Where was this book in 2005 :) great practical content, actual for every level in technical management career. My friend recommended me this book when I started to raise the questions about scope of CTO and head of engineering responsibility. I found some answers indeed
June 14, 2021
A practical guide that delivers good advice in a no-nonsense approach, highly recommended.
This book takes you through what might be a possible path for a technical employee up the ranks, from managing only yourself, to managing the entire company. At every step of the ladder the different responsibilities and challenges are described, how to overcome them, succeed, and move on to "the next level".
At the beginning of the book I felt like it was very insightful and extremely practical with its advice. The more I progressed, however, the situations the author described seemed more remote and less relevant for my current position, which makes sense. I believe that they were valuable reading nonetheless.
I think I'll return to this book later in my career and hopefully be able to better utilize some of the more "advanced" advice given within. Even if you do choose to skip some chapters I recommend reading "Bootstrapping Culture", which contains knowledge relevant for developers and engineers at any level.
I've listened to it in audio-book format and I'm seriously considering buying a physical copy. Then I'd be able to highlight passages, have it on my shelf, or be able to loan it to colleagues (and managers!). I think that is the highest praise I can give a book.
This book takes you through what might be a possible path for a technical employee up the ranks, from managing only yourself, to managing the entire company. At every step of the ladder the different responsibilities and challenges are described, how to overcome them, succeed, and move on to "the next level".
At the beginning of the book I felt like it was very insightful and extremely practical with its advice. The more I progressed, however, the situations the author described seemed more remote and less relevant for my current position, which makes sense. I believe that they were valuable reading nonetheless.
I think I'll return to this book later in my career and hopefully be able to better utilize some of the more "advanced" advice given within. Even if you do choose to skip some chapters I recommend reading "Bootstrapping Culture", which contains knowledge relevant for developers and engineers at any level.
I've listened to it in audio-book format and I'm seriously considering buying a physical copy. Then I'd be able to highlight passages, have it on my shelf, or be able to loan it to colleagues (and managers!). I think that is the highest praise I can give a book.
February 16, 2020
I don't have much to say about this book as it's mostly a compilation of ideas I've either heard or used during my career.
This book can be definitely replaced with a few blog posts. The examples that it gives are rather nonillustrative, I've never heard about most of the companies that the author uses as role models.
Regardless of what I just said the book was nice and easy to read and I really appreciate author's efforts to write it.
I can recommend it as a book you can start and finish during one weekend.
My score 3/5
This book can be definitely replaced with a few blog posts. The examples that it gives are rather nonillustrative, I've never heard about most of the companies that the author uses as role models.
Regardless of what I just said the book was nice and easy to read and I really appreciate author's efforts to write it.
I can recommend it as a book you can start and finish during one weekend.
My score 3/5
June 21, 2020
How can you tell if you really enjoyed a book after finishing it?
I guess ordering a physical copy when you already had the ebook is a sign.
It took me quite a while to finish this book, as I would stop every time that I didn't relate with the role described. Then, I would pick it up when I felt that I had matured in my role and I could better understand the concepts.
I believe it's a very insightful book, and that everyone can gain by reading it. Even if you don't want to be a manager, it can teach you how to be a tech leader, something that every engineer will need after a certain point in their career.
I guess ordering a physical copy when you already had the ebook is a sign.
It took me quite a while to finish this book, as I would stop every time that I didn't relate with the role described. Then, I would pick it up when I felt that I had matured in my role and I could better understand the concepts.
I believe it's a very insightful book, and that everyone can gain by reading it. Even if you don't want to be a manager, it can teach you how to be a tech leader, something that every engineer will need after a certain point in their career.
September 3, 2022
It seems to me that the book was a little bit a commercial book. Because most of the content of the book was very general. If you want to gain a bit deeper knowledge about topics of the book you need to read different books as well. Bu if you are interested in technical management, and you have not read any in-depth content about it, this book would be a good choice for you to start.
Overally the book worth reading.
Overally the book worth reading.
Read
February 8, 2020This is the sort of book I wished I had read several years ago, before I started managing people and teams. It has many practical suggestions and its technical focus makes it very relatable.
I did miss a focus on diversity though. Though the author is careful to switch pronouns, there was barely any mention of the importance and challenges of managing cultural diverse teams and I worry a few of her comments on company culture could be misconstrued as saying these aren't a good idea.
I did miss a focus on diversity though. Though the author is careful to switch pronouns, there was barely any mention of the importance and challenges of managing cultural diverse teams and I worry a few of her comments on company culture could be misconstrued as saying these aren't a good idea.
Read
May 29, 2022The first of what I suspect will be many books I read about management. This was recommended to me by Gary and it’s a good procedural overview of what the responsibilities are of a manager at different levels within a tech organisation, and generally covers what needs doing and when. If nothing else this book has reassured me that I’m not forgetting some key element of the job.
March 12, 2022
This is the IT management book. I recommend it to all the people working in IT, from junior engineers wondering how to use a manager to their benefit and what lies ahead up to executives thinking about culture and structure. As many people have noticed, it starts a bit slow with first chapters stating the obvious (at least to those who’ve been in the industry for some time), but with time it presents more and more useful advice. What’s great about it is that you don’t have to be an executive to find the later chapters useful and applicable to your day to day work. Strongly recommended.
Displaying 1 - 30 of 639 reviews