Interestingly it's sometimes harder for companies that already have the role defined than for growing orgs that usually do this JIT as really strong devs top out of senior and realize/decide they don't want to be become managers. I've defined this type of role twice now by using the skills and behaviours of the specific individuals (i.e. things they're already doing), then expanding the scope and sphere of influence for growth areas. It's worked pretty well because typically you should be promoting someone when they're demonstrating performance at the next level, rather than give them a promotion and then see if they're successful or not. The role needs to be vague enough to allow for individual and strategic changes, but defined enough to provide some type of identity. This is hard.
And even more harder is that within a company, those titles are vastly different depending on what team you get hired on to. You could be hired on at a senior level for a given team yet be considered a standard software developer or even associate on a different team.
Case in point, an engineer was hired on in my current company at a Senior role, being even considered for Principal and was subsequently moved to my team. They are now gauged at almost an Associate level when compared to the rest of the engineers on my team and their titles.
The special problem with Sr Engineer is that it’s most people’s title from year 5 to year 40. If you keep improving in your craft then it can be a very wide band.
I for one have no interest in being a tech lead or a staff engineer as all the non technical work exhausts and frustrates me endlessly. I’m still striving to improve every year at engineering and architecture.