The reality of being a Principal Engineer | Hacker News Reader

The reality of being a Principal Engineer

leaddev.com

92 pointsbitfield49 comments

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.

"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.

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.

> 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”

I am talking about non-technical roadblocks. Cross-team product engineering projects can sometimes involve ownership changes which affects the company in non-technical ways. Some influential product/design lead might lose some control of their UX, some engineering team will become "redundant" and need to be reorged or refocused to other types of work etc ...

You might be able to help with those politics but it's probably also not your job to do that. That's partly why actual engineering and product managers are on-staff to focus on things like that.

I think it is your job to deal with those politics at that level. At the very least to bring them to the attention of the people who can implement a solve and to make a case for why your thing should be solved over other things.

If the principal engineer doesn’t champion technical issues created by org design, then who?

Ownership disputes often stem from non-technical issues. Two orgs with different agendas might feel they require ownership of a given piece of tech to drive their own agenda forward. This can be expected to happen in firms that have multiple product lines but perhaps some shared functionality across them, as just one example.

I sense that we have different experiences and so can't relate to each other's points without getting more specific so I will make this my last reply.

I will just say that a common trope I've seen in online discourse on this subject is basically that you aren't a real <verySeniorIC> unless you are effectively doing the job of (or heavily carrying) your peers in the org chart who explicitly hold management roles. I broke my own back, metaphorically, trying to live up to that ideal with nothing to show for it and at the expense of the output that was expected of me and so I reject that notion. The <verySeniorIC>s Ive seen who hold those titles with longevity aggressively delegate politics to management and focus on the tech.

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.

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".

> 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.

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

Oh I see, they have Staff and Senior Staff between Senior and Principal, and no Director, which makes Principal very senior compared to my personal experience.

The principle remains, though, that titles multiply to make people feel good in the pecking order.

> 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.

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).

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.

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

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

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.

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.

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?

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’.

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.

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.

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

they described themself as a 'senior developer' but said they have 15 years experience. That's more experience than I would expect for someone with the job title of 'Senior Engineer'. Their job title might well be higher level - maybe 'Staff'. All these job titles apply to 'senior' people.

I always considered the Principal title to imply an ownership position.

> 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? :-)

the further up the org chart you go the less clear success becomes. Once you're doing things at a strategic level even the clearest signals trail your decisions by 6 months to a year at least. The stakes get high when you don't know if your decision is right or not until a year later and everyone is suffering with no way out because it turns out you were wrong.

You simply reason from first principals

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.

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.

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.

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.

Maybe they want to improve their "diversity".

I think it's fair to say there's a conversation to be had about this in general, not coming down on it either way... but there's zero reason to throw that particular grenade here.

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.

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.

"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.

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.

Why do you think you need to be a sociopath to do that?

"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.

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.

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.

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.

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.

> 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.

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!

>"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.

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.

Reply on news.ycombinator.com