by bitfield on 4/12/23, 9:15 AM with 49 comments
by tibbon on 4/12/23, 1:49 PM
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.
by frankdejonge on 4/12/23, 12:20 PM
by azangru on 4/12/23, 11:50 AM
> 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?
by throwawayfaang9 on 4/12/23, 12:59 PM
This rarely is beneficial work the company should/must do, instead it is promotion driven development.
by csmpltn on 4/12/23, 2:38 PM
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.
by potamic on 4/12/23, 1:58 PM
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.
by marstall on 4/12/23, 1:33 PM
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!
by 000ooo000 on 4/12/23, 1:55 PM
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.