beyond senior - the ic misnomer
src: Beyond Senior – The IC Misnomer - 2022-09-05
Abstract
It should be no secret that my opinion is that there is no such thing as a solo engineering role. Inevitably we’re all part of a much larger engineering community and no one person is capable of doing it all.
The strongest engineers I know are the ones that can admit this early, and the weakest are the ones who fight against it and find themselves hitting a brick wall right around the senior level. Collaboration, politics, and communication are essential to any level, especially beyond senior.
That’s why whenever I hear roles beyond senior phrased as individual contributor I find myself thinking that it misses the point, and sets the tone for heroics rather than collaboration.
As a community we should address this misnomer, and grow together to find more sustainable solutions to growth.
The IC Misnomer
When looking at job tracks for engineers you’ll likely see one of a few:
- IC (Individual Contributor) - The technical track
- EM (Engineering Manager) - Going into management, some project management
- TL (Tech Lead) - Semi-hybrid, focused on project management with tech
Typically only the first two, IC and EM, are considered official roles. Tech lead at most places I’ve worked is an unofficial title, and tech lead managers are a more rare role doomed to failure for trying to do it all at once.
Within IC you’ll see a leveling system which looks somewhat like this:
- IC L1 - Entry level
- IC L2 - Mid level
- IC L3 - Senior
- IC L4 - Staff
- IC L5 - Principal
- IC L6 - Distinguished
Companies like Block or Google tend to be L+2 of the above, whereas my current role is closer to the above. In any case the title gradient stays mostly the same with perhaps some interspersed “Senior Staff”, “Senior Principal”, or even some really fancy titles around “Fellow”.
Interestingly most of these companies also have large warnings around IC-L4+ stating that it can be a qualitatively different job with very different measures of success. Given that, it seems odd that they’d still be called IC levels.
In fact I would call “IC” a misnomer when one moves beyond a senior level.
The Individual (IC)
Up to mid levels and for a good part of senior engineering levels you will be focused on landing individual tickets and work either by yourself or in small pairing groups depending on your organization’s practices. Most of your assessment will be very heavily based on how you perform as an individual and the value you provide as an individual.
There may be some cases where you’re accountable to the growth of more entry level engineers, but as a formal part of your role this often won’t start taking more shape until senior or above levels.
The Team (TC)
When you’re a senior engineer a vast majority of your focus is at the team level, often as an individual contributing to a larger goal or project. On occasion you might see some movement into technical leadership and being a team lead of sorts which moves this more from an individual contributor to a team contributor.
Your focus shifts from being focused on individual delivery to the delivery of your team, and often you end up pairing with your manager to help drive discussions on how work should be originated, scheduled, delivered, and potentially even negotiated.
At this stage you can be assessed not only on your individual performance, but also the performance of the team around you. This is where the line starts to blur between being an individual and being a part of something larger, and will be a recurring theme as we move on.
The Organization (OC)
Just as an individual is not an island on a team, neither is a team isolated in their wider organization. The role of a staff engineer is where reaching across team boundaries in your organization goes from being an exemplary quality to being an expectation of the role.
To succeed you have to build consensus, communicate, document, clarify, and present on work across an entire organization. If you step back into more individual focus at these levels your effectiveness will be severely limited, as the goal here is to make an entire organization succeed rather than playing hero.
The best staff engineers are great at taking this and delegating out work, and helping to roadmap larger projects well beyond the scope that they could ever do individually. The worst? Well we’ll leave that for another post, except to say that there’s great danger in soloing work meant for much larger groups of people.
The Company (CC)
What a staff engineer does a principal engineer does for an entire company.
They work across disparate cultures, organizations, teams, and more to reach a much broader cultural shift at companies to drive standards and lead projects that are critical to the entire company. They are judged by the success of the company as a whole, and how well they can guide all of engineering to shared goals, and communicate that with executives.
Whereas it’s dangerous to try and solo as a staff engineer it is absolutely fatal to try and do it as a principal.
Does an IC Exist?
No.
In any team, organization, company, or other engineering group there is no such thing as an individual. Even at entry and mid levels you might have noticed mentions of pairing and working together to solve problems. Moving beyond that seniors rely on others to inform decisions, as do staff and above engineers.
No matter where an engineer is at in a company they’re contributing to something much larger, and engineering never was a solo activity. It has always been, and always will be, a group project.
Isolationism
That doesn’t mean people won’t try to run it solo, but such people will often do more harm than good.
Being that engineering is a group activity that requires frequent sharing of knowledge, delegation of work to land larger projects, and the ability to grow others. The more someone isolates from others the more they form silos of information and quickly become a liability to the company.
Sure, they’re very impressive and productive, for a while at least. Give that a few years, assuming they haven’t left the company, and the echoes of those choices will start to reverberate. Code written without understanding others, the product, the customer, and all the related concerns will always be far more brittle and prone to error.
I’ve met several of these engineers in my career, and in every single case after the shine wore off people were stuck cleaning up after a myriad of edge cases and bugs that said engineer never considered while going full hero on the code base.
The Purpose of Teams
One thing a lot of folks who prefer isolationism miss is the purpose of teams, and what makes them productive.
Commonly they would say the purpose of a team is to deliver code as quickly as possible.
I would argue this misses the point. You can move as fast as you want to, but if you’re running a marathon and take off sprinting to deliver on the first mile you’d look pretty foolish for the next 25 and some change miles.
No, the purpose of a team is to deliver code as quickly and sustainably as possible.
We create systems of reinforcement, delegation of work, planning, and other practices to make sure that if any one engineer is missing we can continue on a sustainable pace and deliver on our objectives. If the absence of any one person for 2-3 weeks causes the collapse of a team that’s not a sustainable team.
At one point I’d joked that this sounded a lot like the classic philosophy problem the “Ship of Theseus”:
If you were to replace every member of a team would it still be the same team? Perhaps that will be the subject of a later post, but an interesting idea to muse on in the mean time.
Wrapping Up
It should be no secret that my opinion is that there is no such thing as a solo engineering role. Inevitably we’re all part of a much larger engineering community and no one person is capable of doing it all.
The strongest engineers I know are the ones that can admit this early, and the weakest are the ones who fight against it and find themselves hitting a brick wall right around the senior level. Collaboration, politics, and communication are essential to any level, especially beyond senior.
That’s why whenever I hear roles beyond senior phrased as individual contributor I find myself thinking that it misses the point, and sets the tone for heroics rather than collaboration.
As a community we should address this misnomer, and grow together to find more sustainable solutions to growth.