
Where do individual contributors go once they peak? - adrian_mrd
https://tannerchristensen.com/blog/2019/12/23/where-ic-designers-go-once-they-peak
======
eagsalazar2
Be careful that you are at a company or, even better, in an industry that
isn't rife with ageism and where there is a clear and well defined path for
more senior ICs to continue to develop an age appropriate resume (increasingly
strategic contributions while remaining current with latest industry tools and
practices) that will serve them well if/when they are looking for work at 55.

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.

~~~
gfs78
Not an easy problem to solve. And this is why, given the odds, a career in
tech is probably a bad decision.

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.

~~~
joshuamorton
None of your conclusions follow from your premise.

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.

~~~
gfs78
I find the wording of your last paragraph a little insulting.

Please answer: do you think aerospace, embedded and relational DB engines is
dated work that has not evolved?

~~~
joshuamorton
> I find the wording of your last paragraph a little insulting.

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.

------
ptero
If one _wants_ more responsibility, one has to move to leadership. This is
true in almost every company and work type, not just in software development.

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.

~~~
Denzel
Responsibility vs. accountability. If one wants more _accountability_ , then
you must move to management. Responsibility can and should scale with IC
levels.

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.

~~~
SpicyLemonZest
I'm sure it's a pleasant experience for the high level IC, but from the rest
of the organization's perspective it you're describing architecture
astronauts.

* 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.

~~~
playing_colours
You describe a bad implementation of top level IC. They same way, it can be
someone from the top management who has no clue about individual teams, makes
dump decisions that hurt your team.

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.

~~~
mikehollinger
> 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.

~~~
playing_colours
Exactly, it is similar to my position at some previous company: as a tech lead
I reported to a Director of Engineering who also managed a few engineering
managers. The top IC tech guy - “Chief Architect” reported to CTO.

------
TomVDB
They keep on doing what they love.

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.

~~~
pmiller2
You seem to assume someone has to "love" what they do to be effective. I'm a
senior engineer, and I don't hate what I do, but I wouldn't be doing it at all
if I were financially independent. I'd be doing something I love instead.

~~~
TomVDB
Not assuming, just anecdotally telling what works for me.

------
ereyes01
I think this phenomenon is evidence of the value ceiling of IC work. What is
the point of diminishing returns on paying an IC more money to do what they
already do well vs hiring an additional younger and less expensive person to
do the same thing, though not as well? Of course, an experienced IC can
transition to mentorship, and different companies value this differently, but
that may have a value ceiling as well.

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.

~~~
rightbyte
This is not my experience. It might depend on the field. Unless there is a
"peak IC" doing stuff development stagnate and no matter how much time or
resources is put into something the great results never comes. Things turn out
good, yes, but not great.

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.

------
jonas21
The original article's title is: "Where do IC _designers_ go once they peak?"
(not sure why it was changed on HN), and it focuses mainly on the career path
for design.

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

~~~
AaronM
Based on my experience, it doesn't seem that many companies outside of the
FAANG companies have those kind of tracks. At a small company that builds a
single product, what would a "fellow" actually do that is different than a
senior engineer?

~~~
jonas21
You're right, the company needs to be of a certain size before this makes
sense. But it's not just FAANG -- for example, IBM, Microsoft, Twitter, Lyft
and many others have similar tracks.

~~~
scarface74
People are so stuck on the acronym that think of MS as less of a tech company
than Netflix? Microsoft is much larger than Netflix no matter how you measure
it.

~~~
james_s_tayler
So true. The reply is like "by these other huge famous companies have them
too".

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?

------
pacala
Managers control the purse strings. ICs don't. There will never be equal
status, and it starts with other ICs that won't lift a finger unless it
pleases someone with a fat purse. You can leverage IC star power a little, but
it won't get you too far without a purse.

~~~
Ididntdothis
Very true. Whoever owns the cost center number has the power.

------
mmmBacon
I am a senior IC transitions to management. I think these articles leave out a
very significant part of the equation and that is compensation and career
mobility. Generally the management track at higher levels has more openings.
If you stay in the IC track, there are going to be much fewer openings at that
level with appropriate compensation. This is particularly true the more
specialized your knowledge is. Moving to management track provides more
opportunity at the same/similar or greater compensation. The exception to this
are the FAANG companies but in my experience it’s way easier to get in through
the leadership ladder than through the senior IC ladder. At least that was my
experience in the 2 I’ve worked for. In one of the FAANG I worked for, I
joined as a senior IC but was given a very non-senior manager and was
effectively treated as a junior engineer during the 1st year.

~~~
pmiller2
More openings at higher levels? That's just at odd with how organizational
structure works. For engineers, at least, you need about 1 manager per 8 ICs.
Going up the ladder, you probably need about the same number per level, so: 8
managers of managers per first level manager, and so on. If you have team
managers, directors, and VPs, you should need:

1 VP per

8 directors per

64 team managers.

So, how are there more openings at higher levels?

~~~
mmmBacon
There are more openings for managers at higher levels with the same or higher
compensation than for high ICs simply because there are fewer problems that
have the scope for such a senior engineer. A FAANG I worked at might have a
need in an org for a few director level ICs. These ICs in my experience are
few and far between. ICs at this level make same money as management track. In
my experience not many teams within an org have scope for an IC at that level
Making it more difficult to transfer within the organization. Yet at the same
time there are many director level managers because there are many teams and
lower level managers to manage within those orgs. Additionally, a director
level manager is considered somewhat generic and has an easier time moving
around in the company with things that are tangential to their domain. My
current company is not a FAANG but I can tell you that I see the same thing
there.

------
grogenaut
Many of you are thinking about this wrong.

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.

~~~
thechao
Since I do the same process described here (at a FAANG), I’d like to elaborate
on one more thing: responsibility. Upper management trusts me to do a good job
along the entire pipeline, _particularly_ at the hand-off to the
maintenance/independent-development phase.

Not every company actually defines a role like this (mine doesn’t), but it is
a role every healthy large-scale company needs.

~~~
grogenaut
Very good call-out. Trust is inherent here. Amazon would call it earns trust
and ownership. The role there is Principal Engineer (or really senior sde3).

------
archeantus
Value is all about impact and companies are incentivized to reward and promote
impact. It’s valuable to a company to have a really great IC, it’s even more
valuable to have a manager that can grow their team into really great ICs -
presumably like the manager was at one point.

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.

~~~
redisman
ICs reach a local maximum at some point. Most companies aren't solving
problems that are hard enough to warrant executive-level equivalent
engineering roles (except organizational ie. management of said engineers).

------
Ididntdothis
Most companies have no use for very senior ICs. They don’t have much difficult
work and a lot of managers want to involve themselves in technical decisions
so once you have reached a certain level there is no room to grow. Either go
into management or stagnate.

~~~
BurningFrog
> They don’t have much difficult work

They usually have enormous technical debt that elite engineers could
disentangle.

~~~
tehlike
Technical debt is like real debt. You do it because you want to grow the
business, and you can delay it as long as you can. Paying the debt down doesnt
make the business grow.

~~~
bcrosby95
After owning a house, I feel like technical debt is much more closely related
to building homes and doing remodels.

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.

~~~
tehlike
This is true, but i doubt it was just 10$ piece - they did many of these
shortcuts that probably didn't matter. They probably didn't use the _best_
material on your kitchen countertop, because the marginal value over good
enough is not there.

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".

------
binarytox1n
The problem with growth as an IC is that one person only has so many hours in
a day. The only real way to multiply your impact is to transition from using
your own hours to produce work towards directing the hours others use to
produce work. Simple math shows that your own productivity scales only up to
24 hrs/day while you can easily direct a team of 4 towards 32 hours a day of
productivity and actually get some sleep.

~~~
bcrosby95
This just isn't true. A friend of mine is an IC and regularly ends up making
original tools that solve his problems that everyone else at his company ends
up adopting. The company recognizes this and awards him in kind. He makes
around 1 million in regular salary.

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.

~~~
bob33212
It is simpler to manage a company without arrangements like this. It makes ICs
and Level 1 managers more interchangeable. If you moved the 1M employee over
to another group it would blow up that manager's budget. The more
interchangeable employees are the better for some people in upper management
who don't actually care about maximizing cost efficiency and productivity.
They are maximizing other metrics.

~~~
marcosdumay
> They are maximizing other metrics.

Can not be customer satisfaction (by quality) or employee happiness or
retention.

I wonder what those other metrics are.

~~~
matfil
_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.

~~~
marcosdumay
I was not expecting such a Machiavelic answer, but yes, your explanation looks
quite possible. Indeed, it is possible that the expertise ceiling that goes on
a lot of companies is due to misaligned incentives (plus some dishonesty) for
management. That seems worth taking a better look.

> 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.

------
slavapestov
There are many ways to be an IC. You could just write code all day with
minimal interaction with the rest of the team. But you can also mentor your
teammates or be a technical lead for a component or entire project, even
without becoming a manager with direct reports.

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.

~~~
redisman
> 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.

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?

------
m0zg
Why do we feel the need to "progress" anywhere? I mean, why not enjoy the
mastery of the field, knowing your job so well you can do it blindfolded.
Somehow a welder or a plumber doesn't need to "progress" to "welding
architect" or "distinguished plumber". Yet most of us in tech willingly
participate in a stupid rat race that eventually causes a lot of us to burn
out. You can't make all the money in the world. On my deathbed I'm pretty sure
I won't be thinking of how much more money I could have made. In fact I won't
be thinking about work at all.

------
scarface74
Devil’s Advocate Question: What’s wrong with peaking? I’m 45. I spent 10 years
in “Expert Beginner” mode and then spent 7 years moving between 3 companies
and for the last 3 or 4 going back and forth between a dev lead, back to an IC
to get some hand on experience in some areas I was weak at and now back to an
“architect” or a Single Responsible Individual with maybe a team of dotted
line reports.

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

------
playing_colours
It is unfortunate that the industry seems to stick to only “coder or manager”
framework. There are technical topics and decision spanning across a few teams
or the whole organization: CI/CD, data pipelines, languages / frameworks,
consistency, reusable components, best practices, mentoring, integrations.

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.

------
ssivark
I find the whole concept strange. Why are technically skilled folks boxed into
being “individual” contributors? There are many ways (hats) in which technical
skill can be leveraged to help other people or teams: the person who can
troubleshoot surprises with relentless digging (beaver), the person who
provides technical feedback to colleague (reviewer), the person who has a
broad understanding and can quickly get someone up to speed in a new area or
suggest exactly what to look for (consultant), the person who understands the
system well enough to onboard a new member quickly (teacher), finding new
directions for the org (researcher), etc. All of those are multipliers on the
performance of people and teams, and don't befit the “individual” moniker.

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.

~~~
dpeck
because thats the meaning that we've assigned to the phrase "individual
contributor", its as simple as that. If you don't have people reporting to you
for you to direct in accomplishing the goals of the organization you're an
individual contributor, if you do have them you're a manager.

------
_nalply
And what about individual contributors with a communication handicap? Where do
they go once they peak?

~~~
downerending
That's a great question, and of course depends on the handicap. If it's
hearing/speaking, probably a lot of jobs can be done via "chat", with little
or no phone or in-person hearing required. For limited sight, we fortunately
live in an era of huge monitors. Certainly being blind would suck, of course,
perhaps even more than 20 years ago given the "advances" in UI.

------
Scalanchilis
It sounds like career path for designers has some similarities with software
engineers. I think software engineering can potentially offer a much wider and
deeper set of opportunities.

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.

------
irrational
"Then, a few years into the [manager] job, they realize that they don't have
the natural talent to develop other people. Not only is this a waste of their
time, but chances are, they could have increased their contribution even more
if they had stayed in the [developer] role - a role in which they naturally
excelled. Yet if we want additional income, status or responsibility, most
organizational hierarchies force us into a very different role - instead of
allowing for an entire career of progression within a specific role that fits
our talents."

StrengthsFinder 2.0 from Gallup

------
plutonorm
And then there's me, desperate to get into management. Has hussled for 10
years to make it happen, with no luck. I'm currently sending out hundreds of
CVs trying to get a business analyst role. No interest. Do you know how many
engineers I've seen promoted in 15 years in the industry? 0. None. Had I done
a business degree I'd be well away. I'm so old now that even doing an MBA
wouldn't help me. I'm currently considering getting a super market job because
the thought of going back to programming makes me feel physically ill.

------
SubuSS
I have been an IC for 17 years now (MS/Amzn/Snap) - let's hope I haven't
peaked yet :)

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.

~~~
commandlinefan
> let's hope I haven't peaked yet

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!

------
alexandercrohde
What a dumb article, the whole thing is the title.

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.

------
irq11
There’s nobody making you choose to stop being an IC. If you want (and you
stay up-to-date with the latest trends) you can continue doing it
indefinitely. You just can’t do that _and_ also demand that you be paid the
salary of someone who is leading a team.

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.

~~~
hawaiianbrah
Microsoft pays employees based on level. My manager does make more than I do,
but that’s because they’re a higher level, not because they’re a manager.

~~~
ganstyles
Facebook is the same. Transition to management, make the same pay per level.
It's less about moving for money and more about moving to what skillset you
prefer to use, which I really like.

~~~
tehlike
Ish. There is a ceiling to an ic. Sr dr ic level(distinguished) is probably
it, while an em can go up to svp level.

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.

------
gfs78
Where do they go?

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.

~~~
randycupertino
E - Teaching? A few of my absolute best adjunct professors were retired from
industry and took jobs in education because they loved the field and wanted to
give back.

------
purplezooey
they become PMs and begin the inexorable long decline.

