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’.
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.
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.
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.
> 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.
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’.