The Fallacy of Individual Contributor
A typical developer career path looks something like this:
Of course, this varies a lot from person to person and from company to company due to different skills and competence, culture, trends, luck, goals and personal situation.
Naturally, it gets crowded at the top, that is, less positions available, but the ratio between individual contributor and management is probably less dramatic than what you’d initially imagine. In some teams I was in, we were 3–4 people with one manager, in others I had way more managers than individual contributors.
Take a common example: 3 teams of 3 developers, each has 1 team lead plus a head of engineering and a CTO.
9 individual contributors and 5 managers:
The main differences between IC and management paths, are impact and compensation.
The impact of IC is mostly “local” — implementation, finding solutions, resolving incidents, technical and domain knowledge sharing, etc.
Management impacts the vision, strategy, culture, processes, hiring and has responsibility for future and growth of the reports.
Almost always, the salary is higher for management roles. On top of that, it is way more common to have bonuses and shares or stock options.
My career path
- QA engineer (6 years)
I was still a student for computer science, and it was common back then, to start as a QA engineer, learn the domain and the products, and then move to development. But the dot com bubble burst and everything came to a halt. When the market got better, it was tough to find a development position, due to having a rich QA experience (it’s a trap!) I kept learning and improving. Most of my colleagues were people who had nothing to do with computer science or technology and showed little to no interest in becoming more professional. After a very junior colleague with several months of experience in the industry was promoted to be our team lead, I realized I needed a change. I took an expensive, private programming class and worked evenings and weekends as a developer intern without salary in order to gain experience. - Developer (3 years)
I started my development career in a projects company. The salary was very low, but I was happy to finally start my real career. After a while, I realized that the level was rather low and I was not improving. I switched to another low paying projects company, but there I found great mentors and gained a huge amount of knowledge in development, teams, processes, techniques, technologies and guidance what books to read. - Senior developer (1.5 years)
In the same company, I moved to another project, where I could already mentor others and make use of the best practices I had learned. The client I was working for wanted me to be employed directly by them, with a managerial future, but that would have meant a significantly lower salary, which I couldn’t afford at that time. The projects company didn’t have other projects, so I sought new opportunities. - Team lead (3 years)
Armed with a rich development experience, theoretical knowledge and industry best practices, such as: using design patterns, writing automated tests, introducing a build server, cloud techniques and so on, I got hired as a team lead. The company was very small and I officially reported to the CTO, but the CEO micromanaged all of us, including me and the team members I was supposed to manage. I had the responsibility and the title but no real managerial duties and authority. That didn’t change even when the CTO left and I became the interim CTO. The company was eventually sold to a big company.
For over a year before that, I was learning a new discipline — web development, which I never did before and intrigued me. I spent nights and weekends on becoming proficient. I decided to start over from the bottom and found a web developer job. - Developer (4.5 years)
Worked with brilliant colleagues and learned a lot again. Had much to cover, the entire ecosystem, after so many years of non-web development. We were among the first Ruby developers in the country and together we laid the groundwork for the application which generated huge revenue. Despite that, and despite being an experienced developer, mentoring others, I was regarded as a junior developer by the team lead whose capabilities were mainly good unix command-line usage and some javascript knowledge.
In my next position, which I relocated for, I worked again with experienced smart colleagues on a very large scale operation and gained further knowledge and experience, including DevOps. I was underpaid again, which is quite common for a first relocation job.
After it seemed like the company was going nowhere, I got contacted by a former colleague, had a great interview and was offered a senior role again. - Senior developer (2 years)
With so much technical experience and years of practicing and learning hard and soft skills, I felt comfortable leading and managing projects, consulting management, architecting systems among and interviewing on top of the ”regular” developer tasks. The salary was on the higher end of the scale for developers and I got virtual options. My performance was good and the plan was to become a team lead as the company would grow, but this growth never happened, rather the contrary. I decided to leave after some trust-breaking incidents, and started again as a senior developer, where I took again, many responsibilities, such as interviewing, mentoring backend developers and leading squads.
Major career errors
- Getting stuck in QA role, aspiring to lead the team.
I believed that working smart, hard, more hours, being accountable and keep learning would help. This proved to be wrong.
The fix — a too late initiative to switch to development, my real passion. - Taking jobs that pay low.
I enjoy this profession very much, and learning was my highest priority. But was it really impossible to find a job that was both good paying and teaching? Remember that it has implications also on retirement.
The fix — no settling for too low pay any more. - Not documenting my achievements on a daily/weekly basis.
Companies tend to hold performance reviews twice per year, and I had to think back. The worst one I had, was with the command-line expert manager, who focused on my lack of knowledge with a specific type of web component, ignoring my contribution altogether. This had cost me a huge bonus.
The fix — document achievements as well as failures.
To my surprise, this doesn’t always work. I had a case, where I gave a very detailed self assessment in a performance review, but the team lead ignored it and gave lower grades “based on intuition” with zero explanations, examples or topics to improve.
This unfortunate event gave me the idea to have someone representing me in the performance review, like an attorney or an agent… - Staying in the comfort zone.
I had to work way harder than any other developer I knew to keep improving. I was not the brightest, fastest or most knowledgeable. But I constantly worked overtime, kept reading many articles and books and practiced after work. I remained on the same route all the time, afraid to do anything else.
The fix — try another area — tried DevOps but didn’t like it. Below I will share a list of alternatives I am thinking about. - Bringing a lot of value, but it’s unnoticed.
Wrote about it in when it’s bad to be a good developer.
The fix — brag and take credit when possible, optimize for what I am measured for, nothing else. Sad, but this is the expectation as far as I can see. - I was not fortunate to benefit from big bonuses or company selling.
While I had friends in the industry who received bonuses, 13th and 14 monthly salary, and even a whole yearly salary bonus, it never happened to me.
Experienced a long awaited exit event, but management refused to share despite commitment.
The fix — have bonuses and shares/options in the contract with full conditions. - Not insisting on receiving feedback from managers about how to improve and what to work on in order to move to the next level.
The fix — insist on weekly feedback on 1:1’s. This also fails often, when managers admit they do not know how you can improve, have lack of interest or managerial training, or avoid giving honest feedback. Requesting feedback from colleagues might give hints, but they are not the ones measuring you and might also not have your best interest in mind.
Why am I sharing this? Because despite title changes, I am doing the same job I did when I started.
Perceived progression
Promotions in management roles are tangible: you have a self explanatory title, more reports, more authority, more responsibilities, higher level decisions, you’re exposed to more information and the compensation is higher.
ICs rarely take part in external workshops, but ongoing workshops and training for people in management is quite common.
The IC path, in my opinion, is a bit of a scam. It exists to give a false sense of progression. A softer description would be an artificial progression.
Organizations either introduce few levels which are hard to advance, or tens of levels in order to give this sense of rapid progression. It is usually tied to improving certain predefined capabilities and might result in salary increase. But neither the areas of responsibility dramatically change, nor the authority or influence.
It does help ICs to grow, but this was available before, with the single “senior” or “tech lead” level, where the expected improvements were part of the performance review and hopefully the continuous feedback. An official ladder only formalizes it, but sometimes in vague expectations and descriptions, which are subject to interpretation.
When someone new joins the company, how do you know in which level they are? It’s probably quite easy to know whether they are junior, mid or senior, but how does one judge the level of a candidate? And once it is set, can it be corrected in case it was wrong? Both to demote or promote?
Also, the ladder is internal, so a “principal engineer” in one company might mean the topmost level, an IC that is parallel to a VP, but in another company it is one level above senior.
Moreover, some organizations have no means to support professional growth, for example, if they are not growing or too successful, and they use a limited technical stack. In these cases, I believe, employees don’t even gain experience, but rather repeat the same year of experience again and again.
Why it’s common to hire a manager and not promote internally
- Dunning-Kruger Effect —you’re not as competent as you think you are.
If you’re not doing a great job currently, even though you think you do, why would you be promoted? If you were to be promoted, how could you lead and mentor reports who do better than you? It is also challenging to receive honest feedback from managers, therefore, hard to improve. - This goes hand in hand with the Peter Principle — people are promoted to their level of incompetence. Assume someone is doing great, then they are promoted after a while, they do great again, and promoted again, but then, because the required skill set is different or for other reasons, they don’t do a great job, so they are not promoted, stuck in their level of incompetence.
- Unfamiliarity bias — an external unfamiliar candidate is better than the current employees, whose weaknesses we’re already familiar with, even though management could try to work on them.
Why it’s common to promote less competent people than yourself
- Again, maybe you’re not as good as you think, or you are very competent, but have zero leadership or people skills, and the company does not invest in them before reaching leadership positions.
- Promotion is done based on time.
Someone is maybe doing a worse job than you, doesn’t care as much as you do, is less knowledgeable and maybe has no desire to manage, but they are already working for 4 years and it feels about time. This is how the employer signals that loyalty pays off. - Wrong culture.
Culture is not the team events, ping pong table, fruit and drinks. It’s the values, and it should be reflected in promotions — employees who demonstrate the desired behavior should be trained for leadership and get promoted. Very often this is not the case. I have seen many cases where it was based on friendship with the current manager, a shared hobby, being someone’s nephew or telling jokes over lunch. I also witnessed cases of promoting the employee with the highest academic degree. - Not being a politician.
It’s naïve to think that just doing a very good job is enough. You need to find communication channels with the manager, demonstrate what I can refer to as ”not being too nice” attitude, which is often perceived as a requirement for management. In essence, someone who does a worse job, but has another attitude or makes right moves will be promoted.
Why no one is promoted
- Budget.
Management roles are paid more, so this could be a motivation. For example, a team lead leaves, but no one takes his place, neither externally nor internally and the team “gets by”, probably when one of the team members is more dominant and is the implicit lead. - Moving from teams structure to chapter and squads.
Some companies prefer to have chapters, that is, a base team of engineers, could be between 4 and 15, depending on the company size, managed by a single director or engineering manager. This team works on maintaining the products. Whenever there are projects or tasks, squads are formed, that is, some members are grouped and one of them is the squad lead, which is not a managerial role. After the task is done (could be weeks to months), the members go back to the chapter.
In this structure, there is no need for managers except the directors who lead the chapters and are responsible for the chapter’s members. - No one is good enough.
None of the current employees is good enough, and all external candidates failed to impress on interviews. Heard stories about unmanned roles for a year because of that, while in the meantime someone is actually doing this role implicitly within the team, or one of the other managers takes over.
Why should you become a manager anyway?
Not everyone has aspiration to manage. Some prefer to remain solely on the professional track. Some want to focus on things outside of work, so they feel comfortable not growing. Many suffer from the imposter syndrome. Many prefer to not handle humans, and that was part of what drew them to this field in the first place. Some might not want the responsibility and want to sleep good at night. Whatever the reason is, it’s totally legitimate, and the IC path is an exciting option.
You should become a manager if you have, or later discovered passion for leading, mentoring and having more impact and responsibility.
While some can be criticized for wanting this for the social status and higher pay, this cannot really be ignored. The compensation level is completely different — higher salary, stocks or options and bonuses, and can significantly improve the financial status and retirement.
You should not be afraid of it. Almost no one is born a manager. You can read a lot and train the skills, but nothing is like trying it for real. Worst case — after some time, if you feel it’s not for you — you go back to the IC track. There’s no shame or failure, it’s a choice.
Alternatives to both IC and management paths
Here are some ideas if you feel both career paths don’t fit you, or if you’re an IC with no managerial role in the horizon. Each of them has different pros and cons, responsibilities, constellations, required skill set and learning opportunities. Depending on your ambition (mentor, improve pay, change the world, get recognition, etc.), you could:
- Start your own company
- Have a side project
- Contribute to open source projects
- Consult
- Freelance
- Write articles and books
- Give professional talks
- Change profession altogether
To paraphrase Churchill, maybe it’s like democracy — it’s not great, but better than the alternatives. Just think if it’s enough for you.
