I recently read over Debugging Teams at the suggestion of one of my mentors, and wanted a place to dump my thoughts on the book. This is that place. The content here is fairly personal, with most of the things revolving around me, but hopefully they may serve some use to others as well. So, without further ado let’s dive into the content of the book. Part 2 will go over team culture, and part 3 will focus on engineering vs operations.
HRT
The book primarily centers itself around the concept of HRT (no, not that HRT), or Humility, Respect, and Trust:
Humility You are not the center of the universe. You’re neither omniscient nor infallible. You’re open to self-improvement.
Respect You genuinely care about others you work with. You treat them as human beings, and appreciate their abilities and accomplishments.
Trust You believe others are competent and will do the right thing, and you’re OK with letting them drive when appropriate.
This really hones in the idea that this book is focused on the human aspect of Software Engineering and it provides a really nice summary for those who don’t want to read. There’s a lot more to be learned from the book, but if you were short of time you could just focus yourself on improving these three things and the rest would eventually follow, although likely by trial and error.
Looking at how these three themes apply to me, I’d say that I am probably doing a fairly good job at showing humility and respect, but there’s a lot of improvement to be made in the trust department, which I’ll get into later. There were also a few key points centered around the HRT theme that felt very applicable to me, such as:
If you truly respect someone, you’ll be motivated to choose tactful, helpful phrasing—a skill acquired with much practice.
I often find myself (unintentionally) being rude or “short” with some of my colleagues, and later having to apologize after the fact. I want to respect my peers, but in some cases I fail to show it. This has motivated me to work on being a bit more thoughtful with my words and actions when talking with my peers, especially when I’m stressed or in a bad mood.
[…] you need to learn to accept criticism as well. This means not just being humble about your skills, but trusting that the other person has your best interests (and those of your project!) at heart and doesn’t actually think you’re an idiot.
I often find it hard to accept criticism of my work, and it has a pretty dramatic effect on my mood and motivation. My work cycle, in many cases, has been:
- Hide away in a cave and work on a design doc, project, or program for hours or days.
- Finish the work and send it for feedback.
- Receive a ton of helpful criticism and feedback from my peers.
- Take the feedback as an insult of my skills/knowledge/ego, get frustrated and upset, and lose all motivation to work on the project.
There’s two obvious problems I see with my current workflow. The quote focuses on step four, where I’m assuming that the person criticizing my work doesn’t mean well and is criticizing me, rather than assuming they are trying to help and criticizing the project. This behavior isn’t easy to fix, but my best bet is to try and remind myself that this is the case whenever I receive feedback.
The other glaring problem is step one, where I’m trying to do all the work in marathon format. I get a cool idea and then go hide away to design and/or implement it all at once. A better approach would be to treat projects as fast, iterative loops. Do some small/medium amount of work and send it for feedback early on, and keep doing this until the project is either finished or gets shot down. This way if I have a “bad” or ill formed idea it will get corrected or turned down quickly, when I haven’t put as much effort in.
As an example, I had to do this just now for this blog post! I started to try and critique the whole book in one go, and after a month of not making progress I realized I should just submit what I had but in smaller, more iterative posts. This gives me a chance to hear critique (from you, the reader) and to iterate on my writing style, rather than trying to make my first (and so far, only) post perfect.
Even better, think about going for a “collective” ego instead; rather than worrying about whether you’re personally awesome, try to build a sense of team accomplishment and group pride.
Finally, I think this idea of a “collective ego” is really powerful. I’m often focused on making myself feel awesome, when I should be focusing on making the team feel awesome.
Thank you for reading! I hope to have part two written in a few weeks, focusing on team culture.