Pro IC vs Against IC
Individual Contributor roles (IC) have been around in software engineering for some time, existing most prominently in big tech companies. Before they became commonplace, individual contributor roles would only go up to Senior, and even then line management responsibility would kick in. The big tech companies realised that forcing their best engineers to become managers didn’t make sense: they were forcing highly technically-skilled people into a line management role which they weren’t suited to and then losing their executive ability on the technical side.
When people choose to go into engineering, they often choose it because they enjoy building things and learning new systems and tools. In engineering, the technical surface area is so large that it’s not really possible for one person to know it all, so it’s possible for an engineer to spend their whole career as an IC without running out of things to learn.
Beyond Senior there is Staff, Principal and Distinguished Fellow, which are equivalents to Engineering Manager (EM) roles and up to CTO in some companies. Whilst top level ICs are often more technically-proficient than Senior level ones, the real differentiator is actually their ability to influence their organisation to make better technical decisions that lead to lower tech debt, higher engineering speed, higher quality of output and preventing unnecessary complexity.
Whilst we’re talking about software engineers here, we now see the same in data roles, particularly amongst data engineer, machine learning engineer and data science roles. We are also seeing more of them in analytics engineering, but it’s still relatively rare for analysts to have these types of role.
But why should these IC roles exist? It feels like letting them have their cake and eat it. They get to achieve seniority, parity in pay, parity in influence - without having to manage anyone or invest in anyone else… it’s an easy way up.
Forcing technically-minded people, who aren’t interested in managing others, to have their only way to progress as a people manager is a great way to lose them. This results in a revolving door of technical talent who, needing somewhere to progress, will progress out of the door.
In many ways, it’s harder as an IC to work at these levels, as people with grandiose titles who have big headcount under them can throw their weight around more easily - after all, they get a bunch of nodding heads from their own staff in every meeting. A lot of non-technical colleagues don’t really understand IC roles and expect authority to lie with senior management roles, not senior IC roles. When they find out a Staff or Principal technical colleague doesn’t manage a team, they try to find out who their manager is…
Finance, legal and HR don’t have these kind of roles despite being specialisms - why does engineering or data?
While these specialisms do have depth in knowledge (especially legal), the innovation in them takes a much slower pace and therefore it is possible for managers to both remain at the forefront of their specialism and to look after a team.
Their ability to scale their work is much lower than with engineers: managing IS their only way of scaling, for now 🤖.
What business case do we have for these roles to exist? With line managers, it’s clear - we need someone to lead these areas, line manage and be accountable for delivery. We don’t have a clear business case for an engineer that is the same level as a VP.
As engineers can scale their effectiveness massively as they become more experienced, competent and influential (most of us have heard of the 10x engineer), the impact of having or hiring engineers at this level can be profound. The lack of them can result in poor solutions being designed and built, which leads to big problems down the road - big problems with big costs in terms of technical debt, cost of running and maintenance.
As mentioned before, if these roles don’t exist you have a revolving door of senior engineers who don’t want to line manage… these being your most productive and knowledgeable engineers, who you never really want to lose.
Well, if no one is stepping forward to line manage as they have this alternative way upwards, who is going to do any line managing? This doesn’t seem scalable?
This is a genuine concern, but I think part of the problem in the first place is how broad line management is. Line management can be classified into three activities: mentoring, career coaching and Project/Product Management. Product Management is very often now being handled directly by a Product Manager and Project Management is often handled by a Program or Project Manager, too. This leaves career coaching and mentoring in line management, and this is what the “squads and tribes” organisational structure already moves towards.
If you split that again, mentoring is something that anyone who is good at anything should be doing. Staff and Principal staff should be mentoring other ICs from the same discipline, who are less senior. This is also not the part of line management that Senior ICs have a problem with - it’s part of how they achieve organisational influence and scale. If you teach other ICs to do things a better way, then it makes your life easier, as well as enriching their careers.
This then leaves career coaching as the main thing “true” line managers in an organisation need to do. I have argued in the past that this part could actually be done by HR, who end up being gatekeepers here anyhow (then do we need Line Managers at all 🫢). However, if this is really what line managers are left doing and the mentoring burden is shared by line managers and IC, then actually it is possible for there to be fewer “line managers” in an org, and they can line manage at a greater scale than if they had to do all three of the activities above.
So, having IC roles can mean you need fewer hard to hire line managers (EMs and Data team leads are hard to hire and keep around for long), and that they feel more supported.
It also means technical team leads don’t need to be the expert at everything - they have senior ICs to lean upon.
How do we know when to have a Staff or Principal role? It’s much clearer when you need a line management role filled.
Usually, these roles are created by Senior ICs journeying their way up to being that competent and influential/impactful in their organisation (the legendary 10x engineer/data person, the ones you don’t want to lose).
Then, if you’re hiring externally for such a role, it’s usually to backfill one that has moved elsewhere in the org or has left the org.
Occasionally, it can be identified by a VP Eng/Data that a Staff/Principal role is needed, because there is a lack of depth in the team. This often happens when leadership changes or an experienced Senior IC leaves who hadn’t made it up to Staff/Principal yet, but was close.
I can understand the need for Staff/Principal roles for engineers including SWE/DE/MLE/DS, after all, they do that voodoo that I don’t know how to do… but analysts - I can do analysis of my own. Why would I need such a senior analyst?
While the analyst role is intentionally less technical, they have to sit at the intersection of many roads (business, engineering, data). They have to understand the domain/s they operate in, as well as the folks working there do. They also have to know the data and systems to a very deep level, too. Add to this that they need to have great storytelling and good stats - you’re beginning to look at a bit of a unicorn, once you add up all of the requirements. Senior IC roles like Staff/Principal Domain_X Analyst become a way to recognise, retain and recruit the very best analysts, who don’t necessarily want to go into line management.
Think about that shiny McKinsey/Bain/etc consultant you hired last year to do some strategy work. Having a Staff or Principal Analyst is a similar concept, except they have a deeper knowledge of the organisation and its data. If you were to sample the population of analysts at this level, they would be more likely to have worked in consultancy than analysts at lower levels.
Won’t AI mean that we won’t need such senior ICs and we can get more out of cheaper less senior staff and hires? They can use AI to do the difficult technical parts of the role.
Actually, the opposite is true - with AI, senior ICs can increase their productivity even further and reduce the need for less senior team members. LLMs can help senior ICs write code much faster without reducing quality, as they are highly competent and can see if the LLM has made a mistake or done something strange. Inexperienced ICs may create problems when using LLMs which generate code they don’t fully understand. LLMs are already very good at generating code that equates to junior to mid level IC ability - it is doing it in the right context and composition that is more important here, and this is where senior ICs are crucial.
Also, as I explained earlier, senior ICs (especially Staff/Principal/Distinguished Fellow) are there to be impactful and influential across their org, at project/program/whole org level. Giving junior ICs LLM assistance will just increase the amount of code they produce, not their impact or influence.
Briliant take as usual Dave!