How to Debug Your Team: A Guide for Software Engineers
As software engineers, we spend a lot of time debugging code, finding and fixing errors, and optimizing performance. But what about debugging our teams? How do we ensure that our team is working well together, delivering quality products, and having fun along the way?
In this article, I will share some insights and tips from a book that I recently read, called Debugging Teams: Better Productivity through Collaboration by Brian W. Fitzpatrick and Ben Collins-Sussman. The book is a collection of essays on the human side of software engineering, covering topics such as communication, leadership, culture, design, marketing, and more.
The main premise of the book is that software development is a team sport, and that the success of a project depends largely on the social skills and interactions of the engineers involved. The authors argue that most software engineers are not trained or equipped to deal with the social challenges of working in a team, and that they need to learn and practice some essential skills to collaborate effectively.
The book is full of practical advice, anecdotes, and examples from the authors’ own experiences at Google and other companies. It is also written in a humorous and engaging style, with references to pop culture, history, and science. The book is not a technical manual, but a series of lessons and reflections on how to be a better engineer and a better teammate.
Here are some of the key takeaways from the book:
HRT:
The authors introduce the concept of HRT (humility, respect, and trust) as the foundation of healthy interaction and collaboration. They claim that most social conflicts can be traced back to a lack of HRT, and that these principles should guide all aspects of teamwork. Humility means being open to criticism, willing to learn, and patient with others. Respect means treating others as equals, valuing their opinions and contributions, and avoiding personal attacks. Trust means believing in others’ abilities, intentions, and motivations, and giving them the benefit of the doubt.
Communication:
The authors emphasize the importance of communication as the glue that holds a team together. They suggest various channels and methods of communication, such as mailing lists, design docs, chat rooms, code comments, etc. They also advise to use synchronous communication (like meetings and phone calls) sparingly and only with the necessary people, as it interrupts the workday and imposes a high cost. Asynchronous communication (like email, issue trackers, and document comments) should be used more often and with a broader audience, as it allows the recipients to deal with it at their convenience.
Documentation:
The authors consider documentation as the most important form of communication, as it makes all information available to as many people as possible. Documentation should cover the primary communication mechanisms that people use in the process of writing software with a team, such as mission statements, design docs, mailing lists, online chat, issue trackers, code comments, etc. Documentation should be clear, concise, accurate, and up-to-date, and should reflect the current state and vision of the project.
Leadership:
The authors distinguish between two types of leadership roles in software engineering: TL (tech lead) and TLM (tech lead manager). A TL is responsible for the technical direction and quality of the project, while a TLM is responsible for the people management and career development of the engineers. Both roles require different skills and mindsets, and the authors provide some tips and best practices for each. They also warn against some common leadership antipatterns, such as hiring pushovers, ignoring low performers, compromising the hiring bar, and treating the team like children. They suggest some positive leadership patterns, such as losing the ego, being a zen master, being a catalyst, being honest, and tracking happiness.
Culture:
The authors define culture as a set of shared experiences, values, and goals that shape a team’s identity and productivity. They explain how culture is created, maintained, and defended by team members, and how it can attract or repel different types of engineers. They emphasize the need for a culture that is based on HRT, focused on shipping great software, and open to influence. They also discuss how to deal with cultural clashes, such as when working with other teams, other companies, or other countries.
Design:
The authors discuss how to make a product easy to use, fast, friendly, and accessible for a wide range of users. They also advise to hide complexity, avoid too many options, and choose a specific audience for the product. They also explain how to involve users in the design process, by soliciting feedback, conducting usability tests, and iterating on prototypes.
Marketing:
The authors explain how marketing affects the public perception of a product and why it matters for attracting and retaining users. They also suggest some ways to cooperate with marketing without compromising the engineering culture or the product quality. They also advise to market the product internally, by creating demos, presentations, and newsletters, and to market oneself externally, by writing blogs, giving talks, and attending conferences.
Organizational Manipulation:
The authors discuss how to navigate good and bad companies to get things done effectively, using the term organizational manipulation. They contrast the traits of a good manager who serves the team and encourages risk-taking, with a bad manager who hoards information, fears failure, and takes credit for others’ work. They also warn about the office politician who uses relationships and deception to advance his own agenda, and the bad organization that lacks focus, vision, direction, or engineering culture. They offer several strategies for influencing the organization, such as asking for forgiveness rather than permission, creating grassroots support for ideas, managing upward, seeking powerful friends, and getting promoted to a position of safety. They conclude by advising that if all else fails, the best option is to get out of a bad company and find a better one.
I hope you enjoyed this summary and found it useful. If you are interested in reading the book, you can find it on Amazon or Google Books. I highly recommend it to anyone who wants to improve their teamwork skills and have more fun and satisfaction in their software engineering career.
Debugging Teams: Better Productivity through Collaboration by Brian W. Fitzpatrick | Goodreads
If you have any comments, questions, or feedback, please feel free to share them below. I would love to hear your thoughts and opinions on the book and the topics it covers.
Thank you for reading and happy debugging! 😊
