Hacker News Reader

Comment by johnwheeler | Hacker News Reader

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.

View on HN

>>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 that’s been working 1/8 as long as me and he’s ten times better.

Perhaps you're measuring value too narrowly. A principal engineer can act as a force multiplier for the entire team, even if they themselves are no longer efficient individual contributors.

Can you elaborate a bit more on what you mean by "force multiplier" please?

Someone who leads, inspires, gets people working at their best.

Andy Grove talks about this in his excellent High Output Management, where he asks the question: how should knowledge managers (senior ICs) and people managers spend their time?

His answer is: on high leverage activities. Instead of fixing a small bug that affects a few customers, fix a big one that impacts revenue; train others to be better engineers, multiplying their future output; improve the process your team uses to build product. Essentially, look for activities that multiply output, rather than add to it.

They multiply the skills of the people around them. They make everyone else better. It can be via a tool, a process, good code review, opening a path of knowledge, being supportive, giving confidence, listening well, or any number of other things.

Gandalf in the battle of Minas Tirith is a huge force multiplier. He embiggens the courage of everyone near him and makes them fight harder and better.

I would argue that a principal engineer who can’t function as an individual contributor is a less credible leader than one who could.

I didn't say they can't function as an individual contributor. I said they can't function efficiently as one. Meaning: the opportunity cost would be too high, since the alternative is that they help their more junior team members grow and also help the company make the right decisions when it comes to things like system architecture, tech stacks, features, etc. Those types of contributions can be several times more valuable to the company.

Maybe what John is getting at is while a Principal can do that for a while, at some point their tech chops will get out of date and rusty, both in terms of industry knowledge and the company’s internal stack and best practices. At that point they may lose the respect of more junior engineers, which is a poor sign for company culture.

A senior IC that codes can stay relevant longer. The act of coding forces you to keep up.

In my experience a 'principal' security consultant (I'm in infosec) is the same as the principal engineer you mention. They talk a lot but are so busy, they delegate everything and are very out of practice. If any actual work needs doing, they delegate not only because they don't have time but also because they would need to relearn and look up a lot of things. The junior and senior roles, however, are often pretty accurate descriptions, though the biggest difference is often in management skills and not in technical skills. Some juniors can't do anything and some are as good as some seniors will ever get, but in terms of talking to higher ups or negotiating between companies, there is usually a clear difference. And if a principal consultant still has technical skills, it's not noticeably better than a senior's.

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.

*her for the record

Unless all your company's projects are uniform, there's probably some informal ranking of who can be trusted with the biggest and gnarliest objectives. For us, the title Principal just formalizes your position at/near the top of that ranking for the entire engineering organization. For a division it may be Staff. For a line manager it's Senior.

Where do you work?

Reply on news.ycombinator.com