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.

13 Comments

  1. 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.

    Yves

    Reply
  2. 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?

    Thanks,
    Alex

    Reply
    • 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?

      Reply
  3. 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,
    Alex

    Reply
    • 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.

      Reply
  4. 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,
    Alex

    Reply
  5. Is the real problem that people see management as a step up? You have developers/testers/janitors at the bottom, above them a layer of managers, above them another layer, then maybe the c-suite.

    Companies have created a situation where if you want to progress in the company you have to leave development and become a manager. That makes no sense when most developers / testers I know never want to move into management. They see it as a pointless waste of time where you have to spend your time playing the political games with other managers. Meanwhile the customers suffer because their needs are not the focus of the company.

    Much better to have a technical progression within the company, where you can climb higher if you want to keep the technical side. It is incredibly expensive to replace a technical person with years of experience and understanding in a company. They need to be fairly rewarded for their commitment (and as Dan Pink tells us that isn’t just about the money is it).

    Reply
    • Andrew, it is true that in many places, if you want to get a promotion, you need to leave development. That is nuts. I wrote a post called Creating a Succession Plan for Your Technical Team.

      Most hiring managers barely know how to create a reasonable job description. They leave all this strategic work to HR. Most HR people are paper-pushers, and have no idea what technical people do. This is a disaster.

      This is why you want people who understand software and like the people part of the job, managing people. They don’t have to do much “management” of people. They manage the system. But, we still call them managers. If we give them another name, we’ll discombobulate HR, and that’s crazy-making. We can keep the name and change the deliverables. That works.

      Reply
      • That is the thing isn’t it, when you step back there are parts that just make no sense. How can have HR write the job descriptions for something they don’t understand? Yet you see it all the time.

        I think you are right, a fundamental understanding of how to make software is essential then a love of the people part to go with it. That is not a wide group of people. What is it about developing software that so many are unable to grasp?

        Maybe it is my agile bones but something in me just isn’t happy when you have to mold the departments/teams to what HR/the company thinks is right. That is just highlighting the fact the culture of the company isn’t agile and doesn’t really get why it is different. So will continue to struggle to make good software.

        P.S. Yes you don’t ant to confuse HR that way lies pain.. but maybe they need to be brought up to speed?

        Reply
        • This is why I ask/please/insist (take your pick) that hiring managers do a job analysis and write their own job descriptions. I have met several HR people who know what they are doing, but too often they are outside the organization. It’s why I write Hiring Technical People. It’s why I wrote Hiring Geeks That Fit (with templates for everything).

          The HR people I know can learn. If they have time to learn. But if it’s a small company, HR is supposed to do benefits, plan parties, keep the paperwork up to date, decide which health plan is right (here in the US that is an amazing amount of work), administer the retirement plan (again, an amazing amount of work), source new hires (ha!), and in their spare time, help managers manage.

          HR exists to keep the company out of court. They know how long to keep paperwork. How can they do anything else?

          I feel for them, I do. But a one-person HR department for a company of 60 people (not uncommon) is spread way too thin. Two or three people for a few hundred cannot coach managers or understand what technical people do. These are not strategic HR people. And yet, who is advising senior management about leadership and management??

          Maybe you and I should pair on an article. We seem to have the passion for it.

          Reply
          • I feel for HR as well, they have a tough job. They can always learn, they are always a clever bunch of people. But the technical end of things is so far outside their normal realm it just isn’t something they can assist with.

            So why are HR involved in hiring at all? The development team are best placed to hire new team members. They are going to have to work with them, they know what they are looking for, they know what they need. HR can then fall back to their role of keeping the company out of court.

            If a team want to go agile then hiring people into the team falls right into them self-organising. I believe they should own that process. It doesn’t have to be time consuming. Even though a lot of companies love to make these incredibly time consuming processes for hiring.

            Happy to pair up on something any time. I am really enjoying your writing and I think you are right, it seems to be something we both have a passion for.

          • HR is involved with hiring because they “own” human resources, right? They are involved with training because they “own” human resources, right? Don’t get me started on why HR is exactly the wrong people to define what the leadership needs are for the technical side of the organization. Although here is a tip: if you don’t understand the dynamics of the work, how can you possibly define the project management needs, the management needs, or the leadership needs?

            This is why HR cannot possibly know how to define a job analysis or a job description for a technical person or a technical manager. And, yet, they attempt to do so all the time. This is why I wrote Hiring Geeks That Fit. So that the technical hiring manager had a shot of success.

            You are correct. The development team members are best placed to define the team members they need and to hire. Most of them don’t know how to define the roles or how to hire.

            Because HR exists to keep the company out of court, HR imposes some time-expensive processes. Of course, the way some tech people hire, they make it more difficult on themselves, too. The people who understand hiring don’t understand tech. (A very few of us do.) It’s a problem.

          • This is one of my pet peeves.. They call humans resources. Their own very name dehumanises the very people they are working with. People/colleges/team members are not resources stop trying to deal with them like they are tables. As I say, a pet peeve of mine. It is why I think a start-up can run circles around larger companies because they are more like a family than a corporation.

            That is it, what does HR really own? As you said before it’s purpose is to keep the company out of court, and deal with the admin things that happen when you employ people. HR are can never be the people to ask when you want to define the leadership needs, they want everything clearly structured because that makes it easier to look after. They don’t really see the complexity of developing software.

            I totally agree, they shouldn’t define the job description for any technical position. That is how you end up with descriptions for people with an insane number of skill. All they can do it parrot what they have heard from others (technical managers).

            In my experience the development team know exactly who they are looking for, they know the skills they are missing and just who they need to fill that gap. I have seen teams write their own requirements with ease, mainly because it is what they would want to see if they were looking for a job. Is the real problem The boss/HR doesn’t want to let go of finding the person THEY want not what the team thinks is best?

            But they are also stuck in traditional methods of looking for people. Asking agents, putting ads in papers, on job boards. Don’t get me started on why they listen to what the agents say to them (Lambs shouldn’t believe what the wolves say, yet they do). There is a new world out there when you go looking for people it just seems so many HR departments don’t know where to even start.

            This is where a company lives and dies. Hire the right people and everything flows from that, get it wrong and you start the slow death of a company.

Trackbacks/Pingbacks

  1. Creating a Succession Plan for Your Technical Team | Hiring Technical People - […] often think about a succession plan for managers. But, if you’re not thinking about a succession plan for your …

Submit a Comment

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

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