Live data from Hacker News

My thoughts about the Principal role

galiglobal.com

51–60 of 124 posts

Re: My thoughts about the Principal role

#51
post #9

Principal role = expensive lean manager. They want to help others achieve something without actually getting their hands dirty. Of all the principal engineers I’ve worked with, the vast majority behave like motivational coaches/lean managers. Examples: - There’s an outage on a Sunday morning. A huge Slack thread starts. Devops and devs on call manage to fix the issue. Principal engineer gets involved ACKing other’s p…

I'm in a PE role, and I have to tell myself every day not to go do the POC because that's not how I can maximize my impact. If someone else can do that work, I'm going to try and lean on them. Strategy is hard. Much harder than I thought it would be. I am unable to make progress on strategy when I'm deep in tactical work. I do jump in when needed, but every time I get my hands dirty I fall behind on strategy. Your PE…

[deleted]

Re: My thoughts about the Principal role

#52
post #27

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 rol…

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.

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

Re: My thoughts about the Principal role

#53
post #27

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 rol…

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

Re: My thoughts about the Principal role

#54
post #13

> An architect? A big part of my work is to improve systems and platforms. Listen to problems and propose solutions. But I don't feel like the guy who does a plan which must be blindly followed by others. I don't want to be a gatekeeper who says what can be used and what can't. The only area where I feel like you need to be super careful is around architecture. How many chefs can bake the same cake before you have a…

The issue is that at a certain scale no one person is smart enough, knowledgeable enough or has enough time to actually design a system properly with all the necessary detail. Those who try create an even worse mess than a design by committee.

>The people developing the schema should understand what normalization is and why it's so critical to long term success.

I'd expect everyone except a junior engineer to understand this if the system they work on support normalization well (ie: map reduce hates joins for example). If only your most senior engineers understand basic concepts then you have much more serious issues than design by committee.

>100% of business apps can start as excel spreadsheets documenting types, facts & relations.

Except in a large system no one person knows what all the types, facts and relations are. So you either delegate the work and listen to feedback, or you end up missing critical information or having the wrong information.

Re: My thoughts about the Principal role

#55
post #27

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 rol…

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

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?

Re: My thoughts about the Principal role

#56
post #9

Principal role = expensive lean manager. They want to help others achieve something without actually getting their hands dirty. Of all the principal engineers I’ve worked with, the vast majority behave like motivational coaches/lean managers. Examples: - There’s an outage on a Sunday morning. A huge Slack thread starts. Devops and devs on call manage to fix the issue. Principal engineer gets involved ACKing other’s p…

Ok, but are you implying there is no value in that? Wouldn't you need such a person, and wouldn't you need that person to not be clueless and know their stuff to be able to do a good job at it?

Re: My thoughts about the Principal role

#57
post #27

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 rol…

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.

Re: My thoughts about the Principal role

#58
My quality of life as a senior staff eng depends on a couple things. Be curious what others would add:

- *good manager*: at my company, I’m paired with a manager over a focus area. If they are good we'll form an effective partnership. They’ll help protect focus time, take on lots of planning and people management work, while I focus on the teams technical leadership and roadmap.

-*Important company priority*: if what I’m working on actually matters to the company, we'll get the resources we need to execute. Without this, our team will be frequently poached and we won’t achieve much.

- *strong stakeholder relationships*: I regularly meet with and take feedback from stakeholders. They can see where we’re going on a tech level and incorporate us into their plans. We can be an asset to the company’s different, customer facing product lines, not a hermitted group of devs.

- *strong inter-disciplinary collaboration*: we have all the disciplines we need on the team. Whether it’s data, UX, eng, or something else, we’re not playing politics to negotiate with another management structure on every little task our team needs. It just gets done a a virtue of this discipline being a teammate...

- *A road to prod*: we ship early and ship often. We don’t have anything in our way external to the team for shipping. Also we’re not working on a theoretical thing, it’s actual prod code we help with!

-*hiring great people*: we hire amazing people, and usually we don’t have to worry about their quals. Or worry about them being a jerk. Also we meet to ensure they’ll be a good fit for the team.

-*a clear area I own*: I want to make sure that if I’m given technical authority over an area, there’s not another overlapping staff/principal eng who’s also expecting to own some of that space. It’s clear what the groupings are and who does what to avoid politics and ego clashes between alpha geeks.

-*active burnout prevention*: the culture and management work against my hard-charging style and strongly encourage me to walk away from work during vacations, weekends, and evenings...

Re: My thoughts about the Principal role

#59
post #43

Earlier quoted context omitted.

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.

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.

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.

Re: My thoughts about the Principal role

#60
post #43

Earlier quoted context omitted.

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.

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.

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.
Post reply on HN