How to Harm a Programmer?
The difficult art of promotion — how to promote a programmer without harming them.
Junior – Mid/Regular – Senior. The evolutionary path of a developer looks roughly the same. It is rather independent of the programmer’s age.
So you can imagine a 23-year-old prodigy who has written 8 commercially successful apps in React Native and works in a senior position. You can also imagine a 56-year-old junior Rust developer who used to be a senior in Cobol but decided that money isn’t everything and personal growth matters. These examples are a bit random and, on top of that, they lack female characters, but I only need them to illustrate the argument. Anyway, I’ve drifted a bit from the main thread.
Is there life after Senior?
Junior – Mid/Regular – Senior. Does the path end at Senior? Can a Senior be promoted? I’ll try to add some nuance to these questions.
Of course, a programmer’s career path does not end at the senior position. Within teams there are additional roles, more or less technical, to which a programmer can be promoted. Leaving aside the somewhat comical ones such as Scrum Master or Agile Coach, we can point to at least two promotion paths for a Senior that require slightly or significantly different competencies than writing code. These are:
- Areas related to software, solution, and integration architecture
- Management
In this post I will focus on the second point.
The golden robes of the Manager
Unfortunately, in corporate environments there is a cult of the Manager, and the obvious promotion path for a distinguished senior developer is the position of Team Lead(er). Or simply Manager / IT Manager, if the company doesn’t bother with naming nuances. Under these titles there is often the responsibility of managing a development team, sometimes also its branches: analysts, testers, DevOps engineers, database specialists, etc.
Promoting a programmer to a managerial position usually means even more money for them and — in some circles — prestige and a sense of elevation. The other side of the coin, however, is the multidimensional mismatch of the promoted person: in terms of competencies, psychology, personality, and public image. I’ll focus on the first aspect, because I don’t want to fall into naive psychologizing and low-effort coaching.
The Peter Principle
Someone already wrote about this — Laurence J. Peter. The principle he formulated can be summarized as follows: an employee gets promoted until they reach their level of incompetence. This elegant formula was presented by Peter in 1969 and referred to American organizations with rigid structures and well-established hierarchies. But let’s try to apply it to our industry.
Promotion along the junior–mid–senior line is primarily an increase in hard competencies: better knowledge of the programming language, the platforms used, IDEs, Git, frameworks, CI/CD, sensitivity to code smells, etc. It is a change along the vertical axis because — at least in theory — the promotion corresponds with an increase in competence.
Meanwhile, a promotion from Senior to Manager / Lead is already a major qualitative change requiring completely different skills. Often these are competencies that the given person will not be able to acquire, because they contradict their personality traits — the very traits that made them a good programmer in the first place. A capable manager should be characterized by, among other things, assertiveness, communication skills, the ability to delegate responsibilities and assign tasks, multitasking, high resistance to stress and pressure from line management, confidence, budget control, and a certain drive — because I’m not quite sure what else to call that managerial energy thanks to which spinning grand visions about milk and working software flowing everywhere comes naturally to the person who possesses it. Oh, and let’s not forget the ability to serve the business well, often at the expense of the development team. Sound familiar?
These traits are, if not contradictory, at least quite different from the typical soft skills of a programmer: someone focused rather on a single task, analytical, contemplating a problem before finding a solution, exhausted by even one call per day — from which the daily alone has already drained the reserves of sociability and willingness to understand problems other than the one currently being worked on. Of course, this is a very stereotypical image, but, hmm… maybe there’s something to it.
The other side of the coin is that by promoting a good developer to a managerial position, the team loses a good developer. It is rare that a programmer promoted to a managerial role still has the time and willingness to work with code. A good dev is a meticulous dev — someone who thinks holistically, connects the dots, understands the architecture, and knows the strengths and weaknesses of the systems they work with (which often equals possessing tribal knowledge). We lose much of that when we promote a good developer to a managerial role. Once promoted to manager, a person’s ego is often sufficiently stroked that even if it turns out to be the worst position for them personally, they will cling to it in the name of the considerable privileges that come with it. Ah, the rather undisguised charm of power and money.
Money, not circuses
To sum up.
- A very good developer may turn out to be a very poor manager.
There is no direct transfer of competencies here because these are two separate domains of expertise requiring different skill sets. Yes, managers also have competencies — there is a reason why the kinds of people who assign you tasks push themselves into these roles.
- A weak developer may be a very good manager.
And with a technical background — which, by the way, is the kind of manager that many corporations struggle to find. Sometimes, however, such a person compensates for a lack of success in programming and transforms into a manager convinced of their own omnipotence, with an inflated ego, authoritarian tendencies, and primarily motivated by their own Schadenfreude. In fact, being a good IT manager is, contrary to appearances, a difficult challenge — but that’s a topic for a separate post.
No injustice is done to one who consents
So what about that promotion? One would like to answer with the ubiquitous verbal skeleton key: “it depends.” It depends, among other things, on the preferences of the programmer themselves. Some people find themselves better in maintenance, some in product development and solution architecture, some at a certain point in life burn out as programmers and open a craft kebab stand or a winery somewhere in eastern Poland.
Some want to leave their comfort zone (what?!) and move into management even though all signs in heaven and earth suggest it’s a bad decision. Well, no injustice is done to one who consents.
Some — if not most — care mainly about money, that is, financial security. For such people the greatest promotion is no promotion at all and a raise. In other words: staying in their area of expertise (comfort zone) while earning increasingly more money. And that’s the kind of reward path I would see for a good developer if they are not interested in management.