Managing people is difficult wherever you work, but the tech industry as a whole is pretty bad at it. Tech companies in general lack the experience, tools, texts, and frameworks to do it well. And the handful of books that share tips and tricks of engineering management don t explain how to supervise employees in the face of growth and change.
In this book, author Camille Fournier takes you through the stages of technical management, from mentoring interns to working with the senior staff. You ll get actionable advice for approaching various obstacles in your path, 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.
* Discover how to manage small teams and large/multi-level teams * Understand how to build and bootstrap a unifying culture in teams * Deal with people problems and learn how to mentor other managers and new leaders * Learn how to manage yourself: avoid common pitfalls that challenge many leaders * Obtain several practices that you can incorporate and practice along the way
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 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
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!
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.
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.
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.
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.
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.
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.
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.
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)”
"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.
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.
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).
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
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.
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
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.
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.
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.
This 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.
The 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.
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.