Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My thoughts about the Principal role

galiglobal.com

Post reply on HN
Print view View original

11–20 of 124 posts

Re: My thoughts about the Principal role

#11

Post by version_five »

tkiolp4 wrote: 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…

> 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 people comments, adding thumbs up emojis, and at the end says “Big thank you to all the people involved” (plus a rocket emoji)

Just want to call out how accurate this is. The last place I worked was full of this kind of person (as managers, wecdid not have a principal title), and the description, right down to the emojis is bang on!

Re: My thoughts about the Principal role

#12

Post by radicalbyte »

version_five wrote: post #7

It's common in the consulting industry to have a wide range of titles - [senior] manager / principal, director, managing director, executive director, vice president, associate partner, etc. Depending on the firm, literally all of those could refer to a similar job. The reason I've seen put forward for this is to make it hard to compare titles, so that a person can feel like their title matches their seniority. I've…

It's also a way to provide a technical career path without having your super experienced people all stepping on each others toes.

Re: My thoughts about the Principal role

#13

Post by bob1029 »

> 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 total shitshow on your hands? In my experience, this depends on the complexity of the cake. The more complex, the fewer chefs can be involved at the same time.

The last place you want design-by-committee is when you are trying to model a very complex problem domain. Have your elder council determine the types, facts & relations for your solution, then let the team go wild on top of it. The people developing the schema should understand what normalization is and why it's so critical to long term success. 100% of business apps can start as excel spreadsheets documenting types, facts & relations. There is zero excuse to not start here [0].

Without some common understanding of what the fuck you even call things (and how they are related), you don't need to have a bunch of distributed design meetings about logic & UI that will be built on top of those concepts.

[0]: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

Re: My thoughts about the Principal role

#14

Post by sudeepj »

> I don't feel like the guy who does a plan which must be blindly followed by others

When I became PE, my boss said that if you have to successful then you need to get teams listen to you by influencing instead of an authority.

At that moment, I had no idea how to go about this. But I realized one thing: "Knowledge is power". If you know the tech-stack, product & domain then you are well equipped for this role.

Re: My thoughts about the Principal role

#15

Post by halfmatthalfcat »

efnx wrote: post #2

Not only is it hard to define what the principal engineering role is, it will be different at almost every company. The same goes for staff eng and even to a lesser degree senior eng.

And even more harder is that within a company, those titles are vastly different depending on what team you get hired on to. You could be hired on at a senior level for a given team yet be considered a standard software developer or even associate on a different team.

Case in point, an engineer was hired on in my current company at a Senior role, being even considered for Principal and was subsequently moved to my team. They are now gauged at almost an Associate level when compared to the rest of the engineers on my team and their titles.

Re: My thoughts about the Principal role

#16

Post by stephc_int13 »

version_five wrote: post #7

It's common in the consulting industry to have a wide range of titles - [senior] manager / principal, director, managing director, executive director, vice president, associate partner, etc. Depending on the firm, literally all of those could refer to a similar job. The reason I've seen put forward for this is to make it hard to compare titles, so that a person can feel like their title matches their seniority. I've…

I've seen that in Video Games versus Advertisement, Art Director is a high seniority position in the former while it could be an internship role in the latter.

Re: My thoughts about the Principal role

#18

Post by slumdev »

tkiolp4 wrote: 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…

You're right about how the role ends up being implemented, but it shouldn't be this way.

Re: My thoughts about the Principal role

#19

Post by sokoloff »

version_five wrote: post #11
tkiolp4 wrote: 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…

> 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 people comments, adding thumbs up emojis, and at the end says “Big thank you to all the people involved” (plus a rocket emoji) Just want to call out how accurate this is. The last place I worked was full of this kind of person (as managers, wecdid not ha…

If I had such a principal on my team, I’d be happy about that. It means that they’ve contributed to an overall team dynamic where the team does not depend on them personally to perform under pressure.

Far worse is a team of on-call juniors who stand around jabbering cluelessly until someone decides to call in Principal Pat who fixes it in 15 minutes during the 7th hour of outage.

If the team is on the right track, providing non-technical support and encouragement is exactly what a principal/director should be doing, to reinforce that the team is performing and earns the credit.

The principal “owns” the annual downtime and problem-loss figures. The team gets credit for this weekend’s fix.

In other words: “A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves.” —-Lao Tzu

Re: My thoughts about the Principal role

#20

Post by _y5hn »

version_five wrote: post #11
tkiolp4 wrote: 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…

> 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 people comments, adding thumbs up emojis, and at the end says “Big thank you to all the people involved” (plus a rocket emoji) Just want to call out how accurate this is. The last place I worked was full of this kind of person (as managers, wecdid not ha…

Not a "Principal", but you guys would rather be followed up by a business person who would come up with their revised requirements and timelines, each day or the other? Or obey the commands of the technological genius that somehow always have the answer to every question, for others to implement exactly as told?

Leading by using technological experience and refraining from prescribing "the meds" all the time, is lighter work, so one can stretch over much more than otherwise. But nobody becomes master of everything, and those places that have those, truly suck without knowing it. Having to go into all the depths, someone else'll need to take point..

Post reply on HN