Live data from Hacker News

My thoughts about the Principal role

galiglobal.com

21–30 of 124 posts

Re: My thoughts about the Principal role

#21
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…

As someone adjacent to this role, a lot of the time this sort of "hands off" behavior is incentivized; the reason the principal is not jumping in and taking point on making the final decision and implementing is because that severely reduces the agency and ownership of the senior devs below them (and in many companies risk undercutting the latter's career progression, if it depends on them showing that independent ownership).

Re: My thoughts about the Principal role

#22
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…

[deleted]

Re: My thoughts about the Principal role

#23
This post is good in that it doesn't try to define what a principal engineer is, but just give the author's opinion on what their job is.

One thing I realized with getting jobs with increasing degrees of ambiguity and autonomy is that you can _somewhat_ make it what you want. If it turns out that what you want aligns with what is needed, then things go super well.

The other thingis that titles are just a construct. They're nice badges that help rewarding people by giving ego instead of money. being a principal in a startup is different from being one at Amazon is different from being one at Facebook.

Re: My thoughts about the Principal role

#24
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…

Interesting; at the places I've worked, "architects" are more senior and highly paid than "principal engineers". This description is totally unfamiliar to me.

Re: My thoughts about the Principal role

#25
It is supposed to be a super-smart engineer who is extremely vertical in multiple disciplines, can solve complex problems, and can navigate politics.

I worked at Intel. A principal engineer in the process or architecture was vastly different than a principal engineer elsewhere. For the most part, you become a principal engineer by sticking around, doing lots of extra work, and making at least several major contributions in your career that impact multiple products' bottom line or viability. As a bonus there is a weird deferred-income strategy they use that helps you avoid taxes, your regular bonus multipliers skyrocket, and you are expected to work 24/7.

However, I witnessed several abuses where:

- You can become one if you are friends with an upper manager who scoots you ahead in the line. Several times I saw this type of PE later pushed out by new management, because it was painfully obvious they were in over their heads to everyone else.

- You can become one if you are in a small group that wants to justify its existence. Every group needs a principal engineer, and without one, it is a risk the group will be dissolved. Some managers of tiny groups like their ego trip and want to continue being big fish in small ponds.

- And you can become one if your work a site that hands them out to puff up its image. In the latter case, there was one non-US site that was almost 40% principal engineers, and used that as their claim to fame. "We have the most principal engineers at our site" said the VP. Duh! You are also the VP that approved all of them so you could say that!

So while Intel's definition makes sense and is generally true, it is abused about ... ~35% of the time?

Disclaimer: Intel is an up or out company. You move up, or you move out. It is hard to hover in certain high-pressure divisions. I was passed over twice for PE and shuffled between divisions, and eventually exhausted to the point where i was "out". So i'm a tad bit bitter.

Re: My thoughts about the Principal role

#26
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…

From a practical perspective, most companies large enough to support PEs as described here, are going to have misaligned hacks that made sense once upon a time but are no longer sensible.

A big part of a PEs job is to keep the train moving despite nonsensical design decisions, organizational politics/empires, and legacy code bases/use cases that no one wants to touch. A good PE will help incrementally resolve/improve the above situations.

Re: My thoughts about the Principal role

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

Re: My thoughts about the Principal role

#28
post #26
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…

From a practical perspective, most companies large enough to support PEs as described here, are going to have misaligned hacks that made sense once upon a time but are no longer sensible. A big part of a PEs job is to keep the train moving despite nonsensical design decisions, organizational politics/empires, and legacy code bases/use cases that no one wants to touch. A good PE will help incrementally resolve/improve…

> A good PE will help incrementally resolve/improve the above situations.

100% agree. What I posted above is an idealistic perspective in which you get to greenfield an application from zero. Most real world situations involve some degree of legacy domain implementations which must be bridged into the future.

Being able to rebuild the ship from the inside while it is sailing to the new world is an incredibly valuable skill set. Many developers get frustrated and demand a total rewrite (I used to do this). It would be really hard to make forward progress if you start off with a new ship in Spain every time you encountered the slightest bit of friction.

Re: My thoughts about the Principal role

#29
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 may indeed be useless, but it's also possible they are pretty good at their job. Good strategy is boring and seems obvious when presented because it creates clarity across a diverse company.

Re: My thoughts about the Principal role

#30

It is supposed to be a super-smart engineer who is extremely vertical in multiple disciplines, can solve complex problems, and can navigate politics. I worked at Intel. A principal engineer in the process or architecture was vastly different than a principal engineer elsewhere. For the most part, you become a principal engineer by sticking around, doing lots of extra work, and making at least several major contributi…

I consider principal engineers / architects "astronauts". They've spent so much time floating around they've forgotten what solid ground feels like. They're both disoriented and atrophied when it comes to engineering. It's a trap. You'll eventually have to come back down to earth, and the longer you spend in this role the harder it will be.
Post reply on HN