Hacker News Reader

Comment by azangru | Hacker News Reader

Amusingly, she writes:

> Once I became a principal engineer, it quickly became clear to me that my job involved a lot more than closing tickets and writing code to achieve things.

If we take this sentence at face value, are we to conclude then that _before_ she became a principal engineer, it was not clear to her what the role would entail? And if yes, then what would be the process that made it clear to her after she became a principal engineer?

View on HN

It’s way more common than you might think for companies to give people job titles in order to figure out what the job involves.

If you’re the first ‘principal’ engineer in your company of course you don’t know what you have to do to succeed. And even if there are already a couple of people with that title, there’s no guarantee that they know how to actually make a difference at that level - they’re figuring it out too. Or that what they do to succeed in their division will work just as well in yours.

A big part of being put in a leadership position is precisely that if you have questions like ‘how do I actually make a difference in this company on this dimension?’, the answer is: ‘we don’t know. That’s what we hired you to figure out’.

It doesn't help that this is not a standard position across the industry. Show me 5 different staff and principal engs and I'll show you 5 different sets of expectations and responsibilities. It's better now than a few years ago at least.

There was a thread on HN recently [0], in which many expressed an opinion that "senior developer" role is a "force multiplier" involving semi-managerial and mentoring responsibilities. It amused me, therefore, to read that in the author's case, being a senior developer presumably meant just, quote, "closing tickets and writing code to achieve things", i.e. being an actual developer.

[0] - https://news.ycombinator.com/item?id=34628933

they described themself as a 'senior developer' but said they have 15 years experience. That's more experience than I would expect for someone with the job title of 'Senior Engineer'. Their job title might well be higher level - maybe 'Staff'. All these job titles apply to 'senior' people.

I always considered the Principal title to imply an ownership position.

If you’re the first ‘principal’ engineer in your company of course you don’t know what you have to do to succeed.

It can also go another way: during growth from 1 or 2 people to a small team, at some point a company might start assigning titles to people whoe already know what they're doing. Just because, well, the board or newcomers feel like it's needed or just for clarity or desire to structure things. Which leads to funny situations like me going to look for definitions of what my job might be, finding out that is non-trivial because there are apparently no strict definitions of 'principal engineer' and 'architect' and 'senior developer' and 'developer vs engnineer' and so on. So I ended up 'principal software architect' or something like that, a title which hasn't come up in any conversation ever since nor changed what I do.

> If you’re the first ‘principal’ engineer in your company of course you don’t know what you have to do to succeed

On the other hand, if you are the first (and, therefore, the only?) 'principal engineer' in your company, how do you even know whether you have succeeded or not? :-)

the further up the org chart you go the less clear success becomes. Once you're doing things at a strategic level even the clearest signals trail your decisions by 6 months to a year at least. The stakes get high when you don't know if your decision is right or not until a year later and everyone is suffering with no way out because it turns out you were wrong.

You simply reason from first principals

If the expectations for seniors in her company are to close tickets without hand-holding, I wonder what the expectations are for juniors? To occasionally drool onto the semicolon key? It’s odd to see the ‘principal engineer’ in the article talking about soft skills/responsibilities that would have been considered ordinary for a mid-level dev 5-10 years ago.

Yeah in my recent experience juniors are people who don’t know basic engineering yet and seniors are people who can actually complete a task in their own (with most still having little knowledge of actual advanced programming concepts.)

This is what an industry of outsourcing to “contractors” has done. Companies that aren’t ran by tech people have no idea how to actually hire tech roles and are trusting the contracting firm owners, who I’ve found also have little knowledge how to hire for tech.

In many companies you have to already be performing at the next level to get promoted. Maybe that wasn't the case in her company.

Maybe they want to improve their "diversity".

I think it's fair to say there's a conversation to be had about this in general, not coming down on it either way... but there's zero reason to throw that particular grenade here.

It's entirely possible to be performing at that level but still not know what the actual (as in written) job requirements are until after you're formally promoted into it. Actually, I'd say it's quite frequent.

Reply on news.ycombinator.com