Who Do You Promote Into Management?

I vividly remember my first promotion into management. I was looking for a promotion to be a senior engineer. I asked for a promotion. I got a promotion into management. Was I ready? Oh no!

I remember asking for another promotion. I was told, “You’re too valuable where you are.” I decided to make my myself less valuable and leave.

When I made my last transition into management—the one where I did not transition back into development or testing—that was the one where there were two candidates for the position. One was a very technical guy who barely had any people skills and didn’t like managing people. How did I know? He said so. I was the other candidate.

Now, you need to know that I have been working on my people skills my entire life. I’ve been given feedback that I’m too blunt and direct. I suspect that if I’d been born a man and 6 feet tall, I would have received kudos for being aggressive. I’m just too short and the wrong gender :-) On the other hand, I need to know how to phrase the information so the other people can hear it.

Promoting people into management is one of those very difficult decisions. It should not be a decision you make on the spur of the moment. If you have one-on-one’s with people, you can discover their career plans. You can help them, if they want it.

Part of a manager’s job is succession planning. Do you plan to be in this job forever? I hope not. Even if you just take a vacation, you are not going to be in this job for the rest of your life. You need to think about who you promote into management.

Who is the best person to promote? It might not be the person with the best technical skills. It might not be the person with the best people skills. It might be the person with some combination of the two. I don’t know. You should do an analysis of the value the job requires.

Here’s what I do know. If you always take the best technical person, you deprive the team of someone who was doing great technical work. And, if that person does not want to do management work, you deprive the team of a potentially great manager.

If you know of someone who falls into the trap of promoting the best technical person into management, have that person read my new myth, Management Myth #12: I Must Promote the Best Technical Person to Be a Manager.

Remember before, when I said I asked for a promotion? I wanted to be a manager. Why? Because I was ready for the challenge of making the difficult management decisions. I saw the project portfolio decisions that were not being made and I wanted to make them. I saw the client decisions that were not being made and I wanted to make them. I knew there were difficult tradeoffs to make in the projects, and I was willing to make them. Those were management decisions. I was willing to take a stand and make them. They were not technical decisions. They were management decisions.

So, think about who you promote into management. It should not be a spur-of-the-moment decision. Think about your succession planning. Discuss what people want out of their careers in your one-on-ones with your staff. Whatever you do, don’t fall prey to the Myth: I Must Promote the Best Technical Person to Be A Manager.

About Johanna Rothman

I help managers and leaders do reasonable things that work.
This entry was posted in management and tagged , , , , . Bookmark the permalink.

7 Responses to Who Do You Promote Into Management?

  1. yveshanoulle says:

    Hi Johanna,

    I’m not sure what can be done to being too short, but I do know you can change gender if you want ;-)

    Anyway, for me promoting the best technical person is not the root cause.
    The company not having a technical career path is.

    I have seen lots of companies where the technical career is:

    – junior
    – senior (after 2 years==> waaaay to soon)
    – management (for the best technical people)

    Construx has a nice professional development ladder http://www.construx.com/professionaldevelopment

    And maybe the option is: we train people to a certain level and then we have to let you go, as we are a small company and we can’t help you grow.
    I think one of my first bosses uses this idea, and I like it. Much better then promote at all costs.


  2. Alex Fürstenau says:

    Hi Johanna,

    thanks for the article.

    Do you think you have to promote someone into management? It might be a bit naive but I keep asking myself if we really need these roles, levels and so on. In my company we have different roles (PHP Developer, Frontend-Developer, Quality Manager, Project Manager, …) and different Levels (Junior, Associate, Senior, Lead, …). I try to get rid of at least the levels because I tried to find reasons for these. I couldn’t find any myself so I keep asking people for reasons. The #1 reason was: If my title is Lead *whatever* I might get better payed by my next employer. :-( So, these roles and titles seem not to be important to work good together.

    Do you have an idea for what they might be helpful?


  3. Johanna says:

    Alex, the different levels of technical staff is often for HR to manage the salary levels. Sometimes, it’s for the people themselves to have a technical career ladder if they have criteria against which to measure themselves. If there are no criteria, and then it’s all about salary, the levels are just for HR. Well, that’s the cynical side of me talking. Maybe I’ll write a myth about levels and why we have them. I actually like technical career ladders and internal apprenticeship/mentoring programs. I don’t like levels that are just associated with money.

    For management, I truly believe that good management is useful. A good manager builds a trusting relationship with each person on a team. See Behind Closed Doors: Secrets of Great Management. Later, I wrote an article about how we still need managers, even in agile organizations. See it here: Agile Managers: The Essence of Leadership.

    Great managers leverage the work of other people. The don’t control other people. They make it possible for other people to succeed. They create an environment for other people to do great work. The problem is that we don’t have lots of great managers. We have many good managers. We have some okay managers. We have too many bad managers, who do not realize that they are harming the environment that their people are working in.

    It’s okay to make mistakes. I’ve made plenty. The question is this: Did you make a mistake because you believed some kind of a myth without looking for evidence? Or, did you make a mistake because you happened to make a mistake?

  4. Johanna, thanks for your reply. Don’t get me wrong. I believe that we need people who can modify the environment/system to help others doing their jobs but is it necessary to give everybody a specific role name?

    I often hear something like “We need a testing guy here” or “The team needs project management support” which is the short form for “We have too many bugs” or “We always miss our sprint goal”.
    So, most of the time people are not interested in a special role but in solving a more or less specific problem.
    I don’t see reducing people to one more or less randomly selected attribute helping in finding the right people for the right team.

    Maybe, the role names are necessary in a company wide context?

    I have been moving from a developing centric career to a more coaching centric career for the last two years and I have done a lot of mistakes but I have really learned a lot. :-) I hope I can continue to improve myself and my company every day a little bit.

    Best regards,

  5. Johanna says:

    Alex, by any chance are you folks agile? It sounds that way. If you are agile, you need to make sure that the roles are covered. You may or may not need titled people in those roles. The project needs to cover the roles.

    Now, that said, I will tell you that when I am a developer, I do not see my defects very well. In fact, I am excellent at testing around my defects. I don’t mean to, but I do find only some of them, not all of them. When I am a tester, I think differently about development. I’m this way when I write code, and when I write books. For me, it’s a similar process. (Yes, I use question-driven development for my books :-)

    I like to see project teams swarm around features. In my experience, that helps teams blur the distinction of roles. Until they do that, the roles are entrenched. And, even after that, sometimes, the roles are entrenched. Not everyone is very good at being a generalist.

    We are all capable of flexing, some of us are more or less capable. You, since you have chosen to coach more, have chosen an even more generalist role than other people. Not everyone is comfortable with that. Some people want to further their development or testing specialization. Our organizations need some of that, and should be able to tolerate that. Where will the next generation of product and test designers come from? On the other hand, these people also need to step back and look at the product from the other side, too. Too much specialization can be a bad thing.

  6. Well, Johanna, several colleagues have an agile mindset and I see myself as one of them. We try to move our company in a more agile direction but it’s not easy and it will probably take quite some time.

    A lot of different people in my company declare Bigpoint as agile but I heard a lot of people declare almost every company doing agile. So, agile seems to be the property to be these days. ;-)

    There is still a long way to go for myself, my company and a lot of companies.

    Best regards,

  7. Pingback: Creating a Succession Plan for Your Technical Team | Hiring Technical People

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>