Is Debugging Teams Similar to Debugging Code?

Engineers are bad at debugging

🙀  

Perhaps that is a bit harsh.

Then again, I have worked with many engineers over the years and only met a few who are good at tracking problems down quickly.

Good debugging seems to come from a mixture of technique and experience.

When I debug code, I consider the solution space and try to find the most efficient ways to narrow it down.  

The bisection method.  

Come up with ideas that narrow down the possibilities. 

Constrain the degrees of freedom until you figure out what needs to change to achieve the desired result.

👉 Typical mistakes:

• Randomly Trying Things: The engineer changes things almost randomly in the hope that the issue will be fixed. Alarmingly, the mechanism of action is not understood, which is scary.
  Solution: Stop randomly changing things and come up with a theory that explains the problem.

• Cannot Possibly Be The Problem: No working theory could explain why the proposed cause is the root issue behind the problem that we are having. 
  Spending time working on it is a waste, because, with some quick thinking, we can rule that cause out.
  Solution: Develop a reasonable theory before proceeding with the investigation.

• Fixation:  Overly focusing on one thing, either clearly not the problem, or unlikely to be the problem.
  Solution:  Take a step back and challenge your assumptions.  What if this is not the problem, what else could it be?  

Now, what if debugging teams were similar to debugging code?

⁉️ Do engineering managers or leaders have the same problems when diagnosing their teams?

• Randomly Trying Things: Have you heard about SAFe or Kubernetes? Let’s try them out and see if they solve our quality problem.
• Cannot Possibly Be The Problem: Quality is low and incidents are high?  Let’s ensure we are not having items overflow the sprint.
• Fixation:  Focusing on pet peeves,  fun projects, or a comment from someone higher in the chain of command, with no causal connection to the actual issues the team is facing?

Don’t be that leader. 🙂

Perhaps ask these questions:

• Why are you focusing on the current problem/solution/bottleneck?
• What if you are wrong, where else could your problem/solution/bottleneck be?
• Do you have a working theory that connects this problem with a solution and explains how that will alleviate your bottleneck?