In all of "career frameworks" I've seen, people who actually build things are labelled as "juniors" and "middles" while those who navigate office politics and ass-kissing are "seniors" and above.
But beyond that there's way more to building than writing code or laying bricks. These aren't the career defining challenges you think they are. Solving problems is, and most problems in any non-trivial activity are not solved with code or more precise brick placement.
So while you should be able to code and lay bricks enough to be comfortable in any conversation in the team, you'll get away with not being the best at that if you have skills useful for the bigger picture.
When someone conceived the whole thing and considered all the implications properly from the start, when they "politicked" their way into smoothing the path for the builder to walk and build on, when they "ass-kissed" to get the resources they need, then they're certainly a few steps ahead of any junior or middle even before writing a line of code.
writing code != building things.
In my org, seniors spend a lot less time building things: writing components, etc. They do spend a lot of time navigating office politics. But they are engineering specific office politics: how does system A interact with system B? What are the architectural implications? Ownership of long term data and technical and business strategies?
The "art" of negotiation can be ass-kissing but quite often genuinely with the goal to advance the projects they own and the enablement of the "people who actually build things", which at some point also involves the seniors. You need to build raport and relationships to negotiate seriously.
At the same time, having seniors involved in more abstract discussions before implementation should also lead to better end results. That being said, having my engineers be involved in "ass-kissing" as you put it is honestly not a good use of their time. Leave office politics to engineering managers and project managers, in my opinion.
Getting that spec is damned hard.
What do i mean by spec? Basically are you going to build the right thing. A hard problem - if you think it’s easy, it more than likely means you didn’t understand the problem.
The reason pinning down a spec is so hard is because at the macro level, there are very few actual solutions - mostly only trade-offs are available to work with.
Once it’s been captured what needs to be done (spec) enabling the rest of the team (execute) is comparatively easy.
Fail to spec, and the team can’t execute. They don’t know what needs to be built.
In my forty year career I never saw a spec that was anywhere near accurate or complete.
A senior developer is not a passive position.
I'm sorry, but it's hard to take your comment seriously when your definition of "spec" is AoC puzzle.
Promotion is an inherently political process. "Impact" is really short for "impact on the business leaders' opinion of me".
I think it's a bad thing when a promotion process that is political, pretends to not be political by dressing itself up with flowery language. What it leads to is engineers burning themselves out trying to deliver real value, then getting passed up because they didn't make the right appeals to the shadow council.
If we all know the process is political then we should at least work toward transparency, so that people know that it's not enough to work hard and deliver results, you also have to advertise and network yourself.
In order to bring thousands of engineers to bear on a business’s problems you need people figuring out what everyone should be building.
Basically if your leveling system says "A company of all Staff+ would write no code and go out of business" then your leveling system is bs.