My thoughts about the Principal role
galiglobal.com
My thoughts about the Principal role
1–10 of 124 posts
Re: My thoughts about the Principal role
#2Not 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.
Re: My thoughts about the Principal role
#3> Am I a manager? No. [I] let the team self organize with my help
Isn't that what a manager is, or should be?
Re: My thoughts about the Principal role
#4> Am I a manager? No. [I] let the team self organize with my help Isn't that what a manager is, or should be?
I look at it as being situational. Sometimes you end up with a team whose natural styles all mesh and they don’t need much leadership. Self-organization is great here; a manager’s role should be to give advice and deal with corporate politics (IMO the politics/budget angles are the difference between a principal/staff engineer and a manager).
Other times you get teams whose working styles are very far apart and have a hard time finding common ground. In the latter case, self-organization leads to communication breakdowns; so you have to force some organization on the team.
Ideally you would just hire a team with a diverse but complementary set of skills, but you go to war with the army you have.
Re: My thoughts about the Principal role
#5If you’d like to learn more on this topic Will Larsen has great read about being Principal Engineer. Here link to page that has link to his book https://staffeng.com/about/
Re: My thoughts about the Principal role
#6Not 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.
Interestingly it's sometimes harder for companies that already have the role defined than for growing orgs that usually do this JIT as really strong devs top out of senior and realize/decide they don't want to be become managers. I've defined this type of role twice now by using the skills and behaviours of the specific individuals (i.e. things they're already doing), then expanding the scope and sphere of influence for growth areas. It's worked pretty well because typically you should be promoting someone when they're demonstrating performance at the next level, rather than give them a promotion and then see if they're successful or not. The role needs to be vague enough to allow for individual and strategic changes, but defined enough to provide some type of identity. This is hard.
Re: My thoughts about the Principal role
#7It'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 seen this happening in tech too, especially with senior and "lead" roles (especially being "a" lead vs. "the" lead). At some places, I think the staff / principal / distinguished / etc engineer role is along these lines too, basically a way for a more experienced person to feel like they don't have the same job as a 25 year old.
Re: My thoughts about the Principal role
#8> Am I a manager? No. [I] let the team self organize with my help Isn't that what a manager is, or should be?
I look at it as being situational. Sometimes you end up with a team whose natural styles all mesh and they don’t need much leadership. Self-organization is great here; a manager’s role should be to give advice and deal with corporate politics (IMO the politics/budget angles are the difference between a principal/staff engineer and a manager). Other times you get teams whose working styles are very far apart and have…
Also, although managers appear to work for a team or specific area, they usually interface across many or all in a department. The self organizing team will usually do so as if they are completely independent which is rarely true, so they need to organize within constraints of which they are totally unaware. Example: getting a different team to priortize work upon which your team depends will involve larger development plans, product management and the "politics" you reference. I've never met a technical lead who wants to do this and few who are good at it. This is a good thing.
Re: My thoughts about the Principal role
#9Principal 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 people comments, adding thumbs up emojis, and at the end says “Big thank you to all the people involved” (plus a rocket emoji)
- There’s a decision to be made regarding i18n for DB tables. Architects, senior devs and the principal engineer get together to talk about potential solutions. The principal engineer acts as a lean manager: let people talk in turns, does support good ideas (I mean, he’s not clueless ofc), does try to gather everyone in to a common solution... but never gets his hands dirty as in: “what do you think about solution X? I could work on a POC to see if it’s worth it”. If, after months, it turns out that the idea to be implemented does work, then he says “All the props to the team!” (No way, really? It’s obvious that all the props should go to the team! You, principal, did nothing!). If it turns out that the idea actually does not work, then “no one is to blame, let’s do it better the next time. Let’s get feedback and blah blah”. As I said, if something works or if something doesn’t, it’s never on the principal (but hey, he gets to make twice as much as the most senior dev in the company!)
- Microservices or modular monolith? Same as above. The principal engineer knows his stuff, but just as much as any other architect or senior dev, with the difference that the architects and senior devs are the ones who are going to do 99% of the work (both im terms of choosing the final decision and implementing them. The principal is just there to “support”... but that’s actually quite useless tbh) and they make significantly less money than the principal engineer.
Re: My thoughts about the Principal role
#10It seems like "Principal Engineer" is the new "Architect".