8 ms·

The reality of being a Principal Engineer

92 points by bitfield 3y ago

throwawayfaang9 3y ago
In my experience, the emphasis on cross organization “impact” just leads principal engineer hopefuls to try to force other teams to sign onto large projects that require multiple teams to put in effort. This rarely is beneficial work the company should/must do, instead it is promotion driven development.
- rqtwteye 3y ago
  "This rarely is beneficial work the company should/must do, instead it is promotion driven development." Unfortunately resume and promotion driven development are a very rational approach in most companies. If yo do what needs to be done in an efficient way, you will rarely get recognized and others who do shiny stuff will pass you by.
  - throwawayfaang9 3y ago
    Yeah I know, but I guess I’m just not enough of a sociopath to climb the ladder in FAANG. Just stuck at Senior, probably forever.
    - HeyLaughingBoy 3y ago
      Why do you think you need to be a sociopath to do that?
      - rqtwteye 3y ago
        "Sociopath" is probably a little too harsh. But you need to look out for your advantage and not always only do what's good for the company. You also need to make sure you get credit for your accomplishments.
        HeyLaughingBoy 3y ago
        A little? It's a pretty strong word :-) I agree with what you said, but I would have thought that was common knowledge. Your interests should always outweigh the company's. Anyone believing otherwise is eventually going to get an unpleasant surprise.
        rqtwteye 3y ago
        There is still a wide-spread belief that doing good things gets rewarded and that self-promotion is bad. That's the loophole a lot of business people exploit to enrich themselves at the expense of their workers.
- vp8989 3y ago
  Agreed. There is also a natural disincentive here to optimize the architecture for "team-based flow". As a product engineer, you often get promoted for doing projects that essentially cope with a sub-optimal architecture. If you improve the architecture, there is less promotion fodder for the next person to get to these levels. In fact, I have myself literally been promoted for the former and NOT promoted for the latter. Note that I am referring to product engineers. Platform/infra engineers necessarily have to work cross-team. And of course some "product" projects should be cross-team ... but if most or all of your product engineering projects are cross-team that is a huge red flag.
marstall 3y ago
I've had the Principal Engineer title for several years now. I think I got basically because everyone else seemed to have awesome sounding titles like that and I asked for it. My manager probably felt guilty because he wasn't giving me a raise that year, so he gave it to me. I got a printed promotion letter and everything! What did I do? I was on a two person project with another Principal Engineer for all that time, sharing architecture, coding, design, refactoring work. writing tests, doing deploys, etc. basically the same thing I've done anywhere else. What made me a principal? Maybe the fact there was no-one telling me how to code? I guess that doesn't qualify me as a "true" principal like the OP is describing ... but thought I'd share!
tibbon 3y ago
I'm a Principal engineer at a ~300 person organization and I feel a bit stuck/ineffective. In theory, we aligned the ladders in a manner that Principal sits parallel to Directors in the management track. I'm expected to impact org-wide culture, policy, technology direction, strategy, etc... but so rarely am I allowed into the rooms where decisions are being made, let alone discussed. I don't know (at all) what is being discussed, and by the time I find out about it things are set in stone. I do what I can with mentoring and team culture, and lead by example for code-related things, but that is all very zoomed in and tactical. We've been told explicitly that we're holding off on having people write technical strategy/vision until we have organization-wide direction from those in upper Leadership. That has been the promise for a long time, but for one reason or another keeps failing to materialize. At this point, upper Leadership won't even meet with someone of my rank/position, as they only respect others with VP to C-level titles to work with. This is the type of reality I fear encountering at other organizations. I worry that despite the allure of Principal title, the reality is that too often such things happen and that when it comes down to it, VPs and C-levels only respect similar, and want Principals or Distinguished Engineers simply as "advanced fixers" for problems in a short time.
- liveoneggs 3y ago
  Who told you to not do stuff and why are you listening to them? Who do you report to?
- vp8989 3y ago
  If I understand you correctly, I have felt similar angst before in this kind of role. Basically, you see "org-wide" work that needs to be done but it requires some level of "org-wide" alignment that doesn't yet exist. So you feel like you are twiddling your thumbs doing code reviews and making the tests faster while you wait to get the green light to "do your actual job". At least for me, in hindsight, a lot of that was just in my head. It's fine once you earn the level to not always operate at it. Just as long as when that's needed again you are able to step up.
  - Swizec 3y ago
    > while you wait to get the green light to "do your actual job" In my experience as a pre-staff – it is your job to create the green light. You’re director level, there is no-one to say “make it so”. You’re the one who’s supposed to do that. Org-wide stuff not happening? Guess what, you have to go figure out how to make it happen. Even if that means getting buddy buddy with some of the other directors and building informal networks within the company. That’s the job. Making things happen. Poking the right person at the right time, cashing in favors, building a rapport, etc. And yes, sometimes pulling a VP into a meeting and asking “hey can you pull a string”
000ooo000 3y ago
>"The reality of being a Principal Engineer" The reality? >One of the most important competencies of a principal engineer is to become a force multiplier. This is a more mature definition of the ‘10x engineer’ than what the Silicon Valley ‘cargo cult’ like to use. A 'more mature definition'? What? It's just another buzzword. What a garbage article.
- HeyLaughingBoy 3y ago
  Force multiplier and 10x engineer are two completely different things, at least as they are usually described. The 10x engineer is simply one who has an output far higher than average. The Principal engineer working as a force multiplier has the goal of raising the output of the entire team, group or company. If I can 1.5x a 10-person team, I'm already more valuable than that 10x engineer.
potamic 3y ago
> Once you reach a certain level, all problems are solved by people. There is no such thing as a purely technical problem. It's a good summary overall, but in my view the best principal engineers are the ones who also solve pure, hard, technical problems. Far too often, people at the principal level are content with strategizing and guiding, staying away from the ground. But you lose a lot of potential that way. Nothing can replicate the value of problem solving and building things together. As an engineer, few experiences will give you the kind of learning you get when pairing with someone experienced, knowledgeable and passionate in a subject. As a principal, there is no better way to visit the depths of a problem domain than by working directly on it. Of course it takes a tremendous amount of trust from both parties to not feel undermined sharing responsibilities, and that's usually the hardest part.
csmpltn 3y ago
Hot take: I don't think organizations with less than ~1000 engineers in the org-chart should even have "Principal Engineers". If you: 1. Write code 2. Build proof-of-concepts 3. Fix bugs 4. Create designs 5. Align work across multiple teams 6. Work together on a complex feature, or features 7. Identify new directions and opportunities 8. Create an architecture Then, congratulations, you're a software engineer. Enough with this self-aggrandizing s*!t already.
- quest88 3y ago
  [flagged]
- ThorsBane 3y ago
  Kinda true, but the speed and quality and scope make a difference. A principal moves much faster than a senior, who moves much faster than a junior, who moves much faster than an intern. The comp and responsibilities need to justify the title.
azangru 3y ago
Amusingly, she writes: > Once I became a principal engineer, it quickly became clear to me that my job involved a lot more than closing tickets and writing code to achieve things. If we take this sentence at face value, are we to conclude then that _before_ she became a principal engineer, it was not clear to her what the role would entail? And if yes, then what would be the process that made it clear to her after she became a principal engineer?
- jameshart 3y ago
  It’s way more common than you might think for companies to give people job titles in order to figure out what the job involves. If you’re the first ‘principal’ engineer in your company of course you don’t know what you have to do to succeed. And even if there are already a couple of people with that title, there’s no guarantee that they know how to actually make a difference at that level - they’re figuring it out too. Or that what they do to succeed in their division will work just as well in yours. A big part of being put in a leadership position is precisely that if you have questions like ‘how do I actually make a difference in this company on this dimension?’, the answer is: ‘we don’t know. That’s what we hired you to figure out’.
  - ianbutler 3y ago
    It doesn't help that this is not a standard position across the industry. Show me 5 different staff and principal engs and I'll show you 5 different sets of expectations and responsibilities. It's better now than a few years ago at least.
    - azangru 3y ago
      There was a thread on HN recently [0], in which many expressed an opinion that "senior developer" role is a "force multiplier" involving semi-managerial and mentoring responsibilities. It amused me, therefore, to read that in the author's case, being a senior developer presumably meant just, quote, "closing tickets and writing code to achieve things", i.e. being an actual developer. [0] - https://news.ycombinator.com/item?id=34628933 https://news.ycombinator.com/item?id=34628933
frankdejonge 3y ago
I don't mean to beat down on this article, but the bar set here seems pretty low. Many of the aspects detailed in the article, to me, fall under the responsibility of engineers well below principal level. Suggesting to use, and using, best practices should be expected from people at senior level. Leading initiatives that span multiple teams is a common expectation for staff level engineers. For me, the distinguishing factor between pre staff and staff and above is strategy. Ensuring the technical decisions are made strategically (in alignment with or acknowledgement of longer term business goals), where before the focus is largely tactical (how you execute). That said, I think the shift described is an essential shift for many engineers going up the ladder, although for some the titles don't match the point where this becomes relevant.
- falcolas 3y ago
  That’s mostly because there’s no universal definition of the various software developer titles and their roles. 10 years ago, I was a principle developer. Now I’m a senior developer. Why? I’m at a different company who didn’t have anything above Sr when I joined. Plus, you tend to reset titles when you swap jobs. Staff, principal et.al. tend to be reserved for internal promotions.

92 points by bitfield 3y ago

In my experience, the emphasis on cross organization “impact” just leads principal engineer hopefuls to try to force other teams to sign onto large projects that require multiple teams to put in effort. This rarely is beneficial work the company should/must do, instead it is promotion driven development.

rqtwteye 3y ago
"This rarely is beneficial work the company should/must do, instead it is promotion driven development." Unfortunately resume and promotion driven development are a very rational approach in most companies. If yo do what needs to be done in an efficient way, you will rarely get recognized and others who do shiny stuff will pass you by.
- throwawayfaang9 3y ago
  Yeah I know, but I guess I’m just not enough of a sociopath to climb the ladder in FAANG. Just stuck at Senior, probably forever.
  - HeyLaughingBoy 3y ago
    Why do you think you need to be a sociopath to do that?
    - rqtwteye 3y ago
      "Sociopath" is probably a little too harsh. But you need to look out for your advantage and not always only do what's good for the company. You also need to make sure you get credit for your accomplishments.
      - HeyLaughingBoy 3y ago
        A little? It's a pretty strong word :-) I agree with what you said, but I would have thought that was common knowledge. Your interests should always outweigh the company's. Anyone believing otherwise is eventually going to get an unpleasant surprise.
        rqtwteye 3y ago
        There is still a wide-spread belief that doing good things gets rewarded and that self-promotion is bad. That's the loophole a lot of business people exploit to enrich themselves at the expense of their workers.
vp8989 3y ago
Agreed. There is also a natural disincentive here to optimize the architecture for "team-based flow". As a product engineer, you often get promoted for doing projects that essentially cope with a sub-optimal architecture. If you improve the architecture, there is less promotion fodder for the next person to get to these levels. In fact, I have myself literally been promoted for the former and NOT promoted for the latter. Note that I am referring to product engineers. Platform/infra engineers necessarily have to work cross-team. And of course some "product" projects should be cross-team ... but if most or all of your product engineering projects are cross-team that is a huge red flag.

marstall 3y ago

I've had the Principal Engineer title for several years now. I think I got basically because everyone else seemed to have awesome sounding titles like that and I asked for it. My manager probably felt guilty because he wasn't giving me a raise that year, so he gave it to me. I got a printed promotion letter and everything! What did I do? I was on a two person project with another Principal Engineer for all that time, sharing architecture, coding, design, refactoring work. writing tests, doing deploys, etc. basically the same thing I've done anywhere else. What made me a principal? Maybe the fact there was no-one telling me how to code? I guess that doesn't qualify me as a "true" principal like the OP is describing ... but thought I'd share!

tibbon 3y ago

I'm a Principal engineer at a ~300 person organization and I feel a bit stuck/ineffective. In theory, we aligned the ladders in a manner that Principal sits parallel to Directors in the management track. I'm expected to impact org-wide culture, policy, technology direction, strategy, etc... but so rarely am I allowed into the rooms where decisions are being made, let alone discussed. I don't know (at all) what is being discussed, and by the time I find out about it things are set in stone. I do what I can with mentoring and team culture, and lead by example for code-related things, but that is all very zoomed in and tactical. We've been told explicitly that we're holding off on having people write technical strategy/vision until we have organization-wide direction from those in upper Leadership. That has been the promise for a long time, but for one reason or another keeps failing to materialize. At this point, upper Leadership won't even meet with someone of my rank/position, as they only respect others with VP to C-level titles to work with. This is the type of reality I fear encountering at other organizations. I worry that despite the allure of Principal title, the reality is that too often such things happen and that when it comes down to it, VPs and C-levels only respect similar, and want Principals or Distinguished Engineers simply as "advanced fixers" for problems in a short time.

liveoneggs 3y ago
Who told you to not do stuff and why are you listening to them? Who do you report to?
vp8989 3y ago
If I understand you correctly, I have felt similar angst before in this kind of role. Basically, you see "org-wide" work that needs to be done but it requires some level of "org-wide" alignment that doesn't yet exist. So you feel like you are twiddling your thumbs doing code reviews and making the tests faster while you wait to get the green light to "do your actual job". At least for me, in hindsight, a lot of that was just in my head. It's fine once you earn the level to not always operate at it. Just as long as when that's needed again you are able to step up.
- Swizec 3y ago
  > while you wait to get the green light to "do your actual job" In my experience as a pre-staff – it is your job to create the green light. You’re director level, there is no-one to say “make it so”. You’re the one who’s supposed to do that. Org-wide stuff not happening? Guess what, you have to go figure out how to make it happen. Even if that means getting buddy buddy with some of the other directors and building informal networks within the company. That’s the job. Making things happen. Poking the right person at the right time, cashing in favors, building a rapport, etc. And yes, sometimes pulling a VP into a meeting and asking “hey can you pull a string”

000ooo000 3y ago

>"The reality of being a Principal Engineer" The reality? >One of the most important competencies of a principal engineer is to become a force multiplier. This is a more mature definition of the ‘10x engineer’ than what the Silicon Valley ‘cargo cult’ like to use. A 'more mature definition'? What? It's just another buzzword. What a garbage article.

HeyLaughingBoy 3y ago
Force multiplier and 10x engineer are two completely different things, at least as they are usually described. The 10x engineer is simply one who has an output far higher than average. The Principal engineer working as a force multiplier has the goal of raising the output of the entire team, group or company. If I can 1.5x a 10-person team, I'm already more valuable than that 10x engineer.

potamic 3y ago

> Once you reach a certain level, all problems are solved by people. There is no such thing as a purely technical problem. It's a good summary overall, but in my view the best principal engineers are the ones who also solve pure, hard, technical problems. Far too often, people at the principal level are content with strategizing and guiding, staying away from the ground. But you lose a lot of potential that way. Nothing can replicate the value of problem solving and building things together. As an engineer, few experiences will give you the kind of learning you get when pairing with someone experienced, knowledgeable and passionate in a subject. As a principal, there is no better way to visit the depths of a problem domain than by working directly on it. Of course it takes a tremendous amount of trust from both parties to not feel undermined sharing responsibilities, and that's usually the hardest part.

csmpltn 3y ago

Hot take: I don't think organizations with less than ~1000 engineers in the org-chart should even have "Principal Engineers". If you: 1. Write code 2. Build proof-of-concepts 3. Fix bugs 4. Create designs 5. Align work across multiple teams 6. Work together on a complex feature, or features 7. Identify new directions and opportunities 8. Create an architecture Then, congratulations, you're a software engineer. Enough with this self-aggrandizing s*!t already.

quest88 3y ago
[flagged]
ThorsBane 3y ago
Kinda true, but the speed and quality and scope make a difference. A principal moves much faster than a senior, who moves much faster than a junior, who moves much faster than an intern. The comp and responsibilities need to justify the title.

azangru 3y ago

Amusingly, she writes: > Once I became a principal engineer, it quickly became clear to me that my job involved a lot more than closing tickets and writing code to achieve things. If we take this sentence at face value, are we to conclude then that _before_ she became a principal engineer, it was not clear to her what the role would entail? And if yes, then what would be the process that made it clear to her after she became a principal engineer?

jameshart 3y ago
It’s way more common than you might think for companies to give people job titles in order to figure out what the job involves. If you’re the first ‘principal’ engineer in your company of course you don’t know what you have to do to succeed. And even if there are already a couple of people with that title, there’s no guarantee that they know how to actually make a difference at that level - they’re figuring it out too. Or that what they do to succeed in their division will work just as well in yours. A big part of being put in a leadership position is precisely that if you have questions like ‘how do I actually make a difference in this company on this dimension?’, the answer is: ‘we don’t know. That’s what we hired you to figure out’.
- ianbutler 3y ago
  It doesn't help that this is not a standard position across the industry. Show me 5 different staff and principal engs and I'll show you 5 different sets of expectations and responsibilities. It's better now than a few years ago at least.
  - azangru 3y ago
    There was a thread on HN recently [0], in which many expressed an opinion that "senior developer" role is a "force multiplier" involving semi-managerial and mentoring responsibilities. It amused me, therefore, to read that in the author's case, being a senior developer presumably meant just, quote, "closing tickets and writing code to achieve things", i.e. being an actual developer. [0] - https://news.ycombinator.com/item?id=34628933 https://news.ycombinator.com/item?id=34628933

frankdejonge 3y ago

I don't mean to beat down on this article, but the bar set here seems pretty low. Many of the aspects detailed in the article, to me, fall under the responsibility of engineers well below principal level. Suggesting to use, and using, best practices should be expected from people at senior level. Leading initiatives that span multiple teams is a common expectation for staff level engineers. For me, the distinguishing factor between pre staff and staff and above is strategy. Ensuring the technical decisions are made strategically (in alignment with or acknowledgement of longer term business goals), where before the focus is largely tactical (how you execute). That said, I think the shift described is an essential shift for many engineers going up the ladder, although for some the titles don't match the point where this becomes relevant.

falcolas 3y ago
That’s mostly because there’s no universal definition of the various software developer titles and their roles. 10 years ago, I was a principle developer. Now I’m a senior developer. Why? I’m at a different company who didn’t have anything above Sr when I joined. Plus, you tend to reset titles when you swap jobs. Staff, principal et.al. tend to be reserved for internal promotions.