I believe that the best engineering managers are often great debuggers. Why would this be? What is it about these two tasks that produces such an overlapping skill set?
A great debugger is relentless in his pursuit of the “why” for a bug. This is simple when we’re looking for errors in application logic, but we all know that bugs can go many layers deep, particularly in complex systems that involve many separate parts operating over time-delayed networks. A sign of a poor debugger is a person who, when he adds a log statement to a piece of concurrent code to attempt to find an error and sees that the error can’t be reproduced, assumes that he’s fixed the problem. It’s a lazy habit, but a common one. Sometimes there are problems that seem impossible to determine, and many people don’t have the patience to dig through layers of code (theirs and others’), logfiles, system settings, and whatever else is needed to get to the bottom of something that happened only once. I can’t blame them. Obsessive debugging of one-off issues is not always a great use of your time, but it does show a mind that won’t be satisfied with the unknown, especially when that unknown might cause you to be paged at two o’clock in the morning.
What does this have to do with management? Managing teams is a series of complex black boxes interacting with other complex black boxes. These black boxes have inputs and outputs that can be observed, but when the outputs aren’t as expected, figuring out why requires trying to open them up and see what’s going on inside. And, just as sometimes you don’t have the source code, or the source code is in a language you don’t understand, or the logfiles aren’t readable, the black boxes of teams can resist yielding their inner workings.
Let’s work through an example. You have a team that feels slow. You’ve heard complaints from their business partners and product manager that they’re slow, and you agree that the team just seems to lack the same energy as your other teams. How do you figure this out?