Where do individual contributors go once they peak?
tannerchristensen.com
tannerchristensen.com
In software this is very often not the case. A 55 year old still fluent in hot tech and a lot of strategic work as an architect, interventionist, mentor to younger devs, etc and who can demonstrate all that in their resume will probably do ok. A 55 year old who is "just" a coder will often have a rough time (vs 28 year olds getting actively recruited 5x/week).
In other industries, like EE where I also worked for several years, this is much much less true. Very senior ICs are highly valued and it is common for teams to be a blend of engineers from fresh grads upto near-retirees.
To avoid ageism while being an IC you need to find a job in a niche where the domain is CS and/or ENG based (as in embedded, aerospace, or even relational database engines) and these jobs are far and in between.
Beware: jobs like Facebook seem to be CS based but they aren´t (that´s why their programmer average age is 27). The CS problems they have are due to arbitrary complexity and they are short term. Companies like these are media companies.
I’m 45, still an IC mostly but my next role whenever I decide to leave my current job, will probably be working for a consulting company. Currently, I am “more equal than others” and have more influence based solely on my “relationship and expert” power.
In the cloud consulting space or the generic “digital transformation” space, you have a few customer facing consultants and lots of low paid people doing the grunt work.
I am not seeing any shortage of openings for either “principal software engineers”, or architects. Of course, I’m staying away from the west coast. The major cloud providers and their partners are hiring in most major cities as long as you’re close to a major airport. I happen to live near the world’s busiest airport.
I could just as easily claim that coders who refuse to develop new skills and keep up with a changing environment will eventually find themselves sidelined, due to their inability to adapt to changing needs. Since most of those middle aged people started programming 30 years ago now, they then move into environments where the technologies also haven't evolved in 20-30 years: embedded, aerospace, and dated DB work.
This doesn't preclude people who can evolve from keeping up as mostly-just-coders in a changing world. Calling the complexity inherent in something like facebook "arbitrary" as opposed to the complexity in embedded work as innate just implies that you don't understand the "CS" problems that Facebook (or similar) deal with, and I can imagine that a company like Facebook might not want to hire someone who, for whatever reason, is unable to accurately analyze the complexity of their problem space, especially at a more senior level.
Please answer: do you think aerospace, embedded and relational DB engines is dated work that has not evolved?
And calling modern app development's probelms " due to arbitrary complexity and they are short term" isn't?
I do think that much of the aerospace technology industry uses dated methods. Same with much of the embedded field. There are certainly places that, for example apply modern best practices to embedded work, but most of those places are the exact same things that you're writing off: Google, Facebook, etc. Have embedded projects that follow best practices.
Focusing on aerospace specifically, I know of plenty of people who work in aerospace and don't use version control. That's plainly unacceptable. And I'd argue that the problems encountered there are much more self-imposed than at a Facebook.
Db engines again depend. There's a number of really cool modern relational database work, but the places where it happens (postgres, Google, cockroach labs) aren't places where someone who isn't interested in self growth are going to succeed.
The tl;dr here is that the impression I get from your comment is that you're describing a developer who let their skills stagnate because they learning things one way and don't want to keep up with changing processes. The fields you mentioned are fields that have such a stigma attached to them, and not unjustly. It doesn't apply to every person or project in those fields, but the people it doesn't apply to would succeed anywhere anyway.
I've encountered engineers older than me who are just as excited by new technology as I am and are willing to learn about it and offer their perspective and wisdom as to how its different from what they were used to before, conversations which I find fascinating.
There are also those who I will call less-enthusiastic about the changes; and quickly get overwhelmed by change and either move into management positions or into roles or companies with less change.
I don't think there is anything fundamentally better about one kind of engineer v/s the other. The problem is only when you place an engineer who enjoys the change in a role that doesn't involve much of it, or vice versa.
There is a flip side to this, as some (many? most?) excellent ICs either become poor managers, or hate the job of dealing with humans, or (frequently) both. This is well known and many companies actually want and support top ICs who want to stay ICs with significant freedom to choose projects, generous (time, travel and $$) conference budgets and other perks.
Thus at least some ICs do not go anywhere after they peak (hopefully plateau), which can be a good place to be. But sooner or later they will likely be working under one of their team members whom they did not think much about (who may just be better with people than with technology). This is not a reason to lose any sleep; just something to keep in mind. My 2c.
What’s the difference? Think about when a project fails. “Bad things” happen for the person accountable, whereas the person responsible can move on to the next project. The buck stops at the accountable individual not the responsible one.
In practice, every project has a manager that’s accountable and a lead that’s responsible. As ICs move up the ladder, they’re able to lead larger and larger projects and offer expertise and guidance across multiple projects. Think: providing feedback, from hard-fought past experience, on a design doc that’ll save a team 3 months worth of effort; architecture review, etc. Essentially ensuring and instilling engineering excellence across the organization.
One thing to note, moving up into a senior engineering role may mean you’ll be coding or designing less. And that’s to be expected. Senior engineers understand that coding/designing is one portion of a larger picture that includes communication, eliciting buyin, documentation, architecture, software quality attributes, and many more responsibilities.
In theory, this provides equal management and IC tracks that are fulfilling to all. In practice, very few companies work this way, but there are some out there. And when you find them, you won’t want to leave because it’s such a pleasant experience.
* They descend on random design docs to demand changes, based on vague pattern matching to a problem they faced 5 years ago.
* They don't have to do any of the work to implement those changes, of course. My team has to, and we have to defer to their opinion that changes are needed.
* If the changes they demand end up being really dumb, and hurt or kill my project, they can't be held accountable. Not even when it's a recurring pattern, since every corporate metric will show that the project team are the ones who messed up.
Maybe our disagreement is less severe than I'm thinking, since I also wouldn't agree the IC model at e.g. Google works like you're describing. But separating accountability and responsibility is in my experience an unmitigated disaster.
Top ICs work together with ICs that represent their teams, so that they can make informed decisions. They are up to date with technologies (this must be an obligatory requirement), code regularly, so they are much better then managers to make efficient company wide technical decisions, own the architecture of the whole system or large parts, organise and overlook large and expensive engineering initiatives, drive prototypes and research projects. They must me accountable for being up to date, understanding the consequences of their decisions, getting feedback from managers and engineers - not turn into “astronauts” in some years.
I think ICs should go in parallel with engineering management in the reporting chain: the top IC reports to CTO, next level reports to directors, etc. This ensures that IC’s scope of responsibilities is expanding and they have better visibility and power.
That’s how it works at IBM. I’m the “responsible” party and technical leader for a couple of teams working on related projects. I report to a program director who reports to a VP. My peers are line managers and other senior tech leaders. Part of what’s great about the team that I’m in is that we ha e clear talent pipelines that show how you can matriculate upward in design, engineering, or management, and that a “band 10” of engineering is equivalent in scope, comp, influence, and autonomy to his or her manager equivalent or design equivalent. That extends into the executive ranks as well though it’s more common to find people who hold dual roles of VP and Fellow or Director and Distinguished Engineer or Distinguished Designer.
My experience says that ICs are best embedded in the team to deliver working code with patterns that are conceived from exposure to the real problem being solved.
I feel like one of the worst things that can be done to engineers is disconnecting them from the problems being solved.
Then, by definition, they wouldn’t be an “embedded” engineer, no? In fact, what you’ve described is not at odds with what I’ve described.
I’d like to hear more on your thoughts about Google’s IC track and implementation, especially if you’ve worked there. Care to provide a compare and contrast?
At Google, high level ICs seemed accountable by most standards. They couldn't just abandon projects when they became boring, they got in trouble when their projects didn't work well, and the weird committees (which admittedly did exist) generally felt like guideposts more than obstacles.
On moving up the ladder while staying an individual contributor -- IME as one becomes the tech lead of larger and larger projects, the "tech" part shrinks and "lead" grows and the setup has a constant forcing function into a "manager in all but a name" setup. One might resist, but this is frequently a pretty hard push.
Your second point is spot on. A natural tension arises as ICs move up the ladder, and if one values being an IC, then one must maintain their boundaries.
Depends on the org and company, to be completely honest. Sometimes, management and leadership have little true accountability and that ends up falling on ICs. Projects fail and senior ICs are blamed instead of management because they were "responsible for the implementation". Accountability without responsibility or vice versa often ends up in failure.
At some point, I simply cut and pasted the paragraphs of my performance self-reviews and actions for growth from one year to the next and told my manager: “WYSIWYG, you know what you can expect from me, you know I’ll learn anything that’s needed for the job, and more. What more needs to be said?”
And that was the end of self reviews and we all lived happily ever after.
Personally, I don't think it's necessarily a bad thing when IC's who max out their value writing code transition to other things. I agree not everyone makes the transition successfully, but it's a great opportunity for personal growth, and the potential for upside is high, since an organization can gain a leader with very nuanced and deep insights into product + market.
It might be that I see this from an engineering perspective and that "the market" and stockholders wont notice in the short term until the brand gets a quality reputation in 10-20 years from user hearsay.
Managers on the other hand seems to mostly have the duty of fighting fires and putting out fires - with the most important quality of not litting fires themselves. There is no way a great engineer working as a manager have time to deal with deep proactive technical issues where I have worked.
For engineers, at least in larger tech companies, there's often a tech career ladder that runs parallel to the management ladder where you can have salary and responsibility growth as an IC without managing people. These ladders usually top out at a "distinguished engineer" or "fellow" level that's roughly equivalent to being a VP.
EDIT: added clarification about company size
Ok. That's great. How about the small product companies that have like 20 or 200 engineers as opposed to 2,000 or 20,000?
I have worked at and worth several companies which purport to have this parallel track. In practice there seems to be much less need for senior engineering and much more need for senior management. There may exist a parallel track but there aren't many positions on that track.
1 VP per
8 directors per
64 team managers.
So, how are there more openings at higher levels?
1) in those 8 person teams you mention there may not always be a place for an expert IC
2) companies often reserve the IC-expert budget slots for internal IC promotions while relying on management slots on external recruitment to a higher degree
Additionally, it can be easier to transition to an equivalent or higher role from one company to another on the management side. Most companies are open to hiring a VP from outside but often the highest levels of IC roles are only filled by those with significant experience within the company.
The knowledge and ability to do tech work is great, but many jobs require that AND some other skill set (sales, research, communication, people management, etc). Those jobs also tend to be very well paid.
In places that allow senior non-manager ICs, those ICs are determining what to do. The managers are figuring out who and when to do it, the ICs are going to figure out the details, tech ordering, research, etc.
Usually the way it works is I'll identify a large scale problem, work to quantify it, cost it out, work to find the manager who is most appropriate for it. Work with that management chain to further quantify cost and benefit of fixing the problem. We'll get high level resourcing and prioritization for the work. I'll get going on deeper research, role needs, design docs and v0 implementation. Manager will get going on hiring. At some point I'll swap from driving everything to doing, and just lob prioritized tasks to the managers. Essentially I'm working as a Product Manager and IC coder at this point, eg I'm saying what we should be doing (PM) and doing the work. However at this point the manager is actually setting sprint task level priorities for me. So weirdly the work goes PM (me) -> SDM (mgr) -> IC (Me). At this point the SDM will usually have hired some other devs or a PM and we just fit them into the flow. At a certain point I'm really just a Lead on the team while we groom up a permanent lead. Or if it's a longer project I'll stay in the Lead role for a year. The manager, PM and I are all working together. I don't have to manage anyone but I do a ton of mentoring and product work and communication.
They asked me a while back if I wanted to manage people (manager came from where everyone here seems to be coming from). But when we discussed it they didn't want to lose 30% of my time to management duties.
A highly effective manager will be able to delegate large parts of their perceived responsibility to others, which is how they get to 100% productivity. Same can happen for managers.
Some call it managing up.
Not every company actually defines a role like this (mine doesn’t), but it is a role every healthy large-scale company needs.
And what were your feelings on the matter? You make it sound like "they" decided you would not go into management, regardless of what you wanted.
I find when you're working well with your management then things just happen and there isn't much fretting or arguing. In fact I have to often call out distinctly "are we all clear were making a decision here." And then we just move forward.
If you are an amazing IC, but can’t/won’t help others grow to that level, you are only so valuable to the company - hence the IC ceiling.
They usually have enormous technical debt that elite engineers could disentangle.
Doing so will not be recognised nor appreciated by management.
That one month project could probably be split in to 5 smaller but still meaningful ones.
Agreed. It should be part of the normal workflow and not much talked about.
Heck, even other devs don’t see technical debt as problem. It’s more of a political problem, less technical.
I mean this as a message of hope, not a quibble!
I'd say tech debt is more like a special VAT applied to your current actions, whereas regular debt is proportional only to your past actions.
Unfortunately the economics doesnt play out like this. Whether you have technical debt or not, the stack will get a rewrite every now and then because thats how senior ics will like it or will get promoted because of it. I have seen lots of infra churn that went over budget, didnt result in the impact it claimed, and so on.
Technical debt is overrated.
(Yes, technical debt is often overrated, by young engineers unused to maintaining hairy code. But when it builds up over several years, it can add up to a real problem.)
Meaning... When you choose your debt reduction strategy, you cannot go 0% debt. There will be investments you can do, like increasing deployment velocity, adding monitoring and so on, but refactoring that ugly god object may not be the greatest idea.
Ugly code which is locked away in a module isn't a big deal unless it's a performance problem or bug magnet. I wouldn't really consider that stuff debt, though; if it's not impeding velocity, you're not paying interest on it. Technical debt which has a noticeable interest payment, that's worth reducing.
Sometimes the interest cost isn't obvious. E.g. the UI might be written using some framework which is 5 years old; it might be reasonably clean internally, but the payment comes from developer churn and lack of appeal to devs (whether current or pending hire) wanting to keep their CVs up to date. That cost is real, yet it's imposed exogenously, not because of any deficiencies in the actual technology.
This is part of my point. The eng could have spent 6 more months on making that UI even better, only to have another eng rewrite it in 5 years because... why not.
Most places I gather the non-technical people in charge assume they don't matter so they're basically left as fodder to appease dev leads and make them feel important/creative.
Unfortunately, companies do promote short term gains. Promo cycles are 1-1.5 years long for most companies, as a result people tend to optimize for launching. For managers, in FAANG, that seem to go around # of people that report to you, so they optimize for that.
For a business, there's less incentive to do that investment. You need _some_ investment to keep it long term, but you don't need to put your 100% to make it work. It also comes down to VP of Engineering or equivalent in an org.
Not overdoing technical debt is key. It's a means to an end, the end goal is still $$.
You can always cheap out and get it done slightly faster and slightly cheaper. And you might not have to suffer the consequences. But someone down the line likely will.
E.g. we recently had to install a cleanout for the sewer mainline in our house. Apparently when they built the house, they did everything but install the final above-ground cleanout - instead they just capped it off below ground. The other work, except for the above ground part, all had to be done for testing purposes anyways. But by not installing the above ground part they managed to save something like $10 for each house they built. But now, instead, I had to pay a company $1,200 in labor (they spent all day digging) to install a $20 part when our sewer backed up.
I work in a codebase full of bad, willful technical debt like this. "Let's just do it the easy way" - despite the "hard" way not being harder, just more different than they were used to at the time. Or hard coding things despite being able to derive it from other information - "we can do it later" - good luck, differences creep in and you will spend weeks or even months figuring out all these minor differences and whether they are on accident or on purpose.
6 months down the line, that easy way is completely fucking us up. Certain changes that would have taken an hour take days. And it was completely predictable at the time.
In a similar analogy to yours, most of these systems tend to cause outage somewhere, which are then usually patched on the fly. Depending on a project, shipping fast is usually more valuable than not shipping it for a year. From my pov, i used to be in advertising, and not releasing a billion dollar feature for a year would, by definition, cost a billion dollars a year. If it explodes after releasing, you are still better of by a huge marging because outage would cost much less. Once you have the business going, you can spend money and manpower on the problem, too.
I think this is key: "Hard way not being harder". This depends. Engineers like to overengineer, and without proper supervision they tend to favor technical excellence over business usecase - it needs to be a balance.
On the house example, i bet the value of your house still increased, and the 1500$ you paid is irrelevant in the grand scheme of things. Just like business & rewrite.
Overall, don't get me wrong, I like to use my best skills and put a shiny design out, but i don't do it because I favor doing "good enough".
I can clean up any mess better than most, and I actually enjoy it.
To me refactoring is the design process of modern development. First you write the working code, and then yo design it. Except most people don't bother with the design part, and get dragged down by their atrophied systems.
If you do it right, this also scales well. If you can help a hundred people do their work 10% more productively, that is also more effective than helping four people do their work 50% more productively. Most tech companies that have separate engineering-IC and engineering-management ladders try to keep roughly similar expectations at each level about scope/breadth of impact, it's just that for engineering management, it's "how many people do you transitively manage," and for the IC ladder, it's not as obvious.
I think this article does address that by pointing out that the design management career track generally expects you to manage both increasing numbers of people and increasing amounts of work, and those don't need to be the same thing:
> Overlapping responsibilities between IC and managers is the most prominent issue I’ve observed, but it’s an easy one to resolve by looking at where the line is drawn between people and product on the team.
(This sort of reminds me of a similar problem in academia: there are three separate skillsets, doing research, leading researchers/scaling a research lab, and instructing students, that tend to be conflated into one ladder. They don't need to be.)
No better way to spread your skills to the whole team.
He has way more impact than any individual manager. If you want to have a huge impact at your company as an IC, solve the higher level problems that both you and your fellow developers are having.
Can not be customer satisfaction (by quality) or employee happiness or retention.
I wonder what those other metrics are.
A big one is that managers are de facto judged by the size of their team (and, for more senior ones, the size of the tree underneath them, too). It seems to be really, really hard to have middle management in an organisation without "maximise headcount" becoming an unofficial goal.
Edit: Employee happiness is an interesting one here. It's quite believable to me that being seen to cut down a few tall poppies might have a positive impact on (mean) employee happiness in some cases.
> It's quite believable to me that being seen to cut down a few tall poppies might have a positive impact on (mean) employee happiness in some cases.
This again... I dread to imagine going through the day around people that think like this. But people that think like this exist, and I imagine they concentrate somewhere. If some place makes them happy (and everybody else unhappy as a consequence), you'll probably find them there. This is really believable.
I'm a manager and I have a member of my team that does exactly this. They have built tools and process that has allowed everyone else to be more efficient. Anyone on my team can, but they gravitate towards it. It's up to a manager to make sure they are paid appropriately and make sure that they are given space to actually do this type of work.
I definitely think tools can have a lot of leverage, and an experienced IC could easily develop a tool that would save time for the whole team. And I've seen it happen.
But IME this is the exception rather than the rule. The experienced engineer usually gets the credit for building the system with the tool (for which it was essential), but not building the tool itself. The tool is considered useless until someone has proved it on a important, shipping project.
However, that linear multiplier doesn't mean jack in a world where technology can create exponential leverage. I'm pretty sure on a given day, the potential for a single or small set of individuals (without any centralized management) to produce products and systems that change the world is higher than any day previous.
That is why you see tiny hedge funds doing well, both for finance, quant, and tech workers.
In general I don’t think there is anything wrong with “peaking” at a point in your career where you feel fulfilled without feeling pressured to always take on more responsibility and stress. If you want to lead projects or manage people, go ahead. If you just want to write code, that’s fine too. Of course depending on the company your compensation might top out after a certain point, which you may or may not be happy with. But at least in the bigger FAANG-type companies, you can go pretty far as a “tech lead” style of IC, without directly managing people.
So true. Especially after having a kid, I'm dreading any further promotions above the usual Senior. I'm happy at the level I am for the last 5 years and don't see why I would suddenly want to spend more hours in meetings and be held responsible for more things?
I make “enough” now to meet my short and long term goals and have a great work life balance. Why shouldn’t I just focus on keeping my network current, my resume up to date with in demand technologies, and within the next two or three years when I reach my ceiling, be happy with cost of living raises?
I’m looking at the next level. Management doesn’t interest me. I’m really not interested in the travel requirements of consulting and we are good. I could easily see myself doing the same thing I’m doing now using whatever technologies are trending then at my current company or an equivalent.
But, on the other hand. I might get bored out of my mind and move to consulting just for new challenges and the extra money would be nice but not necessary. A regular old Enterprise Developer in Atlanta can live a good life - especially with dual incomes
Can coders who are limited to a single team, without exposure to a big picture, not experienced in business communications, specialists not generalists do it?
Can a director of engineering, who is busy with people management, meetings, plannings, work allocations, who can barely keep up with latest technologies, forgot when they coded last time do it properly? Do you want VP to decide what language or platform to use across the organization?
It is just my opinion and some experience, but I think there is a proper set of responsibilities in many tech companies for such leadership roles without people management, like tech leads on steroids, they can be called architects, principal engineers.
Roughly, 20-30 percent coding, the rest on communications, coordination, designing, mentoring, researching, solving tricky problems, with career progression in the scope: single team -> department, area -> whole organization.
Working on complex problems requires collaborative effort, which can be immensely gratifying not just intellectually but also emotionally (humans are social beings). It is strange to see a warped restriction of the concept of collaboration down to each “individual contributor” doing what they’re assigned, and ignoring the other “hats”. That formulation never allows/imagines a chance for the whole to be better than the sum of its parts.
So, once it all plays out, in a healthy organization, the IC/manager dichotomy seems somewhat counterproductive. I can't say I have a better alternative for larger organizations, but for small teams and startups, I highly advise disbanding it and staying small for as long as possible to avoid it from being forced upon them due to the surrounding culture.
I agree with the sentiment that a dynamic, role based method for delegating responsibility seems incredibly attractive. If you haven't seen it before, Turtleocracy is really interesting (not just directly, but at a meta level as a way to design social systems for these problems) https://www.notion.so/Turtleocracy-47a6df7692bf4e95a39504a73...
Still, in practice, these growth opportunities can seem far less common than yet another senior full-stack dev position. If you want to work with scale, there's Google, Amazon, etc., but most companies don't really need to engineer for scalability and high availability. They just need to ship some CRUD features yesterday.
At some point, it's worth considering whether it's worth the costs to keep pushing up in career for more interesting work, more money, more status, whatever.
StrengthsFinder 2.0 from Gallup
But over time I have seen my role change in many ways though: I started as the stereotypical IC, slinging code and did that for a long time. Almost at every level though, sooner or later I ended up with almost full ownership of whatever I was working on. That meant I kept growing in levels and I am where I am right now (Uber tech lead for all data analytics infrastructure at snap).
My current role essentially takes up 10-15% time for company level arch/design reviews, 10% time on interviews, 40% time on preset meetings (scrums/team design reviews/planning/post mortems), 20% time on operations and about 15% time for coding. So pretty much all coding I do is in that tiny sliver or outside office.
I am pretty much a part of all meetings my manager peers are a part of - except for their people commitments. The main differentiation I see between the IC role and managerial is that I don't have people reporting to me. I also don't have to be in ALL the status reporting meetings / managing up etc.
There are definitely times I want to put my head down and get some problems solved, but it usually comes at a cost. So I find some or other engineer to task it on and watch it done most of the times. Rest of the times I don't sleep :)
It is breadth heavy because snap is still a small company in terms of # of engineers. My equivalent role in AWS was a lot more on the building side (50-75% went into building stuff and rest for ops/interviews etc.) because it was a depth position. I did choose this after 13 years of depth roles, it has been quite interesting so far! The biggest advantage I bring is that I can pretty much fix anything in the system and make changes in any component, assuming the dev is not available. I also keep the full stack in my head, so serve as the initial litmus test for new proposals.
I see a bit of misconceptions about pay (I do get paid in the same band as my level to next level give or take bonuses/stocks etc), ownership (My ass is very much on the line for our data quality), responsibility (my managers share the responsibility in a different way - they will get a team member on things that need done and refocus. I will jump in myself if that doesn't work) etc.
I like the freedom. I do like the fact that I can be socially aloof (I am usually friendly, but my friends are outside work) and still get things done. I prefer not to worry about others personal lives (from what I see, this becomes inevitable for managers). I definitely like not having to deliver reviews (I am still a part of the process).
Feel free to ask me any questions.
Hear hear! There's still so much to learn - I've been coding for nearly 30 years, and there are entire domains I've hardly scratched the surface of. And now I'm actually getting a chance to apply AI techniques to my day-to-day work!
Here's my measure for "meaning density" in article. "How many sentences did it have" divided by "How many distinct points did it make"
this is one of these "lightning rod" articles, where nobody upvotes it because the article itself is good, but rather because it talks about something they are angry about and agree with and want to debate.
You are paid to produce value. If you continue to focus on producing value as an individual, you have to reasonably expect that your compensation will eventually reach a limit.
Let's not kid ourselves, the ladders are never equal, and a senior ic level doesnt translate well to another company. After l7 and above, the skillset is only mostly recognized within the company.
Setting aside the fact that most companies don’t have this, here’s a protip: count the number of engineers at each tier. People don’t get automatically promoted to l7 just because they spent years grunting at l6. It scales with impact, and opportunities for impact as an IC are fewer and farther between than for managers.
Some ICs are not really architects but work on tiny scale on critical bits. There is often some fractal quality to their work and the tiny structures are reflected back into the organization.
Some ICs have come up with patents - the foundation for building businesses with a profitable moat around them.
Last but not least are ICs role models and can have a large impact on the development of other individuals.
It is often not easy to find a way to impact the organization on a larger scale but it is possible. I think the I in IC is not helpful.
There kind of is, though. If you’re lucky, once you hit mid-40, you’re with a company that will be able to keep you on/stay in business for the next 20 years until you retire, because job hunting as a middle-aged “IC”/non-managerial is… unpleasant. I’ve been involved in several hiring committees where (managerial) types would look at a resume and say, “this guy’s been doing this for twenty years and he’s still ‘just a programmer’? Ugh, next”.
A-Management.
B-Consulting.
C-Stagnation.
D-Endure a string of jobs where they are mobbed because they are seen as a threat until they retire from the industry.
E-Continue working as an IC, satisfying their intellectual and financial needs.