How to Select a Fine Technical Manager

• Most software developers want to be a team manager someday.
• Most software developers are utterly unqualified for such a position.
• Non-technical people are even worse managers than technical ones.
• So… how do you solve the problem of selecting a fine technical manager?

Solution: Give the job to a technical person who never asked for it!

First, a little background story…
I was catapulted into my first management job 12 years ago. My employer wanted me (and a friend of mine) to build a new business out of an interesting idea I had. This idea (programming templates in Microsoft Word) turned out to be a successful venture and we were suddenly faced with managing 20 developers and designers. And I didn't like it. I preferred working on my own ideas, figuring out the way ahead for the company, solving problems, and not bothering with the mundane details of our customer projects. My friend and I quickly created a layer of project managers so I could be shielded from all the boring stuff.

However, when one of the project managers was on a vacation, I had to descend from my ivory tower to take over his job. Annoyed, and with a deep frustrated sigh, I invited the team members for a short meeting. We quickly went through the stuff they were doing, I pointed out a few risks in their priorities, gave some pointers as to what the solution might look like, and told them to buzz off so I could fly back up to my magic orbs and vials. A couple of days later I descended again to check on their progress, and we went through the same procedure.

I never wanted to be a full-time manager, so I turned myself into a one-minute manager.

Some time later, after the project manager had returned, I was quite surprised to hear from a team member that they had preferred my management style over the way the project manager was managing the team. It turned out that he was always micromanaging everything, while I just communicated a direction and let the team figure out the details that I couldn't be bothered with. The project manager had a politician's hat. He loved talking, meeting, documenting and socializing. I didn't, I liked problem solving. I had a wizard's hat.

Most software developers want to be a team manager someday.
When asked about their career plans, most software developers tell me that they want to become a manager someday. I believe them to be primarily driven by status and money (neither one a bad thing), and not by the kind of activities that come with the job. Now, let me tell you honestly: management activies are as much fun as being the mayor of a town with six people, three pigs and a chicken. It's no big thing. It just something that needs to be done.

Instructing computers is much more fun than instructing people.

(It's because computers usually do what you want them to, and people often don't.) Those rare technical people that really prefer talking, meeting, documenting and socializing over solving problems and building solutions may also, quite coincidentally, be the ones that have the tendency to micromanage others. And this renders them unsuitable for the job, as far as I'm concerned.

Most software developers are utterly unqualified for such a position.
It is often assumed that when a person is good at his job he is good at managing other people doing the same job. For the average software developer, this is far from the truth. Many of them are unqualified due to lack of communicative and social skills. And the mindset needed for instructing computers is very different from the one needed to instruct people.

Programming is micromanaging computers. People management is NOT micromanaging people!

Switching to a job as a people manager requires a radically different way of solving problems, and technical people are not naturally gifted to make that transition. In fact, overly complicated process frameworks and methodologies like CMMI and RUP are sad examples of what happens when technical people try to describe how to manage projects, teams and organizations. They tend to think in terms of processes, tasks, input and output. They forget that managers are dealing with real flesh-and-blood people who prefer to be left alone to do their jobs.

(Have you ever wondered why the movie business does not have dozens of process frameworks and methodologies? It's because they have no technical people trying to describe how their business needs to work. Still, they are better at making their deadlines than we are…)

Non-technical people are even worse managers than technical ones.
Despite the inability of most software developers to become people managers, it seems that the selection of non-technical people is an even worse choice for management of technical people. It's because they don't speak the same language; they don't follow each others line of thinking and reasoning; they don't share the same humor, and they cannot communicate with each other using half a sentence and some jargon. Technical people need technologically savvy managers, otherwise there is little chance of a healthy basis for mutual respect and understanding. So, after my mistakes of 12 years earlier, I've learned my lesson.

You should not allow project managers to manage technical teams.

Software developers and project managers are peers. They take care of different things in a project. One is managing code and tools, the other is managing planning and resources. But neither is managing the other. They each have seniors taking care of that.

Give the job to a technical person who never asked for it.
I prefer to give the job of managing a technical team to someone in the team who never cared about that. I want him to be a person who is so concerned about buiding great solutions that he cannot be bothered to spend time micromanaging other people. But, since he has a passion for doing things right, he will commit to this assignment as he does to any other. He will learn how to do it right, and in the least amount of time. The technical managers I have selected this way have proven to be the most eager to pick up management literature, and to ask for management development trainings. They are also the only ones asking me for some advice when they have a management issue. They research how to prepare for their assignments, and how to solve their problems, as they have always done before.

I sometimes come across "people managers" who don't know a thing about managing people. They have never read the The One Minute Manager, The 7 Habits, Fish!, The 21 Irrefutable Laws, Peopleware, or any of those other great works. They think they already know everything. And in order to know everything, they want to micromanage everything.

I never wanted to be a manager. I still prefer writing code and building stuff. And when someone stops at my desk to show me a problem, I still sometimes secretly think "My God, why bother me now?". But I did read those books, and I'm still learning (actively and painfully) what it takes to be a manager. So now I take off my headphones and my wizard's hat, I smile at them, I give them a few pointers in some direction, and I might tell them that they should be able to solve the rest of the problem themselves. And after getting rid of them, I put my headphones and wizard's hat back on, and I remind myself to do a follow-up later that day, during any of the daily meetings and social talks, to see if all is going well.

I wrote this article as a follow-up to these three blog posts:

The Technical Manager (Jacob, April 23d)
From Developer to Technical Manager (Aaron Lerch, April 20th)
Do You Really Want to Be a Development Team Leader? (Andrew Tokeley, April 12th)

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
A Tasty Team Building Exercise
People Don't Read
Managers Under Attack!