Debugging Your Teams

When an engineering team underperforms, it's common to blame the individuals on that team. But 80% of the time, the problem does not lie with the team. How do you find the root cause?

This post is the result of a few discussions and co-writing sessions with my friend John Cutler, author of The Beautiful Mess.

---

Many engineers in my company are literally doing nothing. They honestly just don’t seem to do anything, they should all just be let go.

This is what a friend of mine told me recently. He works at a leading tech company.

It’s not the first time I hear this kind of statements. Blaming the people on the team is easy. More often than not though, I have found that the problem does not lie with the individuals on the team and is instead a systems problem.

To make a parallel with coding: when code throws an error, you get a stack trace. This helps you debug the issue. The last line of the stack trace is where the error was actually raised. But most of the time, the root cause of the issue is not on the line that raises the exception. Debugging your code involves moving up the stack trace and finding the root cause of the error. This is something that experienced engineers do naturally. Novices tend to get stuck on the last line of the stack trace. 

Debugging teams is similar. Anyone can get better at debugging their teams and organizations. It requires moving past the first conclusion that you want to jump to. Below are some real-life examples that I have observed. For each of them, I describe what a rapid conclusion could be, and alternate explanations you may find once you start “going up the stack trace”.

Observed: Team delivers code, but what they build has no impact

“Jumped to” conclusions: 

• Unable to think big, lack of ambition.

• Doesn’t understand our users and our business. 

• Doesn’t care about the success of our company.

Alternate explanations:

• Feels stuck in “their lane”, no agency.

• Don’t want to throw other teams under the bus.

• I’m here to “peace-keep”.

• “I’ve been told I’m just here to code, my EM and PM decide the tickets we work on”.

Observed: Team has not delivered anything for 6 months

“Jumped to” conclusions: 

• Not the right people.

• Phoning in work.

• “Rest and vest” mentality.

Alternate explanations:

• Code is legacy, was written by one hero and no tests, afraid to change. 

• Internal stakeholders and/or processes are blocking releases.

• Team members haven’t been properly onboarded and trained.

Observed: Team delivers buggy products

“Jumped to” conclusions: 

• Incompetent.

• Doesn’t care about the quality of their work.

Alternate explanations:

• Doesn’t know what quality is and why it’s important.

• “I’m prioritizing releasing fast and iterating, I thought that’s what we wanted”.

• Too many competing priorities, no time to polish work!

• “I don’t know this product and what it should do, how can I know that this is a bug?”

Observed: Team keeps facing the same issues over and over (e.g. planning inaccuracy, long dependency chains between tickets, etc.)

“Jumped to” conclusions: 

• Incompetent.

• No growth mindset.

• Unable to learn.

Alternate explanations:

• Don’t know how to fix the root cause.

• Another team is the source of the root cause.

Understanding that there are alternate explanations is a good first step. It helps you understand your own biases. But how do you find out if there is an alternate explanation, and if so what it is? 

One way to think about it is to frame it with the 5 learnings gaps:

• Knowledge Gaps - A lack of information

• Skill Gaps - A lack of practice

• Motivation Gaps - A lack of motivation / incentive / reasons

• Environment Gaps - A lack of a supportive environment

• Communication Gaps - A lack of clear communication

For example, in the case of a team delivering buggy products, the root cause could be a motivation gap (“don’t care”), a skills gap (“I don’t know how to find bugs before customers do”), a knowledge gap (“I don’t know this product”), or an environment gap (“I wasn’t given the time to fix those quality issues”). When a team does not deliver impact, it could be a communication gap (“I wasn’t sure what I really was supposed to work on so I picked at random”), an environment gap (“to have an impact, I would have to go fix this other service, and I’m not allowed to”), or a knowledge gap (“nobody on my team really is able to tell what customers and how to provide them with value”). 

To be clear, I’m not saying everything is always a “systems problem”. Individual responsibility is a real thing and sometimes, individuals on a team simply lack the skills or the intrinsic motivation to be effective at what the company requires of them. And in those cases, facing the reality and taking action within your team is the right thing to do. But based on my experience, this is a small percentage of cases and 80% or more of the cases relate more to things that can be fixed outside of the team by fixing environment, communication, knowledge, or motivation gaps. 

This is exciting because it means that you may be able to help the team in more ways than you originally thought. How exactly to solve the problem can take many shapes depending on the root cause, the culture of the company, and on your role/position in the organization. That shouldn’t stop you from identifying the problem. As the saying goes, “A problem well stated is half solved”.