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

I appreciate the idealistic take on what a "principal" role should be like, but in all actuality, principal engineers are commonly the ones that simply stayed there long enough (ie. to survive multiple re-orgs), and played their politics cards wisely. They were playing the title game. Often, their work is invisible to most. They perpetuate tribal knowledge, and have trouble letting go of the past and accepting change.

You'll notice plenty of comments here from people who claim to be principal engineers - stating that they "kinda follow it all". I wish we could talk to their colleagues though (the juniors, seniors, PMs, tech-leads, support/escalation engineers, as-well as other principals).

This sounds like standard title inflation, and it's not restricted to just technical ladders. It's certainly a problem, but I don't think we should discount the idea of principal engineering roles just because job titles can be misused or abused.

The company I'm at has a single principal engineer. He was hired externally. Within a year of starting, he'd had a bigger impact across teams than the CTO in the same time period. He doesn't necessarily write tons of code, but he's also not sitting in an ivory tower telling other developers what to do. Rather, he very quickly got in tune with the sorts of technical problems being faced by basically every team and developer at the company and started introducing various techniques and technologies to resolve pain points around the organization. Before long, we were doing things that wouldn't have even been possible before.

This sounds like a great guy. Can you give some concrete examples of various techniques and technologies that he brought to the table?

Few places are hitting 12 on the Joel Test twenty years on. That, unit/integration tests, and a "message bus" with metrics dashboards and you're above average.

If you need a principal engineer to tell you to write unit/integration tests, that speaks volumes about the quality of engineering below him.

Unfortunately, I have to agree. I've been hired into an informal "staff/principal" role for my part of the organization and it's simply impossible to work. The other staff/principal engineers I see here are exactly how you describe. They are against anything that will make their roles as "the oracle" less important.

Documentation is such a mess because of that and the onboarding process specifically says there are a lot of "oral history" newcomers have to learn before doing anything meaningful.

I don’t get that but it does happen. I don’t want to be stuck working on the same project forever and the only ways I can avoid that is by documenting everything, using off the shelf widely used frameworks where documentation is available and cross training.

So how to improve this situation? I think it’s human problem :)

If you can't convince them, you might try the boss.

I do agree with your sentiment and I am always genuinely curious about whether an organization chart would stay the same if the whole team was fired and re-hired. If not, then how can you counteract this organizational-rot problem. Also how to understand if you yourself is the part of this problem.

Interesting. At both Amazon and my current employers, engineers at that level have to be able to both talk-the-talk and walk-the-walk. No resting on laurels and being buried in the past.

Anecdotally, one of the distinguished engineers at my current place came from a similar role in Google. They left Google because they kept putting them and a number of other distinguished engineers on products and projects that would never see the light of day, or be turned in to an actual project.

Applications are open for YC Summer 2019

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