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…
My thoughts about the Principal role
51–60 of 124 posts
Re: My thoughts about the Principal role
#52I 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.
Re: My thoughts about the Principal role
#53I 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…
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> 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 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
#55I 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.…
Re: My thoughts about the Principal role
#56Principal 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…
Re: My thoughts about the Principal role
#57I 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…
Re: My thoughts about the Principal role
#58- *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
#59Earlier 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.
Re: My thoughts about the Principal role
#60Earlier 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.