The reality of being a Principal Engineer

https://leaddev.com/career-paths-progression-promotion/reality-being-principal-engineer

by bitfield • 3 years ago

92 49 3 years ago

azangru3• 3 years 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?

pzh• 3 years ago

In many companies you have to already be performing at the next level to get promoted. Maybe that wasn't the case in her company.

tsss• 3 years ago

Maybe they want to improve their "diversity".

HeyLaughingBoy4• 3 years ago

It's entirely possible to be performing at that level but still not know what the actual (as in written) job requirements are until after you're formally promoted into it. Actually, I'd say it's quite frequent.

jameshart3• 3 years 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• 3 years 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.

stinos• 3 years ago

If you’re the first ‘principal’ engineer in your company of course you don’t know what you have to do to succeed.

It can also go another way: during growth from 1 or 2 people to a small team, at some point a company might start assigning titles to people whoe already know what they're doing. Just because, well, the board or newcomers feel like it's needed or just for clarity or desire to structure things. Which leads to funny situations like me going to look for definitions of what my job might be, finding out that is non-trivial because there are apparently no strict definitions of 'principal engineer' and 'architect' and 'senior developer' and 'developer vs engnineer' and so on. So I ended up 'principal software architect' or something like that, a title which hasn't come up in any conversation ever since nor changed what I do.

azangru3• 3 years ago

If you’re the first ‘principal’ engineer in your company of course you don’t know what you have to do to succeed

On the other hand, if you are the first (and, therefore, the only?) 'principal engineer' in your company, how do you even know whether you have succeeded or not? :-)

silveroriole• 3 years ago

If the expectations for seniors in her company are to close tickets without hand-holding, I wonder what the expectations are for juniors? To occasionally drool onto the semicolon key? It’s odd to see the ‘principal engineer’ in the article talking about soft skills/responsibilities that would have been considered ordinary for a mid-level dev 5-10 years ago.

edgyquant• 3 years ago

Yeah in my recent experience juniors are people who don’t know basic engineering yet and seniors are people who can actually complete a task in their own (with most still having little knowledge of actual advanced programming concepts.)

This is what an industry of outsourcing to “contractors” has done. Companies that aren’t ran by tech people have no idea how to actually hire tech roles and are trusting the contracting firm owners, who I’ve found also have little knowledge how to hire for tech.

frankdejonge• 3 years 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• 3 years 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.

throwawayfaang92• 3 years 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.

rqtwteye3• 3 years 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.

throwawayfaang92• 3 years 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.

vp89894• 3 years 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• 3 years 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• 3 years 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• 3 years ago

Who told you to not do stuff and why are you listening to them? Who do you report to?

vp89894• 3 years 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.

Swizec2• 3 years 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”

timellis-smith• 3 years ago

I'm a principal engineer in a consultancy and can fully associate with this viewpoint.

The org wide work but not org wide alignment rings very true and it occupies much of my free work time trying to solve.

chasd002• 3 years ago

"advanced fixers" is probably spot on. I know many companies will invent titles and hand them out (sometimes pay raises too) in order to keep people from looking elsewhere. My advice is to get close to the money, if you can tie your work and decisions to bank deposits you get a lot more attention.

giancarlostoro• 3 years ago

You should consider taking the initiative to meet with them every week where you get future / current initiatives from them and status on anything they need to do moving those forward. Maintain a spreadsheet you can share with them (or whatever they prefer) and you just get new statuses. The goal is to be on the same page and have some familiarity before you even bother telling anyone else in IT correct? So make it happen.

I say this because I host such a call with our marketing team. I know what's coming down the pipeline before any developer even hears about it. My boss also uses it as an opportunity to interject and remind marketing that they already are trying to push too many initiatives our way, so they have to push some back.

Keep titles, descriptions, projected development start dates, and projected release dates, and a column for all status updates (date them, and put a name to the last status).

donavanm• 3 years ago

Im a principal at AWS. Ive worked across similar org sizes in the past. If we were having coffee Id ask who you report to, as org charts matter to perception. Why your input isnt (apparently) valued for business & technical strategy. Who youre trying to influence, and how. And who told you that you shouldnt be informing those decisions.

SilverBirch• 3 years ago

This sounds very surprising to hear from such a small organization. How many principal engineers are there? Because I would expect from that org size and your seniority you would be the most senior technical person in the company, and reporting at least to the head of engineering/CTO. If you're not on of maybe 3 principal engineers at most, and if you're not reporting directly to a C-level person, then they've probably just diluted the title. If you genuinely are that senior you probably should have the clout to have an open conversation with your boss about making sure you're in the right meetings, and hell - make the meetings! If you get together with a group of engineers across the organisation and define a set of best practices or strategy vision for the company you're making it happen - you don't need an invite. But at this level, you're meant to be doing "influencing without authority" which is bloody difficult and basically means "be inspirational".

mytailorisrich2• 3 years ago

In theory, we aligned the ladders in a manner that Principal sits parallel to Directors in the management track.

That seems extremely high in my personal experience, which is that Principal Engineer corresponds to Manager on the management side.

I'm expected to impact org-wide culture, policy, technology direction, strategy, etc...

Also in my experience this sounds more like Technical Director level as that really having input into directing the org.

An issue is that as an org grows it tends to create more titles in order to cater for egos and the pecking order among people who may have been there for a long time. So you have Junior Engineer, Engineer, Senior Engineer, Principal Engineer, Senior Principal/Associate Director, Director, Senior Director... In which case Principal Engineer certainly isn't on same level as Director on management side.

aix1• 3 years ago

I don't know about other companies, but at Google the titles are as follows:

  Level - SWE ladder - Eng Manager ladder
  L8 - Principal software engineer - Director
  L9 - Distinguished software engineer - Senior director

anontrot• 3 years ago

As a Staff Engineer, at least for now I'd be happy with the money that comes with the Principal title

WastingMyTime89• 3 years ago

In theory, we aligned the ladders in a manner that Principal sits parallel to Directors in the management track.

That’s pure HR talk and is indicative of where you might stand compensation wise. It doesn’t really give you equal standing in the company. It’s not a question of title. It’s the reality of what you can do.

If you think about it, it entirely makes sense. Directors leverage their team to achieve results. You only have yourself and the example you can set.

000ooo000• 3 years 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.

HeyLaughingBoy4• 3 years 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• 3 years 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• 3 years 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.

ThorsBane• 3 years 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.

The reality of being a Principal Engineer

Related Stories