What do you think?
Rate this book
Debugging Teams: Better Productivity through Collaboration
In the course of their 20+-year engineering careers, authors Brian Fitzpatrick and Ben Collins-Sussman have picked up a treasure trove of wisdom and anecdotes about how successful teams work together. Their conclusion? Even among people who have spent decades learning the technical side of their jobs, most haven’t really focused on the human component. Learning to collaborate is just as important to success. If you invest in the "soft skills" of your job, you can have a much greater impact for the same amount of effort. The authors share their insights on how to lead a team effectively, navigate an organization, and build a healthy relationship with the users of your software. This is valuable information from two respected software engineers whose popular series of talks―including "Working with Poisonous People"―has attracted hundreds of thousands of followers.
187 pages, Paperback
First published October 25, 2015
182 people are currently reading
1,885 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 73 reviews
July 30, 2017
I can highly recommend this book to individual contributors and those early in their leadership journey. It provides a good discussion of what makes a healthy team and how to work well in one. It talks about good leadership and company cultures. It even talks about why marketing (caring about first impressions), customer service (listening to your customers), and company politics (coordinating large groups of people with multiple goals) aren't always as bad as they're made out to be.
That said, if you've been a leader (whether formally or not) for more than a couple years, this book is likely going to be boring. The people for who that's not the case are the ones who probably really need to read it.
That said, if you've been a leader (whether formally or not) for more than a couple years, this book is likely going to be boring. The people for who that's not the case are the ones who probably really need to read it.
January 19, 2022
� “Leader� Is the New “Manager�
� Traditional managers worry about how to get things done, while leaders worry about what things get done�(and trust their team to figure out how to do it).
Another big reason for not becoming a manager is often unspoken but rooted in the famous “Peter Principle,� which states that, “In a hierarchy every employee tends to rise to his level of incompetence.� Most people have had a manager who was incapable of doing her job or was just really bad at managing people,7 and we know some people who have only worked for bad managers. If you’ve only been exposed to crappy managers for your entire career, why would you ever want to be a manager?
the human aspect is the hardest part of writing software.
While the leader is hoping and the low performer isn’t getting better (or leaving), high performers on the team waste valuable time pulling the low performer along and team morale leaks away into the ether. You can be sure that the team knows they’re there even if you’re ignoring them � the rest of the team is acutely aware of who the low performers are, because they have to carry them.
� Lose the Ego
� People have enormous respect for leaders who apologize when they screw up, and contrary to popular belief it doesn’t make you vulnerable.
� Be a Zen Master
� Be a Catalyst
� In many cases, knowing the right person is more valuable than knowing the right answer.
� Failure Is an Option
� Track Happiness
� One of the most valuable tools in tracking your team’s happiness is, at the end of each one-on-one meeting, to ask the team member, “What do you need?� This simple question is a great way to wrap up and make sure each team member has what he needs to be productive and happy, although you may need to carefully probe a bit to get details.
� Delegate, but get your hands dirty. When moving from an individual contributor role to a leadership role, achieving a balance is one of the hardest things to do: initially, you’re inclined to do all of the work yourself, and after being in a leadership role for a long time, it’s easy to get into the habit of doing none of the work yourself.
� People Are Like Plants
� Intrinsic Versus Extrinsic Motivation
� Seek to replace yourself.
� Know when to make waves.
� Rarely will these problems work themselves out, and the longer you wait to address them, the more they’ll adversely affect the rest of the team and the more they’ll keep you up at night thinking about them.
� Shield your team from chaos.
� Give your team air cover.
� Let your team know when they’re doing well.
� We prefer the “phenomenon� nomenclature because, even though this may make you feel like a fraud who will be discovered at any time, the imposter phenomenon often drives you to work much harder and achieve goals that you might never have achieved otherwise.
� Whatever sort of leadership you’re involved in, the same “fake it till you make it� technique tends to work very well.
� Traditional managers worry about how to get things done, while leaders worry about what things get done�(and trust their team to figure out how to do it).
Another big reason for not becoming a manager is often unspoken but rooted in the famous “Peter Principle,� which states that, “In a hierarchy every employee tends to rise to his level of incompetence.� Most people have had a manager who was incapable of doing her job or was just really bad at managing people,7 and we know some people who have only worked for bad managers. If you’ve only been exposed to crappy managers for your entire career, why would you ever want to be a manager?
the human aspect is the hardest part of writing software.
While the leader is hoping and the low performer isn’t getting better (or leaving), high performers on the team waste valuable time pulling the low performer along and team morale leaks away into the ether. You can be sure that the team knows they’re there even if you’re ignoring them � the rest of the team is acutely aware of who the low performers are, because they have to carry them.
� Lose the Ego
� People have enormous respect for leaders who apologize when they screw up, and contrary to popular belief it doesn’t make you vulnerable.
� Be a Zen Master
� Be a Catalyst
� In many cases, knowing the right person is more valuable than knowing the right answer.
� Failure Is an Option
� Track Happiness
� One of the most valuable tools in tracking your team’s happiness is, at the end of each one-on-one meeting, to ask the team member, “What do you need?� This simple question is a great way to wrap up and make sure each team member has what he needs to be productive and happy, although you may need to carefully probe a bit to get details.
� Delegate, but get your hands dirty. When moving from an individual contributor role to a leadership role, achieving a balance is one of the hardest things to do: initially, you’re inclined to do all of the work yourself, and after being in a leadership role for a long time, it’s easy to get into the habit of doing none of the work yourself.
� People Are Like Plants
� Intrinsic Versus Extrinsic Motivation
� Seek to replace yourself.
� Know when to make waves.
� Rarely will these problems work themselves out, and the longer you wait to address them, the more they’ll adversely affect the rest of the team and the more they’ll keep you up at night thinking about them.
� Shield your team from chaos.
� Give your team air cover.
� Let your team know when they’re doing well.
� We prefer the “phenomenon� nomenclature because, even though this may make you feel like a fraud who will be discovered at any time, the imposter phenomenon often drives you to work much harder and achieve goals that you might never have achieved otherwise.
� Whatever sort of leadership you’re involved in, the same “fake it till you make it� technique tends to work very well.
February 9, 2024
I started reading this books as an engineering manager, searching for ways to make my teams more effective, and found a book that I consider should be read by anyone who is part of a team, needless to say, this is specially relevant for software engineering teams, since it's based on the experiences of a software product organization. It's a very light read and it has tons of other interesting book recommendations at the end, I will definitely read some of them.
November 12, 2020
I can’t really disagree with anything in here but similar to what other reviewers said, it’s mostly stuff you’ve probably heard about before (and I say that as a person who’s not a manager). It’s also fairly light on practical advice. That being said I still appreciated it as it helped to cement some of the things I already sort of knew and I think it’ll be a great reference to come back to later on if I ever do become a manager or lead of something.
September 5, 2022
Не понимаю почему так долго читал эту книгу. Она рассказывает про работу в команде для инженеров с сильным техническим видением. Хорошо подходит для перехода из разработчика в техлида, но периодически ловил устаревшие (?) подходы: mailing list, как пример.
February 16, 2025
I did not learn much from the book, but what I would recommend, even for my future self, is to read through the remarks I did, when I will want to change a team - run through them. It might recall some of the important points on what I should look at before calling a shot 🙏🏼
January 26, 2022
Definitely a great book on its own but since this is a follow-up on Team Geek, it's mostly reiteration and repeating Team Geek's ideas.
November 12, 2018
The purpose of this book is to help people improve their collaborate with others. The authors introduce it as “social challenges of creative collaboration.�
Cool tech history note. The authors worked on the Subversion open source project; and later at Google on Google Code.
The book reads as a series of essays; it’s easy to pick up a chapter or section without going end to end.
The “core traits to remember� are abbreviated “HRT� and stand for humility, respect, and trust.
Hat tip: Andrés Bastidas. Read on Kindle in October 2018.
Cool tech history note. The authors worked on the Subversion open source project; and later at Google on Google Code.
The book reads as a series of essays; it’s easy to pick up a chapter or section without going end to end.
The “core traits to remember� are abbreviated “HRT� and stand for humility, respect, and trust.
Hat tip: Andrés Bastidas. Read on Kindle in October 2018.
February 20, 2017
The second edition of Team Geek was renamed to Debugging Teams to reflect a partial rewrite to make the book more accessible to people who aren't on software engineering teams. But, the focus is still very much on debugging a software engineering team. That said, there is a lot of value for non-engineers, but expect to find yourself flipping through several less relevant sections very fast.
If you're on a software engineering team, I highly recommend this great book with very relevant, useful advice. And unlike many books in this area, it's not overly focused on managers. Their three main principles they advocate for building great teams are humility, respect, and trust. My favorite chapter was Building an Awesome Team Culture.
The last chapter felt like basic guidance on strategies for building a great software product, and seemed very out of place in the book. I think they felt the book was too short, so they tacked on another essay. While I agree with what they wrote in that chapter, it's unlikely an experienced engineer or product manager is going to learn much from it.
If you're on a software engineering team, I highly recommend this great book with very relevant, useful advice. And unlike many books in this area, it's not overly focused on managers. Their three main principles they advocate for building great teams are humility, respect, and trust. My favorite chapter was Building an Awesome Team Culture.
The last chapter felt like basic guidance on strategies for building a great software product, and seemed very out of place in the book. I think they felt the book was too short, so they tacked on another essay. While I agree with what they wrote in that chapter, it's unlikely an experienced engineer or product manager is going to learn much from it.
March 3, 2018
First things first: If you read or ever heard about the famous "", you can consider "Debugging Teams" a perfect companion for the issues pertaining to modern information technology teams and their dynamics.
The book's strong point stems from the fact that the authors have experience both in managing and be managed, as well as dealing with complex open source community and the dynamics of their members. They don't sugarcoat difficult messages when it comes to team organization, communication, and management, and yet they manage to provide the reader with good examples of humane and safe environments where people can thrive.
I think I'll go back again and again to sections and chapters about management antipatterns, "Dealing with Poisonous People", and "The Art of Organizational Manipulation".
It would be fair to say that any organization / manager who claims "our people are our greatest asset" should have digested and internalized (and gone beyond) the guidance provided in this book. If not, they you'd better recommend them this book as required reading!
The book's strong point stems from the fact that the authors have experience both in managing and be managed, as well as dealing with complex open source community and the dynamics of their members. They don't sugarcoat difficult messages when it comes to team organization, communication, and management, and yet they manage to provide the reader with good examples of humane and safe environments where people can thrive.
I think I'll go back again and again to sections and chapters about management antipatterns, "Dealing with Poisonous People", and "The Art of Organizational Manipulation".
It would be fair to say that any organization / manager who claims "our people are our greatest asset" should have digested and internalized (and gone beyond) the guidance provided in this book. If not, they you'd better recommend them this book as required reading!
April 8, 2019
This is a great book to read as a team. It's full of easy to understand and practical advice. This edition of the book is intended for a larger audience than just programmers but all the good examples are from programming teams.
I liked the theme of HRT that's throughout the book -- Humility, Respect, and Trust. Some of the ideas I found worth writing down.
* Fail early, fail fast, fail often -- don't work in isolation or be afraid to share work in progress
* Ask questions to guide other to their solutions.
* A leader is always on stage, always being watched. Remember the gears analogy. Leaders have gears with more impact from small changes.
* Focus on booting bad behavior from the team, not bad people.
* Change behavior, not people.
* When dealing with emotional responses or feedback, focus only on facts and details.
* Treat people as adults, not children. Don't be too harsh on rule breaking. Learn why the rules are getting in the way.
* Over-communicate. Frequent updates.
* Tech debt: Defensive work, contrasted to user-facing work that is Offensive. Defense isn't sexy, but it needs done. But rarely can you only play defense.
* Look for opportunities to help others out and gain political capital. Think of it as an investment portfolio -- some will pay off but not all.
* Trust (in your product, team) is your most sacred resource
I liked the theme of HRT that's throughout the book -- Humility, Respect, and Trust. Some of the ideas I found worth writing down.
* Fail early, fail fast, fail often -- don't work in isolation or be afraid to share work in progress
* Ask questions to guide other to their solutions.
* A leader is always on stage, always being watched. Remember the gears analogy. Leaders have gears with more impact from small changes.
* Focus on booting bad behavior from the team, not bad people.
* Change behavior, not people.
* When dealing with emotional responses or feedback, focus only on facts and details.
* Treat people as adults, not children. Don't be too harsh on rule breaking. Learn why the rules are getting in the way.
* Over-communicate. Frequent updates.
* Tech debt: Defensive work, contrasted to user-facing work that is Offensive. Defense isn't sexy, but it needs done. But rarely can you only play defense.
* Look for opportunities to help others out and gain political capital. Think of it as an investment portfolio -- some will pay off but not all.
* Trust (in your product, team) is your most sacred resource
September 21, 2021
Couldn't get past the first chapter.
A very poor example out of the gate of Michael Jordan's 90s Bulls. Emphasizing that it wasn't him but the team that won all those championships - true it was the team, but would the team have won without MJ? I don't think so. Could MJ go to a semi-competent team with Scotty Pippen tier player on his side and win? For sure.
A few pages later the authors drive the point of the most important aspects in successful teams - respect/trust/humility which directly contradict MJ's leadership style as evidenced . How wouldn't the authors know of MJ's "toxic" way of handling his team mates living in Chicago in the 90s is beyond me.
The next few pages describe an instance of the perfect team member class - always humble (no ego), being respectful and having trust in the team. I think the authors are missing the core idea of what the activity of computer programming is - a craft intelligent people take pride in.
Instead of offering platitudes, I'd offer the only two actual characteristics of a good team member which are not tied to his performance (humility vs ego): honesty and self-responsibility. That's it.
A very poor example out of the gate of Michael Jordan's 90s Bulls. Emphasizing that it wasn't him but the team that won all those championships - true it was the team, but would the team have won without MJ? I don't think so. Could MJ go to a semi-competent team with Scotty Pippen tier player on his side and win? For sure.
A few pages later the authors drive the point of the most important aspects in successful teams - respect/trust/humility which directly contradict MJ's leadership style as evidenced . How wouldn't the authors know of MJ's "toxic" way of handling his team mates living in Chicago in the 90s is beyond me.
The next few pages describe an instance of the perfect team member class - always humble (no ego), being respectful and having trust in the team. I think the authors are missing the core idea of what the activity of computer programming is - a craft intelligent people take pride in.
Instead of offering platitudes, I'd offer the only two actual characteristics of a good team member which are not tied to his performance (humility vs ego): honesty and self-responsibility. That's it.
April 20, 2019
This book really changed me and had me see the value in incorporating a mission statement, regardless of what team you’re on, or level in your company. The principles in the book speak to Humility, Respect, and Trust, and how each of those is integral for building the best team. It’s a very quick read, but I highlighted a lot of quotes from it. Probably the best part speaks to how IT folks get thrust into management, it’s usually not a path we want to go down. How do you traverse that? Get this book.
June 1, 2021
This book about managing and troubleshooting teams. MUST HAVE for any leader (both technical or management). This book is great. It helped me to understand how teams are working, how to deal with people in a better way, how to build a better culture in the organization. It has a lot of good examples from authors on how to deal with different situations in the work. I love the examples and I can say I've been there and faced it.
I'm pretty sure this will be a handbook for me for the next few years or more.
I'm pretty sure this will be a handbook for me for the next few years or more.
January 16, 2022
I read this book after listening to a podcast. It's been described as “How to Win Friends and Influence People for programmers�.
Debugging Teams is supposed to be a new, less software-developer-specific version of Team Geek. I haven't read Team Geek, but Debugging Teams still had pretty much that was focused on software-related things. I thought this was a good thing. Sure it could generalize.
The main thesis of the book is their “HRT�: humility, respect, and trust. These are all good things to have.
Debugging Teams is supposed to be a new, less software-developer-specific version of Team Geek. I haven't read Team Geek, but Debugging Teams still had pretty much that was focused on software-related things. I thought this was a good thing. Sure it could generalize.
The main thesis of the book is their “HRT�: humility, respect, and trust. These are all good things to have.
January 14, 2023
'Debugging Teams' is an absolutely fine book if you are just uncovering that there is a human side to the technology journey. If you have gone beyond that, say you are a senior engineer or a manager, this book will be a pleasant read, but it most likely won't teach you anything. I thought it was well written, simple, clear, to the point, and brought a good value system into the discussion, supported by solid examples. But I am well aware of how to observe someone's work style, the bus factor, the benefits of collaboration and how to overcome toxicity, that for me it didn't do all that much.
April 25, 2024
If you'd like to build an engineering culture that made Google legendary, this is the book to read.
It's also one of the best and the most concise management books I've read. It describes an approach to
management - nay, leadership - that is rooted equally in being highly ethical, and highly realistic. For an engineering manager (or anyone leading a group of knowledge workers), I'd consider this absolutely essential reading. However, I believe any community would benefit if its leaders championed the fundamental principles of Humility, Respect and Trust described in this book.
It's also one of the best and the most concise management books I've read. It describes an approach to
management - nay, leadership - that is rooted equally in being highly ethical, and highly realistic. For an engineering manager (or anyone leading a group of knowledge workers), I'd consider this absolutely essential reading. However, I believe any community would benefit if its leaders championed the fundamental principles of Humility, Respect and Trust described in this book.
October 25, 2019
People are the main component of a project. That said, it's extremely important to know how to build a solid team. The authors cover a lot of scenarios of collaboration with people inside your team, how to lead them, how to shield them against poisonous people, how to collaborate with people from another areas of the company and with the users of your product.
Highly recommended (whether you are an individual contributor, a team leader or intend to become one).
Highly recommended (whether you are an individual contributor, a team leader or intend to become one).
June 18, 2021
Primary theme of the book is HRT: Humility, Respect, and Trust.
This book content is based on the authors' experience and anecdotes, along with summaries from a few other management books. There are no studies cited and no quantification. The book provides best practices with a focus on what to do rather than why or how. No novel insights.
The software category covered is shrink wrapped (see Joel's Five Worlds).
This book content is based on the authors' experience and anecdotes, along with summaries from a few other management books. There are no studies cited and no quantification. The book provides best practices with a focus on what to do rather than why or how. No novel insights.
The software category covered is shrink wrapped (see Joel's Five Worlds).
January 21, 2024
I'm afraid I cannot be objective in this review because I'm so in love with this book! I'm lucky to have read it in my first years in the IT industry but it also gave me great insights while finishing my PhD research. It has an open and humane attitude that I thought it didn't exist in high tech professionals, at least at the level of the authors. This book is also available for free in its webpage! Read and enjoy!
September 24, 2017
Loved this book! I wish I had read this much earlier, probably when I started my career. This book is not just meant for people managers, but also for individual contributors who have to work together in a team to build great products. The experience of the authors enriches this book with an abundance of relatable examples.
January 14, 2018
Pretty okay book. Lots of advice is just common sense, but there are parts here and there that may be useful in the future, especially if you never encountered situations described in the book.
Definitely a good read for people who never read anything like this before. Maybe if all people followed the advice here, it'd be a better place. :)
Definitely a good read for people who never read anything like this before. Maybe if all people followed the advice here, it'd be a better place. :)
March 14, 2020
Unlike ordinary development books, each page was a useful book, full of different best practices. Each page contains suggestions that you can adapt to daily work life. In addition, they embody the points that are tried to be explained with examples from their own lives. In short, I found the book very useful, I recommend it.
December 5, 2020
From the outside, it looks managerial. But really it's a guide on how to organize your project communities, build trust with peers and users, and keep a healthy team culture.
Some stuff is straight forward of you've worked at companies like Facebook or Google. But it's always nice to have explicit call outs.
I'd recommend it to anyone who is a main contributor to a project, or leads a team.
Some stuff is straight forward of you've worked at companies like Facebook or Google. But it's always nice to have explicit call outs.
I'd recommend it to anyone who is a main contributor to a project, or leads a team.
September 1, 2021
Great book although a bit bland. The book has great overall principle, however I was hoping for more detailed solutions (it has after all "debugging" in the name)
I was also a bit disappointed they dialed down on technical stuff to reach a bigger audience.
Nevertheless, a good book if you're expectations are different
I was also a bit disappointed they dialed down on technical stuff to reach a bigger audience.
Nevertheless, a good book if you're expectations are different
August 2, 2024
A really good summary of best practices for a healthy team culture and managing a team. Given it’s heavily rooted in day-to-day practical advice and tips popularized in other books, it’s a great jumping off point for those new to the space but only a recap for those who have been living it out already.
November 17, 2017
How I wish this book existed when I started leading teams several years ago! IMHO, this is one of the very best books on team leading and general corporate life. A must read for anyone working with teams!
March 18, 2018
The authors talk about some problems and bad behaviors that can affect teams. I definitely saw myself in some of the "don't do this" examples. Whoops. If I had read this book ten years ago (or even one year ago) my life today would be very different. Live and learn, right?
January 3, 2019
Quick, entertaining, and surprisingly dense book detailing what components make up successful software engineering - or really any! - teams. I didn't exactly learn anything new reading this book but find incredible value in this book being citable.
Worth the read.
Worth the read.
July 12, 2019
Very good book for matured software engineers who are now stepping into more management-like or leadership-like roles. (Especially the first two parts. The last part focused on the users was IMHO a bit off-topic.)
Displaying 1 - 30 of 73 reviews
Can't find what you're looking for?
Get help and learn more about the design.