[vp8989]

I have personally not found the staff/principal level very enjoyable or satisfying. You end up being a hub for the larger team, helping everyone do their jobs. I'm not just referring to the coders.

It's very draining and I resent that the industry classifies this type of work as technical IC work. A small subset of these higher "IC" roles do get to focus on technical IC work, but for most people a staff/principal role is basically going to be that of a co-manager with no authority.

I've been considering down-leveling or getting into some software niche where technical expertise is actually valued and existentially necessary to the business.

[libraryofbabel]

> You end up being a hub for the larger team, helping everyone do their jobs.

This is 70% of my job as a Sr Staff Engineer and I love it. But yes, it does take a certain temperament to enjoy it or find it satisfying. I like collaboration and pairing and helping other ICs grow their careers. And I love teaching, which this role allows me to do in abundance in all sorts of ways. Sure, I enjoy sustained technical work as much as the next engineer - but usually that work is better done by someone else who can use it to learn and grow and can own it down the road. Otherwise it becomes another piece of company knowledge that lives only in my head, and there's too much of that already.

I think there is still a bit of a perception that IC levels higher than Senior are about "Senior but with more interesting technical problems". This is largely false. In most organizations those roles are about empowering other people. You can see this if you read the stories Will Larson's new book, Staff Engineer: Leadership Beyond the Management Track. Done right, it can delivery a ton of business value. Yes, it may be a continuation of the IC track, but it's a qualitatively different job. I think that could be stressed more in career guidance from management or when promoting folks into these roles, so that we don't keep promoting our most effective programmers into jobs for which they're not really suited and won't enjoy.

[AYBABTME]

> I think there is still a bit of a perception that IC levels higher than Senior are about "Senior but with more interesting technical problems". This is largely false. In most organizations those roles are about empowering other people. You can see this if you read the stories Will Larson's new book, Staff Engineer: Leadership Beyond the Management Track.

I think that's _one_ way to do it, but it defeats the purpose of having an IC path. It's basically "ship code while being a lite-manager". There's space for more types of staff+ engineers than "manager-lite" versions of the role.

I'm in a semi rebellion with exactly the description you provide, because I find it's short-sighted. We need to allow these roles to be anywhere along the spectrum from manager-like to purely technical. The best description I found of these more senior roles is that they give you license to build the role you wish to have. Kind of like being a tenure professor.

Here's my own self-defined role definition: focus on exploration and research along with mentoring my peers into becoming the next version of themselves. On the other hand, I have no interest in managing the day to day process; it gets in the way of my primary goals.

[paulz_]

> I think there is still a bit of a perception that IC levels higher than Senior are about "Senior but with more interesting technical problems". This is largely false.

Anyone know of a career path where this is actually the case? Lately it seems like everywhere I turn it's meetings and PowerPoint. Ideally I'd like to keep working on harder and harder engineering problems until I die of old age.

[toast0]

Work on small teams doing hard things. Best if the team is mostly experienced people, too.

Big companies may work on harder problems, but usually with bigger teams and you end up doing a lot more communication.

[zebnyc]

How would you recommend that an engineer network with principal/staff engineers like yourself in their respective companies? Asking as you mention that the role is about enabling / empowering others.

Context: I am going to be starting a new job as a senior software engineer in a mid-size company in a few weeks.

Thanks

[spenczar5]

I quit my job as a PE in AWS, and now work on writing performance-critical code in a scientific context. I couldn’t be happier with the decision.

If you’re considering getting out, I would encourage it. Getting back to working on primarily technical problems, rather than social/communication scaling ones, has been great for my overall happiness.

[wfhbata]

Have you been able to maintain a similar level of compensation?

I started my career in scientific computing, and was paid a pittance compared to what a PE is paid at a big tech company.

I’m wondering if moving to scientific computing is a luxury afforded by putting in time at AWS.

[baron_harkonnen]

It's still quite strange to me that we're at a point in tech where technical skill becomes a penalty.

This is not to say that non-technical skills are not important and often more important, but for both myself and friends "getting paid well" and "working on hard problems" have become conflicting goals.

There was a brief while, at the beginning of our current tech boom where strong technical skills were extremely valuable. What initially attracted me to software was hanging out with some absolutely brilliant software folks working on very hard problems, and getting paid better than anyone else I knew.

I'm perpetually disappointed that after many, many years of honing my technical skills I find that if I want to use them 9-5 I have to choose to be paid considerably less, and scour far and wide to find those jobs. I've now decided that it's best to treat my passion for technical problems the same way I would any other non-work related hobby. Similar to the way that being an avid reader and book lover is nice, but ultimately not that important if you want to work at Barnes and Noble selling books.

[bradleyjg]

This is generally the way things go. That it wasn’t true at some point is the anomaly.

The generalized version is that anything widely desirable about a job other than money acts to push down wages. For example, if a position is widely respected, well most people like to be respected so wages are going to be less than if it wasn’t widely respected. Similarly, if there’s a lot of people that enjoy spending time with children then jobs that involve spending a lot of time with children aren’t going to pay as well as they would have otherwise. See also, games programming.

[hallway_monitor]

After leading a team for about a year and a half, I see why managers get paid more. Simply, it's less fun, especially for someone who likes to solve hard technical problems.

I think I'm okay at leading a team but moving me to a staff engineer position would be better for me and the company and I think my leader knows this. The experience has been enlightening and I have a lot more respect for non-technical managers now.

[spenczar5]

The sibling comment pretty much nailed it. I saved well over 75% of my income as a PE and have more than enough money accumulated, so I'm not worried. My wife works as well, and even though we're in a pretty expensive area (Seattle) and have a child, we're very comfortable.

I get paid $110,000 per year, and have great benefits. It feels like plenty to me, even though I don't save nearly as much anymore.

I agree it's a luxury from putting in time at AWS. I don't think I'd be as comfortable (psychologically, anyway) if I had gone straight to academia.

[lumost]

Curious what a role in non-academic scientific computing looks like. How did you get into the field? what kind of companies have this kind of role?

[spenczar5]

Oh, I work at the University of Washington in the astronomy department - so, definitely academia. I am just classified as “professional research staff,” which distinguishes me from students and faculty.

As I mentioned below, I got into this field by emailing a professor out of the blue, essentially saying “Hi, I am a software engineer interested in working on astronomy software. What’s your world like?”

[yks]

That’s a dream of mine (astronomy and SWE) but alas earning money is a higher priority right now and unclear when that will change

[sgerenser]

If one started at Amazon before 2016 or so, and put in a full 4 years to get 100% of their new hire stock vesting, they’d easily have more than $1 million just in stock. That plus all your other savings from the time you put in can make relaxing in a lower paid role for the next N years until you’re ready to retire an attractive proposition.

[wfhbata]

Yes, that is exactly my point.

On the other hand, if you spend your early career as a researcher making five digits a year in the Midwest, then move to SV in middle age to increase your earnings, you probably won’t ever catch up and be able to live very comfortably given the cost of housing.

This is just a possible counterpoint, learned the hard way, to the common advice to “pursue your passion.” My advice to those who have the option: make some money first, then pursue your passion.

[r00fus]

Depending on where you live (and whether you own property) that may not be a lot if you are the only breadwinner with a family to raise.

[ska]

> epending on where you live (and whether you own property)

No, it's a lot for 4-5 years anywhere. This is on top of a pretty decent salary. For most working folk, putting this much aside in cash-equivalent over entire career is hard.

GP is talking about going from a high base salary to decent base salary, while using the extra comp (estimated here at approx 1mm) to smooth the impact of the drop in base. This is very manageable.

[sgerenser]

Edited my comment. The $1M is essentially on top of whatever you’d normally be able to save. If that is a lot more than $0 then most people would be in a pretty good position to take a lower paying job for as long as they want then retire comfortably.

[planet-and-halo]

How did you get into scientific computing? This is something I've been interested in but not sure what paths look like.

[spenczar5]

I've long been interested in astronomy - I majored in it in college. So I just emailed a professor out of the blue. I looked for one whose personal page said a lot about "astronomy software." We met for coffee, and it went from there.

I think it's pretty easy to find tons and tons of scientific groups that are absolutely dying to find more professional programmers - at least in physics and astronomy, but probably in lots of disciplines. Feel free to email me if you'd like to talk more.

[wikibob]

How did that decision impact you financially?

Were you able to get something in a similar range as what levels.fyi lists for an Amazon Principle Engineer ($640,000 [0])?

Or did you become financially independent from the Amazon comp which allowed you to not care about the new lower salary?

[0] https://www.levels.fyi/company/Amazon/salaries/Software-Engi...

[spenczar5]

I saved most of what I made from the Amazon comp, and now have more than enough to feel comfortable.

Now, I get $110,000 per year. That's plenty. I have a family, but my wife works too in tech and has a good income.

The marginal value of the extra income from working in big tech just wasn't worth it for me.

[wikibob]

Thanks for the reply!

If you had it to do over again, would you chose to go into the area that you’re especially interested in and sacrifice ever getting the high FAANG comp?

Or do you feel that having that savings invested has given you the long term security to feel comfortable, but perhaps if you’d made ~80% less over your career you’d be less satisfied?

[spenczar5]

That’s something I think about often. Sometimes I do wish I had plunged towards passions, but I know a lot of people who burned out by doing that.

I think my path was probably a good one; it really is very psychologically nice to not worry at all about money and be able to advance my career in any direction I want now without feeling like I am being selfish, or neglecting my responsibilities as a father, or whatever.

I also certainly learned a lot at Amazon (although the thing I learned most was “how to be effective inside Amazon,” which isn’t a particularly great skill in the long run!). So it was not so bad.

[Raptor22]

> I also certainly learned a lot at Amazon (although the thing I learned most was “how to be effective inside Amazon,” which isn’t a particularly great skill in the long run!).

Can you speak more to this? Why is being effective inside Amazon different from being effective at any other large organization?

[bradleyjg]

At the end of the days it’s hard or impossible to be such a good programmer that you can create as much value through programming as someone else can through enabling several to many other very good programmers to do better work.

There may be some less than candid framing in calling the roles “IC” but it does make sense that all ladders lead to multiplicative contributions in one or another.

[kstrauser]

My friend explained it this way: up through senior, you’re concentrating on making yourself and later your team more efficient. As you transition through to staff/principal, you’re working to make your department and whole company more efficient. Sometimes that means unblocking someone so their work can continue. Other times that means getting two teams together to work out their differences. Even if you’re not getting your hands dirty as often, you’re making a much bigger difference than you would if you were spending all day looking at code.

Reframing it that way made a huge difference for me. The things I’d thought of as chores, or necessary evils, are really my opportunity to use the knowledge I’ve accumulated to make whole teams of people work better. That’s pretty cool.

[Spooky23]

I did a “principal” role with another name in a CTO organization. It got old quickly because you had no control, and it was difficult to actually accomplish anything.

The org evolved to a strategic devops role where we absorbed strategic platforms. “Principal” tech chops plus actual control of moats in the org translate into getting shit done.

IMO, unless “principal” is primarily a way to pay you more, you’re better off actually owning stuff than being “IT Yoda”. The same skills you think you’re avoiding in a management role are critical (and harder) for a technical leader.

[mavelikara]

> a staff/principal role is basically going to be that of a co-manager with no authority.

The expectation is to be a leader without being a manager.

In many disciplines, to earn higher salaries you will have to produce/influence output at a level that might not be possible by one person. The way to get that kind of output is to mentor junior engineers.

[analog31]

That's been my role as a senior staff scientist. And at first glance, you'd wonder, well who in their right mind would want that? But it actually has its merits.

With authority comes a chain of authority. The manager is just projecting the authority of the manager above them, and so forth. That can translate into being a manager without being a leader or an authority. Also, if you rise to the expectation of being a leader, you might have a chance to actually get good at it, something that many good administrators never experience.

I've also been a manager. It was dull, and I knew that I would never be competitive at it, so I went back to the technical track.

[matthias509]

I am in a PE role right now and I 100% agree that the PE is the hub. I like that. I see my role as being a catalyst. I make things move along faster and more efficiently. I like seeing growth in others on the team.

Also, it’s ok if you don’t like that. If you would rather just be in there getting your hands dirty solving that one hard problem with no interruptions, then I think you should do that. You’ll be happier. Probably the increase in happiness is worth it even if you have to “pay” for it with a slightly reduced salary.

[andrey_utkin]

A question for all the PEs here. When you want to reflect critically on what you do, and actually measure your performance and/or bottom line contribution, what do you measure and how? What do your bosses measure? Surely warm fuzzy feelings and other placebo effects are not enough. Imagine a situation that some underlings resent about your uselessness or lack of responsibility. What criteria/facts could possibly make you agree with that?

[alistairSH]

As a manager, I’m looking at how my principals are helping the team move past big hurdles. Their ability to write code is a given, and they still do it (though not as much as they did, or at least not the same type of code). But are they mentoring and pair-programming with junior team members? Can they take what the BA/PM ask and turn it into meaningful technical tasks (that’s part of my job too - I try to lead that exercise, but need them as a sanity check and to stay on top of new things I might miss). Can they talk to a customer in a useful way (not too technical, not condescending) and do whatever problem is being discussed? Are they a go-to resource for other teams? Are senior leaders dropping in to ask them questions?

I’m definitely not looking at the raw number of Jura tasks here close. But I’m not looking at that for junior devs either.

Edit - usually, the more junior drive are more in awe of the principals. I’ve never encountered one who outwardly seemed to think the principal wasn’t contributing. More than likely, the principal was actively helping them get their own tasks done.

[matthias509]

This. If I’m not helping junior devs get their work done, I am failing as a PE.

[andrey_utkin]

Helping is activity, how do you evaluate the outcomes?

[wheelinsupial]

Where I work scrum masters are supposed to “help teams improve”. That’s measured, in one way, by looking at the current rate of performance of a team and projecting it out. Then a scrum master needs to improve the team’s performance by some amount that exceeds the cost of having them there.

Some examples, number of on time deployments, number of story points, number of bugs... I’m not saying this is perfect, but that’s how some people are measuring.

So if a PE is responsible for improving juniors, I suppose a PE can be judged on the size and complexity of projects their juniors are able to take on. Maybe the time to promotion and number of juniors getting promoted?

[alistairSH]

Unfortunately, it tends to be a bit "squishy" - task completion (by the PE or by junior team members), team velocity, etc can all be used, but using them exclusively is just asking for the team to game those metrics. Much better to have regular 1-on-1s with each person and just discuss progress - team progress, individual project/task progress, and any career goals. If somebody is actively seeking promotion, we'll use a job progression matrix (HR puts them together) and talk through the differentiators and what that employee can do to fill the gaps.

[aprdm]

Totally. It's also ridiculous difficult to change companies since your brain becomes pretty much the context of your current organization. It's IMO harder to apply to other companies as explaining your day-to-day requires a lot of context and nuance about your company that do not fit a resume.

Further to that, the interview process of staff/principal are usually akin to a senior dev with technical grinding except that isn't your day to day and hasn't been for a while.

[grayclhn]

You definitely need to be with a team that knows how to use principal-level ICs to be effective. Most teams need to be trained/coached (by the principal) in how to do that. :)

[didibus]

That's currently my worry as I grow, PE is the next level up, but I don't know if I want to get this far removed from the concrete code deliverables and software architectural decisions.

[alistairSH]

Does your employer have a separate software architect track? We have basically 3 tracks... developer, architect, and engineer. Developers write application code and the principals end up in that "hub" role mentioned up-thread. It's a good role, if you enjoy it. Architects drive corporate-wide tech direction, build new products from scratch (alongside developers), and some spend a lot of time working on standards and processes. And engineers are the DevOps/CloudOps guys - they code, but it's more scripting things and wiring systems together (vs building business apps) and they're on call. But, between the 3 general roles, there's pretty much a job for everybody.

I'm in an SRE role now, big change from a UX developer/manager (did that for 15+ years), but also fun and challenging, just in different ways.

Edit - All three tracks end up in some variety of "hub" role. Senior architects end up in meetings with VPs and other senior leaders. And writing documentation and diagrams. Engineers end up with lots of customer-facing time, which can be stressful if you don't thrive under pressure. Kind of comes with seniority. If you don't "play well with others" there's nothing wrong with staying in a true IC role - but you need to have the self-awareness and communication skills to make it known. And it definitely caps out a lower compensation level (ignoring some very niche skills).

[matthias509]

So don’t let yourself get removed completely from the deliverables. Keep in there. Take some tickets off the queue and work them so your skills stay sharp. If you are worth your salt, this contribution will be noticed by other ICs on the team and your boss. Just realize that the IC role isn’t primary for you. Provide useful feedback in reviews to keep dumb stuff from happening. Make sure your team is working on the right things.

And yes, the PE contribution is harder to measure and the risk is there that others won’t see it. If you aren’t comfortable with that risk, then don’t go for the PE role.

Which is OK! It doesn’t have to be “up or out”. For me PE is as high as I want to go. I have no desire to deal with the stress and risk of moving up past PE.

I’ve also intentionally moved from a PE at my precious job back to being 100% IC in my current company and then a few years later back to PE where I am now. I did that to build up a slightly different, more marketable skill set.