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.
Politics, nepotism, ass-kissing, or incompetence exist everywhere and at every level. Just the byproduct of not living in a utopia.
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.
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.
I do think it's a bad thing, but not for the reason you think.
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 the orgs that I have worked in, there were very few developers who could actually handle coding complex features and applications. The people navigating the office politics are important, but let's not pretend they are actually capable of pulling off the work. They can understand that "system A interacts with system B" at a high conceptual level, but are not capable of digging down at the detailed level necessary to make it happen.
My current org is the opposite. Loads of Very Smart Developers all building supposedly brilliant stuff in isolation for their fiefdom without any regard for how it fits into the bigger picture.
I'm not the one you responded to, but I definitely feel like it's not necessarily a "good" thing or a "bad" thing. Having a senior be more involved in writing some functionality should mean more maintainable code with more complex issues factored in to the solutions, which should mean better predictability when it comes to planning new work.
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.
Writing code is easy when you have a spec to work to. It more or less writes itself - see <30second submissions to Advent of Code last month (likely AI - but it doesn’t matter how it was written for this point; just that it was written and solved the spec).
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.
Sorry, I think that's delusional and if anything maybe only applicable to the very narrow and simple problem space. Nobody writes out the "spec" for the next best inference engine or the next best distributed database.
The senior needs to figure out that the next best inference engine or the next best distributed database are what needs to be built in the first place (or beating about the bush as you said). That’s hard. Lots of conflict to be explored.
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.
> Writing code is easy when you have a spec to work to. It more or less writes itself - see <30second submissions to Advent of Code last month (likely AI - but it doesn’t matter how it was written for this point; just that it was written and solved the spec).
I'm sorry, but it's hard to take your comment seriously when your definition of "spec" is AoC puzzle.
The more senior you become, the more you are responsible for building the right thing the right way. Necessarily this might involve what you call "navigate office politics and ass-kissing" but others might just call talking to your colleagues and planning.
Agree with the sentiment, but senior, staff, platform, architect, etc can also be granted on merit in orgs with engineering segregated. Playing the high school drama games does get you places though.
Yeah that's a problem -- Here's my law for honest leveling - If somebody of a given level is incapable of doing something of the level below them, then your leveling system is broken (and they should be in a separate track).
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.
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.