Thriving on the Technical Leadership Path

This is definitely not true. There are IC tracks at many companies. I'm over 50, still doing technical work, and I'm having a lot of fun. I was a STSM (Senior Technical Staff Member) at IBM and I'm now a Senior Staff Engineer at Google. Yes, most senior technical folks don't actually spend much time coding; it's things like technical architecture, creating slide decks for the VP's, meeting customers, etc. That was definitely true when I was at IBM. At Google I get do more coding, but a lot of my time is spent helping more junior engineers, working subtle bugs that other people weren't able to do, reviewing code, etc. But people management? Heck, no! I enjoy doing the technical work too much to have to spend time doing people management. I'm grateful that there are people who are willing to do management, since it's a different set of skills, but it's not for me.

I do spend my weekends doing technical work (mostly reviewing and testing other people's ext4 patch submissions, and/or reviewing papers because I'm on various program committees), but that's because I love to do those things.

> 4. Being paid less than the lowest grade manager, is not fun .

At least at Google, and at IBM, it's not unknown for IC's to be paid more than their manager.

> 5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.

It may be different for people doing other kinds of programming, but at least for Systems Engineering, there's an awful lot of value in knowing how the various abstraction layers fit together, and more importantly, understand the business imperatives which drives even the lowest level technical work. (Things like maximizing ROI on storage infrastructure by making sure you can efficiently use nearly all the IOPS which the HDD's in your data center can deliver, for example, is subtle work.)

Also, at senior levels, you need to know how to lead technical teams, and that's quite different from people management. And when I say lead, very often you may not have formal hierarchical power over the people that you need to influence; but instead of you have to pursuade them to share your vision and go along with your plan.

You can find ways of being a technical leader without having a formal role. You can mentor more junior engineers; you can try to establish better coding and test/QA standards at your company. You can find some open source project that you're passionate about, and take on leadership roles there. Maybe you can find a way to contribute in standards organization.

If I'm interviewing you for a job at $COMPANY, I'm going to be looking for signs that you can exhibit leadership, and that's going to be way more important than whatever title that you might have. If you have the title, but you can't demonstrate ways in which you were able to demonstrate technical leadership, the title isn't going to mean much.

> senior principal engineer

you're telling me there's a difference between a principal and a senior principal? this seems like title bloat (non-financial, meaningless compensation)

i think there are just way too many senior engineers and not enough work for them. this title thing feeds into my hypothesis: if you're getting to the principal level and then encouraged towards "senior principal" level, that's an illusion of career progress.

i think more senior engineers expect to carry the sort of intellectual freedom they had as high output juniors forever as they become "organizationally woke elite hackers". that's just not a good way to portray yourself, though: eager juniors like that person once was will do the job at 75% cost, and not try to occasionally wade into politics as this free roamer has empowered herself to (ref. bullet about cross-organizational lubricant type)

i would be extremely wary of portraying myself as an "elite hacker with enough confidence to meddle across teams" because that is about as vanilla as it could be in 2019. instead i would slot in with an enterprising managerial type and basically become his code peon, pumping out his prototypes, giving him the credit where due, and understanding that he's generating the ideas but not the code, so he can't ghost you very easily and (maybe) he'll keep you safe in the event of layoffs.

this keeps you learning new tech and always building, but makes you really valuable to someone with organizational power, so safer than some generic engineer on a larger team.

The list of "What does Strategic Engineering Work look like," looks a whole lot like basic management. Each of these things listed below are fundamentally organizational/resources/personnel issues and except for one have almost no relation to the work stream of an IC which would include actually writing new code, refactoring old code, debugging, etc...:

- Tackling technical challenges that span multiple technical and organizational systems.

- Researching and identifying the problems that could be worked on, a year or two from now

- Ramping up strike teams to help build a thing.

- Looking at the big picture including cultural, product and technical challenges, to help inform choices that would be best for the org, perhaps with a 2-5 year view.

- Forming strategies, writing proposals and pitching them across the company, for new architecture, systems or approaches.

- etc...

Except for developing prototypes, assuming the senior engineer is actually doing that, that entire list are just foundational management/leadership tasks.

You're not making a great case for senior ICs being impactful.

I mean, what you described is one way to deliver senior-level impact for a team.

However, this has a very important problem. Every time you join a team, you have to build up this rapport from scratch. If you switch jobs every few years, you'll find half your professional time consisting of busting your ass to build up rapport, only to have to start from zero at the next job.

When you're hired as a manager, you don't need to do (this kind of) rapport building. You just tell people what to do, and they will build it.