Hacker News new | comments | ask | show | jobs | submit login

Though I am a principal that tracks very closely to what this article describes, I think eng organizations need both "broad" and "deep" principal technical roles.

E.g. at that level, the road forks three ways: deep principal ("pure" IC, & an expert in an area), manager, and broad principal (the hybrid force multiplier role).

The tricky part is making sure that the deep role doesn't devolve into promoting people purely on technical merits, and being blind to their cultural impact. Everyone at that level is a role model, for better or worse.

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/guiding others compared to doing it themselves.

Perhaps I'm misunderstanding something about the distinction.

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 everything he knows - and then the company has 10 people but no work for all of them, and they're years later.

Of course, often in such a situation it makes more sense to bring in a consultant for this sort of specialized work, but you don't want to base the core of your product on consultants either.

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.

shrug I guess we'll just have to agree to disagree. Of course nobody wants to build the single most important part of a company around a single person. My point is that for some deep niches, building entire teams around it, and pulling away the people who know most about those things in order to have them 'mentor' a bunch of people who in no way will be able to reach the require depth for a long time just doesn't make sense. And from my understanding, it is this sort of situation the GP was referring to. I don't think, and from my experience which of course suffers from insufficiently large sample size, this situation is not all that uncommon.

(as an aside, I especially object to 'taking advantage of a diversity of perspectives/approaches' being a universal good/requirement. I have seen many cases where having one person just get on with it absolutely beat the design committee. But again this perspective is probably skewed by being involved mostly in deeply specialized numerical software, where exceptional value mostly comes from having both deep domain expertise in something unrelated to computing and deep technical/programming knowledge)

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact