[tytso]

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.

[erobbins]

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

This is the worst part of the whole gig frankly. It's an awful place to be, all the responsibility and expectations but none of the muscle.

[tytso]

The biggest projects span such a wide number of teams and/or departments and/or product areas (product areas at Google are headed by Senior VP's) that you're never going to have someone with the formal authority having either the time or the technical knowledge to run those projects. Even at the department level, the VP will have hundreds or thousands of people reporting to her, and so she's not going to have the time or attention either.

So the authority gets delegated down to the technical leaders, and while it can happen that there will be conflicts that have to be escalated to the VP or SVP level, it's usually because a team simply doesn't have bandwidth to satisfy a request, or are being given conflicting signals as to the prioritization of different projects, and so we need to escalate to senior management to either get more head count, or agreement that a given prioritization will mean that the project will slip, etc.

The technical leaders make the technical decisions, and are responsible for the technical decisions. Management makes the resourcing decisions, and product managers make the product decisions. Usually, it's pretty obvious whose domain a particular decision is in, and as a senior technical leader, I actually know enough about the constraints that I can tee up the question, with the tradeoffs, and then say, "but that's a product-level decision: do we ship with now, or do we slip and so we can add this particular critical feature? Note to management: if you don't like the velocity of the development, we badly need at least 3 more head count by next quarter or we will be presenting you with more Hobson's choices like this."

And that's fine with me; I don't find working with recruiters and negotiating with the CFO for headcount, or sitting in an all day meeting trying to divide up the headcount granted to the department to the various teams. Not having to do that is not "lacking muscle", it's being freed from work that I don't like to do.

[foobarian]

Are you the /dev/random guy? If so thank you for all the countless times I copied it as skeleton kernel /dev code. :-)

[sabujp]

I don't know, did Theodore Tso implement /dev/random? (hint: he's the famous EXT4 guy)

[tytso]

Yes, I'm the /dev/random guy as well as the ext4 guy. I've also been the serial driver guy, and the tty guy (Posix job control was my first large contribution to Linux). I also was on the board of the FSG when we hired Jim Zemlin, and when the FSG merged with the OSDL to form the Linux Foundation. I was the Kerberos v5 TL at MIT, and I served as one of the IPSEC working group chairs and on the IETF Security Area Directorate. Oh, and for a while I was Treasurer for Usenix.

See? There are plenty of ways to be a technical leader without being on the management track. :-)