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…
My thoughts about the Principal role
21–30 of 124 posts
Re: My thoughts about the Principal role
#22Principal 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
#23One 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
#24Principal 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
#25I 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> 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…
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
#27It'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> 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…
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
#29Principal 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…
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
#30It 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…