I'm a Principal engineer at a ~300 person organization and I feel a bit stuck/ineffective.<p>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.<p>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.<p>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.<p>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.
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.
Amusingly, she writes:<p>> 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.<p>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?
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.<p>This rarely is beneficial work the company should/must do, instead it is promotion driven development.
Hot take: I don't think organizations with less than ~1000 engineers in the org-chart should even have "Principal Engineers".<p>If you:<p>1. Write code<p>2. Build proof-of-concepts<p>3. Fix bugs<p>4. Create designs<p>5. Align work across multiple teams<p>6. Work together on a complex feature, or features<p>7. Identify new directions and opportunities<p>8. Create an architecture<p>Then, congratulations, you're a software engineer.<p>Enough with this self-aggrandizing s*!t already.
> Once you reach a certain level, all problems are solved by people. There is no such thing as a purely technical problem.<p>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.
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!<p>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!
>"The reality of being a Principal Engineer"<p><i>The</i> reality?<p>>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.<p>A 'more mature definition'? What? It's just another buzzword. What a garbage article.