Management Myth #8: I Can Still Do Significant Technical Work

“But, what can I do to help when I see a problem?”

“Ask me what we need. Ask the team what we need. Make sure we are fed and watered,” Susan said with a grin. “Mostly, just ask. We’ll tell you. Give us moral support, but don’t mess with the code.”

Susan stood up to leave and said, “Oh, I’ve revoked your checkin privileges. You can read anything you want. You can’t check anything in. And, I’ve changed the root password. You can’t mess with anything technical. You’re a manager. Be one.”

Delegate Problems and Don’t Take Them Back
When we, as managers, see a technical problem, it’s tempting to want to wade in and help—either by fixing the problem ourselves or by telling people how to fix it. But that destroys the trust that we have built with our teams. Once we delegate the problems to the team, we need to leave the problem delegated.

If you try to take technical problems back, you are not doing your team any favors. They will eventually stop trying to solve problems, anticipating your lack of delegation. Why should they solve problems if you are going to grab the problems back once things get sticky?

Do You Still Understand the Details?
Now, be honest with yourself. Do you still understand all the details of your team’s technical work?

As soon as we become managers, our technical problem-solving skills start to erode—at least, they should, if we are becoming great managers. Why? Because we spend more time with people on the team and with other managers and less time with the code, the tests, the requirements, or whatever part of the organization you came from.

That doesn’t mean we shouldn’t know whom to ask about a problem, but we shouldn’t know about all the technical details.

Once, when I was a director of development, one of my developers came rushing into my office with a highly technical problem that he thought I could solve. I listened and understood where the issues were and who could help him. I couldn’t pinpoint where the problems were in the code, but I knew the problems lay somewhere in the performance area, where we had made changes just the previous week. Because I had kept current with the current discussions, I could steer him to the correct people. But, I couldn’t solve the problem.

If you don’t understand the details anymore, is it your job to wade into the details? No, it’s not. You can facilitate problem solving, but you can’t solve the problems yourself.

Know What You Can Do
The best thing we can do as managers is to create an environment in which people can do their best work. Sometimes, that means facilitating a problem-solving meeting. Sometimes, it means making sure they have enough servers or debuggers or whiteboards. Sometimes, it means keeping other people, such as your manager, out of the way.

It might even mean that you help read the code or, maybe, as a very long shot, that you get to write or test some code. But, providing technical assistance is unlikely to be helpful once you are manager.

Why? Let’s review what managers do. Managers exist to organize with purpose. They organize people or help people organize themselves into project teams. They organize problem-solving or project-solving teams. They organize ideas. Sometimes, they organize coffee, bagels, or doughnuts. But, if you are still organizing code or tests once you’ve been a manager for more than a week, you are not doing either the management job or the technical job well. You haven’t delegated your old work and explicitly and implicitly told the team, “I trust you to do the technical work.”