7 ms·

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.

by vp8989 5y ago

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.

matthias509 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      This. If I’m not helping junior devs get their work done, I am failing as a PE.
      - andrey_utkin 5y ago
        Helping is activity, how do you evaluate the outcomes?
        wheelinsupial 5y ago
        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 5y ago
        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.
grayclhn 5y ago
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. :)
spenczar5 5y ago
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 5y ago
  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.
  - sgerenser 5y ago
    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.
    - r00fus 5y ago
      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.
      - sgerenser 5y ago
        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.
      - ska 5y ago
        > 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.
libraryofbabel 5y ago
> 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.
- zebnyc 5y ago
  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
- paulz_ 5y ago
  > 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.
  - 5y ago
didibus 5y ago
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 5y ago
  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 5y ago
  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.
bradleyjg 5y ago
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 5y ago
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 5y ago
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.
aprdm 5y ago
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.
mavelikara 5y ago
> 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 5y ago
  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.

by vp8989 5y ago

matthias509 5y ago

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 5y ago
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 5y ago
  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 5y ago
    This. If I’m not helping junior devs get their work done, I am failing as a PE.
    - andrey_utkin 5y ago
      Helping is activity, how do you evaluate the outcomes?
      - wheelinsupial 5y ago
        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 5y ago
        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.

grayclhn 5y ago

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

spenczar5 5y ago

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 5y ago
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.
- sgerenser 5y ago
  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.
  - r00fus 5y ago
    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.
    - sgerenser 5y ago
      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.
    - ska 5y ago
      > 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.

libraryofbabel 5y ago

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

zebnyc 5y ago
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
paulz_ 5y ago
> 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.
- 5y ago

didibus 5y ago

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 5y ago
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 5y ago
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.

bradleyjg 5y ago

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 5y ago

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 5y ago

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.

aprdm 5y ago

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.

mavelikara 5y ago

> 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 5y ago
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.