Management Myth #8: I Can Still Do Significant Technical Work
Published on AgileConnection (https://www.agileconnection.com)

[article]

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

Summary:

The temptation can be incredibly strong for managers—especially new ones—to step in when a technical problem arises. But, that isn’t a very good show of faith in one’s team members. Johanna Rothman writes that as a manager, you have to delegate a problem and leave it delegated.

“You know, if you want something done, you just have to do it yourself,” Clive muttered as he strode down to his office.

Susan looked up from her desk and sighed. She stood, followed Clive down the hall, and knocked on his office door.

“What? I’m a little busy right now!” he replied and turned back to his computer. Then, he turned to Susan and said, “Explain this part of the framework to me.”

“No.”

He looked at her, raised an eyebrow, and said, “No? I’m your boss.”

“That’s right. You’re the manager, but you’re not asking me as my manager. You’re asking me someone who’s going to go in and do some damage, as opposed to some help. I’m the technical lead. If you have a problem with what’s going on technically, you’re supposed to talk to me. You’re supposed to talk to the team. Why are you not talking to me? Why are you not talking to the team? Why are you messing with the code?”

“Did you see what Todd did?”

“Yes.”

“You can stand there calmly and say yes? You’re not freaking out?”

“No, I’m not freaking out, because the team and I solved this problem this morning, which is more than you have done. Whose problem is this to solve?”

“Uh, yours and the team’s.”

“Thank you. And did you ask me or the team how we were solving the problem?”

“Uh, no.”

“So, you missed that Todd and Cindy are pairing on the fix for this problem, that we already have a patch on the production server, and that Dick and Samara are pairing on performance test development so we catch this in the future. You missed all of that, right? Oh, and that we will be reviewing the code and the tests, right? You missed that?”

“Uh, yes.”

“You were going to put on your Superman coder cape and do it all yourself?”

“Uh, yes.”

“Look, Clive, you were the Superman developer back in the day, but your day was more than five years ago. Even if it had been a year ago, you wouldn’t know what we’ve done with the code. You cannot possibly be current with what we are doing. We have thirty people in the code, what with the automated tests and the updated frameworks. You don’t know what we have anymore. You are no longer current. You cannot do significant technical work anymore without doing real damage. Stop thinking you can.”

“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.”

But, My Manager Expects Me to Do Both
Ah, now we come to a real problem. There are some second-level managers out there who think it’s reasonable for a first-level manager to manage one or two people and fully participate as a technical contributor. That second-level manager might be correct, but that first-level manager is barely a manager.

There is a tipping point. As soon as that first-level manager manages a third person, the manager’s balance must swing from technical work to management. And, if everything has been OK up until then, then it will take a crisis for the first-level manager to realize that his or her management responsibilities have to come first.

Explain to your manager that you have management responsibilities that are more important than technical work. You trust your team. You can facilitate their problem solving. You might even be able to contribute to their problem-solving process. But, to get down and dirty in the code, tests, requirements, or project management only hurts your team.

Management Might Not Be For You
If you can’t keep your hands off of the technical work, then you might decide that being in management is not what you want. In that case, discuss what you do want with your manager. You are allowed to change your mind!

But, while you are a manager, keep your hands off the technical work. You are not part of the technical team. Don’t think or act like you are.

Read more of Johanna's management myth columns here:

About the author