≡ Menu
Pawel Brodzinski on Software Project Management

Why Do We Keep Promoting Wrong People to Management?


I was thinking recently about career paths in IT industry. My special area of interests was how people get promoted to managers and why. The conclusion I came up with is pretty sad.

Career paths in IT industry are screwed.

A typical promotion chain looks something like: developer, uber-developer, manager. That’s nothing new under the sun, right? This is basically how most of us got promoted to management roles. Where is the problem then?

Actually I see two issues. First, organizations typically promote best engineers to management roles. Like the engineering was oh so similar to management or something. Like the best engineer around automatically was the best possible candidate for a manager. Like the skills needed to perform on these positions weren’t completely different.

What a bullshit. Actually the best possible candidate for a manager is the person who is, well, the best suited to become one. Possibly one of those average coders out there. Yes, the one who somehow often helps the team to deal with problems even if she doesn’t make the most difficult job by herself. Well, she kind of helps to shine everyone around. Even that superhero coder you consider as the most valuable team member.

After a second thought wouldn’t it be better to promote her instead of the best engineer?

Well, it probably would but there the second issue pops up. Your superhero engineer also looks for some leading role to push his career ahead. And the only one you can offer is a team manager. Now, if you choose someone else for promotion he will likely get frustrated, quit, will found his own startup and build it up, buy your company and then fire you for your lousy leadership skills. And even if this plan doesn’t work exactly that way, losing your superhero coder isn’t the first thing you’d like to deal with.

This is another thing I don’t really get. Why there is no tech lead role in many organizations? Why do we have to promote best engineers to people managers even though they suck at dealing with people. They can show their leadership where they mastered the art – in software development. So let them lead whenever you build software. But when it comes to deal with people, and managers do deal with people all the time, you better have someone who focuses on the team and not on the project.

As my thoughts go through many organizations I know I very rarely see a clear distinction between these two roles: people manager and technical leader. The effect of the situation is this screwed career path which not only produces mediocre managers out of great engineers but also leaves great candidates for people managers unnoticed. A kind of lose-lose situation if you ask me.

This is not how you want to lead your organization. Or is this?

in: personal development, team management

25 comments… add one

  • neilj September 20, 2010, 4:30 pm

    The problem is that even if you succeed in keeping your best engineers out of management, it is not true to say that the best engineer is the best tech lead.

    I guess it depends on how you define the role, but I consider a tech lead to be responsible for, amongst other things, the technical progression of those around them, (through coaching, code review, introduction to new ideas/concepts) sometimes to the detriment of their own personal technical contribution.

    The difference between this and an individual contributor is that while the individual contributor *can* spend time on the development of less experienced members of the team, the tech lead *has* to spend that time.

    This requires a selflessness on the part of the tech lead that is not shared by all. This means that it is necessary to provide a third track for the individual contributor.

    Success in this track is harder since managers and tech leads (should) amplify the effectiveness of those around them, while the individual contributor can only amplify themselves. However it is a path that should not be over looked.

  • Josh Nankivel September 20, 2010, 7:09 pm

    Great post Pawel! Here is my response:

    What I Look For In a Technical Lead

  • Machiel Groeneveld September 20, 2010, 10:23 pm

    I guess the same goes for those people that studied business administration or something similar or sales people that got promoted to a management position. I see you distinction between technical and people management, I don’t see why IT is the exception

  • Pawel Brodzinski September 21, 2010, 12:50 am


    You’re right that the best engineer isn’t a sure-shot candidate for tech lead. Actually it wasn’t my intention to say otherwise. The problem I see is that many senior engineers consciously look for a position which allow them to lead. And that is where teach lead role comes handy.

    And yes, tech lead should introduce new practices, help to improve code quality etc. It is still work with code, not with people. This still differs much with people management role.

    You’re right with individual contributor path – there should be one, but this way or another it usually is present in organizations. Sometimes it is too short and has not enough senior positions but you can say it is non-existent.

  • Pawel Brodzinski September 21, 2010, 12:56 am


    I don’t say IT is an exception. I pretty much expect it isn’t. But I don’t know other industries well enough to say for sure.

    You mention salespeople. I think it is a bit different. Why? Because managing salespeople is different. Vast majority of salespeople I know works very independently. They don’t cooperate as much within their teams and with other teams in the organization. But after all, I’m not a salesperson so I don’t play an expert here.

  • jfbauer September 21, 2010, 3:27 am


    I wonder how many managers make the problem solving connection between a good developer and management. What I mean is a manager that is removed from day to day, hands on coding and technology is constantly solving non-technical problems all day. That manager sees their best developer also solving problems every day, just more technical ones. Plus, the manager probably is looking at that good developer as the guy/gal he/she goes to get their quasi-technical/management problems solved. Thus, the manager sees the good developer as a good problem solver, loosely similar to themselves.

    Thus, when a management position opens, the good developer, seen by management as a problem solver, becomes a likely candidate regardless of true capability to coach/mentor/lead others/etc. This, coupled with familiarity of the good developer versus someone random from the outside that doesn’t know the power structure, players, company culture,etc. may propel the good developer into management.

    I can’t say this covers 100% of the cases, but in looking back, I have seen this pattern in past professional lives.

  • Tim Western September 21, 2010, 5:16 am

    The problem is actually simpler than that, people have misconceptions about what leadership is, and what management is. Because of this, is it any wonder that this is still an issue? It isn’t to me, leadership isn’t necessarily about ordering people around, but it is about inspiring others to work together. I think perhaps this is a bit cultural in some instances, where we tend to see the leader as this lone wolf, when what he needs to be is more like the Captain of the Enterprise, putting the right people in positions to excel.

  • Mariusz Kapusta September 21, 2010, 5:16 am

    Well, if you don’t know what it’s about it’s about money ;).

    Usually managers earn more than developers, which makes the problem hard to solve since the system is screwed itself. Developers even if they don’t feel they can be good managers want to get promoted since in moste of the cases it’s the best and ONLY way to get more: money, prestige [put here whatever you want from Maslov pyramid].

    Response to that is setting separate career paths without attaching to them success (manager) or loser (always-developer) notion. Best in class developer can earn comparable to managers. Real specialists earn much more.

    I would focus on those two:
    1. Self-assessemnt and informed decission of every person: who am I want to be, where are my strenghts, what to do to play them well -> choose my path
    2. Setting career paths for both groups.

  • Pawel Brodzinski September 21, 2010, 5:50 am


    You’re right. However if a manager sees his own role in a way you describe it probably he shouldn’t have been promoted in the first place and the system which got him promoted is screwed.

    And yes, screwed system produces more and more wrong results, namely wrong promotions.

  • Pawel Brodzinski September 21, 2010, 5:57 am


    The notion of leadership is often screwed and probably if we could get it right we would improve promotions we make in our organizations. Yet somehow I don’t expect it would really solve the problem.

    If there is only one option to advance most people will choose it no matter if they are suitable candidates or not. And we would still have managers who should manage because they just suck at the role. Beyond all repair.

  • Pawel Brodzinski September 21, 2010, 6:08 am


    To some point – yes, it is about the money. This is by the way one of reasons why stiff salary ladders suck. However these few companies with reasonable career paths I know usually have money sorted out correctly.

    Actually if I was asked to design salary ladder I would leave it (almost) completely open. I don’t see a problem to see a developer earning more than senior manager. Of course as long as she’s worth it. This approach requires good managers and so we come back to the first issue.

  • Bruce Lofland September 21, 2010, 6:50 am

    I blogged about this recently here: http://blog.pmtechnix.com/from-geek-to-project-manager/

    I agree with you. This is one of the problems in IT that I have seen many peopl struggle with as I have myself.

  • Martin Proulx September 21, 2010, 9:31 am

    I recently heard someone say “it takes 10 years for a software developer to become really good at what he/she does”.

    When an organization so heavily invests in its developers, why would they want to put them on another career track and promote them to manager? I wonder…

  • Pawel Brodzinski September 21, 2010, 12:09 pm


    Because no one had another idea. Because this is how things are done there. Because people themselves want to move out from development. Because no one cares. Because salary system is screwed. I guess there are many answers to the question.

    A few years ago I run a survey among developers and the question was “what would you like to do in 5 years from now?” Pretty few people wanted to stay on development track – most of them wanted to move. However it is difficult to say if it is a reason or a rather an effect of screwed career paths available in IT.

  • Jüri September 21, 2010, 10:30 pm


    I could not agree with you more.

    I was a developer myself for years, before becoming development manager. The change occurred when we hired two new developers who were just way better developers than I could ever be. And I understood that my dealing-with-people-and-writing-skills + tech background is not very common and so I switched.

    Actually – the other part of the problem is that developer is considered to be somewhat inferior to development manager, which I think is total load of BS. Developer is the person that gets the job done and creates the value that is sold to customer, not the blabbering, planning and writing works of a development manager.

    I guess that a good engineer should not be promoted to manager but should be promoted to more interesting and challenging engineering jobs. That’s it. All management is BS and overhead anyway, creating-value-for-customer – wise.

    I really hate when my team members call me a “boss”. It is just painful to hear. I sometimes say: “I am here only to help you to show everyone off how good you guys are”

  • Pawel Brodzinski September 22, 2010, 12:41 am


    Well, for me “more interesting and challenging” job was managing people. One of my former manager used to joke that I’d been an average developer so they decided to promote me to management. And to be honest I think there is some truth in it.

    But that’s not a reason why I stick to people management or why I advanced as a manager. I just found it something I want and like to do. Something which can be equally challenging and difficult as solving most complex engineering problem is.

    Anyway, I fully agree that manager’s job is to remove obstacles and to make engineers shine. However I consider it creating value. After all you, as a manager, make a difference. Of course as long as you’re damn good manager.

  • Stan Yanakiev, PMP September 22, 2010, 1:12 am

    Great post, Pawel. I totally agree. The Halo effect of promoting good engineers to managers can be avoided if there is technical career development path in the organization so that in order to grow an engineer does not need to become a manager.

  • Barb September 24, 2010, 11:30 am

    Great post and I will have a future post on this subject because I just went through something similar. The other interesting point is the “bundling effect”, which I wrote about a while ago; when you combine the role of project manager with something technical like system admin, engineer or even system analyst into one role. Do you really get good project management when an engineer is managing a project? This bundling seems to happen when economic times are tough, then I get called in to rescue the project. You can check out my post at http://www.vyrtunet.wordpress.com. I recently posted a series of articles on business culture change and management.

  • Pawel Brodzinski September 26, 2010, 7:08 am


    Actually there is one situation where bundling roles makes sense. In tiny organizations you probably will have a lot of bundles like engineer + project manager, developer + support engineer, etc.

    It might also make sense when economics is tight but than it is a bit different discussion and it is, well, about economics in the first place.

    However I’m not sure if bundling engineering roles with management does make sense even in those two situations.

    In tiny teams you’d probably have a natural leader and, to some point, it would be more than enough. If your grow to the point you need to appoint a full-time manager you better have her working on her management skills. Otherwise you’d end up with half of mediocre engineer and half of mediocre manager instead of having at least one role performed well.

    With poor economics having a good leader at hand can be even more valuable as he can help you to carry the team through tough times.

  • Mariusz Kapusta September 27, 2010, 4:00 am

    @Barb, Paweł: I was bundled some time ago myself. Worst thing you can do! When you are key designer, analyst and PM there are moments when all 3 of you are needed at the same time. It means 300% workload. Cannot be done :(.

    I’m promoting idea to focus on your strengths. Every tema need experts and every team needs a leader. Separating those roles if possible is best. However on small teams it would cost too much. The key item to remember is to make sure you do not overload “bundled” person with catching up with engineering job.

    Usually if you are engineer and you like it, in time of stress you would come to comfort zone, which would be programming instead of going where you should – managing the project.

    I agree with last statement: in times of crisis you need strongl eaders who will show the way to the others. Otherwise you will stay where you are.

  • Pawel Brodzinski September 27, 2010, 10:22 am

    “Usually if you are engineer and you like it, in time of stress you would come to comfort zone, which would be programming instead of going where you should – managing the project.”

    Actually it should be printed using big font and given out every person who is promoted from engineering to management role.

    Bundling roles always brings some risk of one role being sacrificed when the role of preference requires more time. In terms of leaders you better have people whose role of preference is leadership and not engineering.

  • worthey brisco September 29, 2010, 7:04 am

    As someone who has never spent a day in the IT world, but has been in leadership positions (I prefer the term leader over manager; you lead people … you manage things) for over 35 years, I can tell you the best leaders seem to have pretty much the same traits in common, regardless from whence they came (even engineers! ;-))) Here, in no particular order are some of my favorites:

    1) They know their people … strengths, weaknesses, goals, abilities/capabilities
    2) They know their own shortcomings and surround themselves with people who are strong in those areas where they are weak. Or, in those cases where they have to “play the hand they’re dealt,” they can cobble together a team of performers, playing off of each other’s strengths and weaknesses. As a boss once told me, “a real leader is someone who can take the imperfect team, in the imperfect situation, and make it work.”
    3) They’re Smart. Brilliancy is not required, but dunces and dupes needn’t apply.
    4) They’re Great Communicators. Listen …listen … listen.
    5) They’re Fearless. Sure, all leaders feel fear or doubt at one time or another (those who say they don’t are either liars or narcissist) but as the old deodorant commercial said, “Don’t let them see you sweat.” Both your team and your bosses are looking to you to remain firm and confident, regardless of the situation.
    6) They’re Approachable. Don’t be an arse. Make it known (and prove it) that your folks can feel free to come to you even when the news is not good. How you react/handle those times will more often than not become your reputation.
    7) They’re Loyal. No one gets thrown under the bus … no one. You take one for the team … then go behind closed doors and do the necessary counseling.
    8) They’re Ethical. Each and every time … whether someone is looking or not.
    9) They’ve got Great situational awareness. Very few times do good leaders get caught their pants down … those “uh-oh” moments we all remember.
    10) They’ve got a good sense of humor … including the self deprecating kind. I’ve seen many a tense moment/situation overcome by a leader’s sense of humor. Whether a joke, or a comment … humor has a great way of dissipating the awkwardness or unsettled environment that can inhibit any team.

    Of course, such a list could continue on, but these are some of the traits I’ve seen displayed by other successful leaders and ones I have striven to emulate/reflect any time I was called upon to lead.

    What has been your experience?

  • Pawel Brodzinski September 29, 2010, 8:35 am


    When I read your list I could sign myself under each and every of those points. Everything you wrote is about people and not about engineering (or whatever else you want to put here instead).

    And yes, you can find those people among programmers too, but the point is they are very rare. Or maybe not so rare, but these traits don’t make them shine as developers and they’re often omitted when organizations look for leaders. Instead they are choosing people who will never become great leaders as they have inability to work as you describe.

    And yes, this means choosing leaders or managers among IT organizations is generally screwed.

  • Jake October 2, 2010, 10:32 am

    The best engineers out there show a huge ability to understand, progress, and keep with the industry. If an employee has the intelligence and understanding to become a great engineer, he can easily become an equally great manager.

    99% of the time, the super secluded unperson-able developer, is not the best engineer (usually tries to give off this impression fairly radiantly), but if you find that you truly have a ‘Great Engineer’, promote him to management.

    Give him the time to become a great manager, if he has the dedication to become skilled in the arts of software, I can assure you he will read the books on management, find the most efficient and productive ways of dealing with people.

    This is almost insulting to people in the industry, If you have someone who is incredible with dealing with systems, let them lead your physical systems, If you find someone who is a mediocre engineer, then chances are ( no matter what there people skills are) they will be a mediocre manager, period.

  • Pawel Brodzinski October 2, 2010, 12:45 pm


    I can’t agree. If I pushed your arguments a bit further it would mean that the best doctor is also a best candidate to manage a hospital. And this kind of thinking is one of most significant issues with health care system in my country.

    But coming back to software industry, I’ve seen counterexamples to your approach in big numbers. There is even a theme I see over and over again, which is a belief that a good manager should be, in the first place, the best engineer in the team. And since those people are indeed gifted engineers they are even able to keep their technical skills at top level. But the question is at what cost?

    The answer is, at cost of making their “people skills” not improved even a bit. They might have even read a few books about management and treated them as they treated book about algorithms – as ready recipes how to work with people. The problem is people aren’t like computers – you never know for sure what you get as a result of your action.

    However I’m not going to say it is impossible. I know a few good engineers who are making/have made the transition the good way. But they are more exceptions from the general rule than majority.

    Intelligence and understanding is not enough to become a good manager and they’re definitely not enough to become a good manager easily.

    Anyway I agree that a developer who sucks in communication ans has virtually no soft skills whatsoever isn’t a great engineer. Yet still, the set of skills to become a great engineer is completely different than one needed to become a great manager. Probably none of the latter is unteachable but wrong approach and scale of learning effort make it a task which few succeed at.

Leave a Comment