Debug Your Team the Way You Debug Your Code

Listen to the error messages in your team!

As engineers, we often look into the logs of our programs and find error messages there. We expect our program to work. An error message is an unexpected problem. When we read an error message, we think: “Oh, something is broken, I need to fix that,” and then we do. To us, that feels natural.

Error messages exist outside our software too, but for some reason we often handle them very differently. When something happens in our workday, in the fabric of our team, that we wouldn’t expect on a good day, that is an error message — for example:

• an argument between you and a colleague,
• an unclear requirement that leaves us falling short of an expectation,
• a deadline we have to push back.

Instead of feeling the same urge to fix this error, one of the following two things often happens:

(1) We blame ourselves and turn it into a personal failure.

(2) We overrate the error, see a bigger illness behind it, and demand fundamental change.

In my view, both reactions are the wrong approach, and the measures behind them are also far more exhausting than a healthy response: whoever takes errors personally attacks themselves as an individual and makes their own daily life much harder than it needs to be. Whoever demands and carries out big changes places an equally big bet that this change will fix the core problem — a high risk with an uncertain outcome.

When our software throws an error message, we neither blame the software nor rewrite it on the spot (except for the Rust folks among you — jk).

Why do we often handle it differently within the team? Here too, we can isolate the error, look for the cause, and then fix only that. Nothing more. Do it once, and we have one less problem and nobody has to beat themselves up over it. Make it a habit, and step by step we bring about the big change we sometimes wish for. It just doesn’t feel that big, that exhausting, or that risky — because it is none of those things.