On Being a Principal Engineer • Hacker News Board

Re: On Being a Principal Engineer

#191

Post by kortilla » Sun, Feb 10, 2019, 11:49 PM UTC

2muchcoffeeman wrote: post #144

jameshart wrote: post #120

Earlier quoted context omitted.

The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was nearby when some interesting work got done, and somebody who made something interesting happen . What I’m looking for in a principal engineer is someone who turns good teams into great teams; who steers the organization away from disastrous mistakes; who enables the business to accomplish…

> It’s something that comes hard to senior developers, because we’re all aware that every result is a team win. So when you’re asked about a project you worked on, you’ll tell the story all in first person plural: ‘we had to solve this problem, so we decided to use this approach’. As you said, good outcomes are team efforts. Even your best developer is not going to do anything great if he’s fixing bugs. Less senior d…

Right, a staff level engineer would have been the one to organize the team so the junior developers are picking up the easier stuff and learning the system.

If you think team dynamics just magically emerge that way around a complex technical project, you weren’t as senior as you thought.

Re: On Being a Principal Engineer

#192

Post by solipsism » Sun, Feb 10, 2019, 11:51 PM UTC

roel_v wrote: post #186

solipsism wrote: post #106

Earlier quoted context omitted.

deep principal ("pure" IC, & an expert in an area), manager, and broad principal (the hybrid force multiplier role). I don't understand what a "deep principal" would be. If this person is a SME with incredibly deep knowledge and experience, what an incredible waste it would be to not turn that person into a "force multiplier". I don't care how complex the code is -- that person's impact would be tenfold showing/guidi…

Some technical roles require deep understanding of an extremely niche thing. It just doesn't make sense to have such a person supervise 10 junior and senior people, they wouldn't be able to do any more work than the one guy. For example I've seen a GPU optimization expert who did his PhD on GPU chip design. What sort of 'guiding' others would he be able to do? He could spend 2, 3 years teaching a team of 10 everythin…

In this situation you're describing, a single person is responsible for, and the only person at the company capable of working on, the "core of [the] product"? Unless this is a company of 1, that's absolutely crazy!

There are many reasons you'd want more people (I don't know why you're jumping to the large number of 10... why not 2?) on this "core of the product":

* mitigating risk from the bus factor (https://en.wikipedia.org/wiki/Bus_factor)

* lessening the "information silo" effect (https://en.wikipedia.org/wiki/Information_silo)

* taking advantage of a diversity of perspectives/approaches

If these ideas aren't relevant, then you're probably not talking about a very important part of a company. If they are relevant and this is a critical part of your company, then it makes every bit of sense to build at least a small team around it, thus leading to the "principal engineer" earning his/her title.

What sort of 'guiding' others would he be able to do? He could spend 2, 3 years teaching a team of 10 everything he knows

You make it sound like he'd have to quit his job and become a professor. He would continue to work while teaching the people around him. They might never learn "everything he knows", but that's not a requirement. And there's every chance someone he trains might eventually surpass him. This is exactly what it means to be a Senior+ engineer.

Re: On Being a Principal Engineer

#193

Post by solipsism » Sun, Feb 10, 2019, 11:56 PM UTC

jedberg wrote: post #142

solipsism wrote: post #108

Earlier quoted context omitted.

These companies usually expect advancement, and advancement requires participation-in/production-of higher and higher level design/architecture. You can hang around for a few years, but eventually people are going to ask why you're not progressing. Depending on the FAANG you'll either be stack-rank laid off, or put on a PIP and pushed to voluntarily leave. EDIT to add: On the contrary, non-FAANG is where you want to…

Are you sure he wasn’t making twice as much because he brought more value? There is no reason that your report shouldn’t make more than you. In fact I’d love to manage a team where everyone makes more than me. That would be amazing!

What I meant to say by "just producing code" was that he wasn't having much of an impact on people around him. He was producing a regular amount of good code. He just had been there forever.

I agree completely that there's nothing wrong with managers making less money than people they're managing. The only reason I mentioned that he reported to me is because that's the only way I became aware of his salary.

Re: On Being a Principal Engineer

#194

Post by mlthoughts2018 » Sun, Feb 10, 2019, 11:56 PM UTC

solipsism wrote: post #187

mlthoughts2018 wrote: post #113

Earlier quoted context omitted.

In fact they are not at all related. The engineers on my team bought into the ideas I was bringing as I rolled out implementations that proved the value. Management however was less interested in increased value and more interested in entrenching their existing status and authority levels even if it meant torpedoing obvious and proved-out value-additive / cost effective engineering projects.

Ah, so it wasn't that nobody cared about your perspective. It's that managers didn't care about your perspective. A gem I've picked up from my experience in different kinds of tech companies: Never work anywhere where managers are the ultimate decision makers. At engineer-driven companies, managers are enablers.

That really is a good heuristic. Managers at these companies should be asking, “what do we need to be doing?” and “what do you need to get it done?” If instead they are dictating what to do or only telling you what you can’t have, that is big trouble.

Re: On Being a Principal Engineer

#195

Post by bobmagoo » Sun, Feb 10, 2019, 11:57 PM UTC

This was great, thanks for sharing. I'm currently pointing my career towards principal (security) engineer and would love any similar articles on what it's like and what makes a good one if anyone had recommendations.

Re: On Being a Principal Engineer

#196

Post by vikas5678 » Sun, Feb 10, 2019, 11:59 PM UTC

ryanong wrote: post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

With every organization, once you are part of a product initiative for a few years, this question of "how transferable are my skills to a different domain or company?" is a valid one to ask oneself.

Also, it is easy to get so involved in the daily busyness, that your skills might not be transferable.

I think spending some time in being curious and learning/investing in transferable skills, and building a "brand" of helping others(either online or in person) helps significantly when it is indeed time to pursue that next opportunity.

Re: On Being a Principal Engineer

#197

Post by ajdlinux » Mon, Feb 11, 2019, 12:01 AM UTC

zuhayeer wrote: post #82

ryanong wrote: post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

https://levels.fyi is a good resource to understand where you stand laterally across many companies. Title inflation definitely skews a lot of this. Leveling nomenclature like “principal” and “staff” don’t necessarily correlate across other companies (for example, a senior engineer at Google could come in as a staff engineer or even higher at LinkedIn). But even outside of titles, it’s difficult to become a new playe…

It's very confusing reading tech career advice when you come from a company where "staff engineer" is one level above incoming grads and "senior engineer" takes 10 years...

Re: On Being a Principal Engineer

#198

Post by pfranz » Mon, Feb 11, 2019, 12:03 AM UTC

johnwheeler wrote: post #133

Titles in software are so stupid. Where I work, everyone is “Software Engineer” whether they have 20 months of experience or 20 years. The respect and pay are commensurate with on-the-job performance and output. I know a “principal engineer” who can talk the talk, write books and articles but can’t produce any software of real value, and I work with a guy who’s been working 1/8 as long as me and he’s ten times better…

I see a lot of ridiculous titles, too. I think he addresses that in the "myth of a flat org" section. To continue his "all databases have schemas…even the ones that say they do not" metaphor: over-normalization is bad, too. It's hard prevent muddying titles with things like vanity, but a well-named title gives shorthand in large orgs or when new people come on.

Of course knowing everyone individually is best, but that doesn't scale.

Most of the places I've worked are small to medium. Titles don't matter all that much. One place tried to develop a technical ladder to coincide with their management ladder. I don't think it worked out too well, but they did establish "leads" that were more likely to hop around and mentor. It didn't really change their responsibilities. It just formalized and endorsed what they were currently doing. It really helped to narrow down for people who to go to and allowed those leads to spend time on those kinds of issues.

Re: On Being a Principal Engineer

#199

Post by phkahler » Mon, Feb 11, 2019, 12:07 AM UTC

jameshart wrote: post #120

ryanong wrote: post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was nearby when some interesting work got done, and somebody who made something interesting happen . What I’m looking for in a principal engineer is someone who turns good teams into great teams; who steers the organization away from disastrous mistakes; who enables the business to accomplish…

That's the challenge in all engineering interviews - determining weather they did anything useful or were just on the team. I've had to tell people to stop telling me about "we" and tell me what "you" did. Some people are so caught up in trying to be a team player that they hide their contributions. Others use it to hide their lack of contribution. It's not hard to separate these once you're aware of the issue and start asking the right question "what did you do?"

Re: On Being a Principal Engineer

#200

Post by TuringNYC » Mon, Feb 11, 2019, 12:09 AM UTC

valleyjo wrote: post #90

maxxxxx wrote: post #19

Earlier quoted context omitted.

"But I am also at this weird point where I am not sure if the title of "staff/principle" can be transferred to another company. A lot of the value that I add now is because of the historical knowledge I have. What we have tried as a company, what we haven't, why we built some things the way we did, how things work currently, how the politics works and the trust I have built. " This worries me too. Within my company I…

I’ve seen this happen even within the same (large) company. Someone is a director level who has maybe 100 reports. The entire product gets cut. The IC’a find other jobs within the company. There are only so many Director level positions around and many of them are achieved organically. The ex-director then goes somewhere else as a regular engineering manager unlikely to ever have such a position again.

That sounds like a liquidity problem (not enough positions opening up, and opening up infrequently) rather than a qualification problem (not qualified for director positions elsewhere.) Presumably, if the ex-director waits long enough they may find another director position (or not...)