5 ms·
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 t
by md5person 8y ago
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).
- throwaway98988 8y agoUnfortunately, 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.
- scarface74 8y agoI 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.
- hk-mars 8y agoSo how to improve this situation? I think it’s human problem :)
- mixmastamyk 8y agoIf you can't convince them, you might try the boss.
- nilkn 8y agoThis 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.
- 6ak74rfy 8y agoThis sounds like a great guy. Can you give some concrete examples of various techniques and technologies that he brought to the table?
- mixmastamyk 8y agoFew 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.
- nambit 8y agoIf you need a principal engineer to tell you to write unit/integration tests, that speaks volumes about the quality of engineering below him.
- Twirrim 8y agoInteresting. 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.
- stonewhite 8y agoI 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.