Managing Up
wheresyoured.at
wheresyoured.at
The management fetish is quite apparent.
If I understand it right, this is codified on IC ladders: E4s/E5s are doing the vast majority of actual software development, with E6+ contributing here and there but being a mix of PM/engineer/quality control. Staff eng's are often reminded if they're coding "too much" that they're probably Doing It Wrong and not maximizing impact and should have broken the task up into smaller chunks and distributed them among the team.
It's just gross: actually doing the work is made to seem a bit gauche because hierarchy needs something to distinguish itself otherwise.
Maybe I'm missing something here?
Some nuance. Most people _want_ to be promoted, due to some combination of a) they want to earn more money, b) they want the respect / power that comes with the higher title, c) they actually want to do the job that the higher role is doing.
However, a lot of people aren't necessarily cut out for / want to do the work that comes with higher levels.
If these people were happy to be L5 for the rest of their life and not want a promotion, companies would be happy to employ them at that and have them lead Software projects.
However, they ultimately want ever increasing salaries and more scope, and that's only possible by promoting them. Many people get promoted and realize most of them is now spent not coding and they are less happy, but they have, in a way, Peter Principled their way into their terminal level.
I'm not sure if that's true; many companies have explicit "up or out" policies, and some don't codify it that way, but don't particularly want their employees to find their happy place and stay there.
(It's a different matter now that you can be laid off. But you won't be dinged for being a well-performing L5).
Performing well at a level is not directly related to promotion. You are expected to perform well as ICT4 or L5 (i.e. get good ratings), but promotion is an orthogonal process.
My previous employer had a pretty explicit "up or out" policy, until the CTO - who was the main driver behind it - left. Luckily, this was before I reached my current, happy level. I'm not sure what the L-equivalent is, but I'm a senior software engineer.
I am willing to accept that many employers might still be following the policy you mention. Would you be willing to accept that many employers don't?
I still think it's a bit of a chimera, but hopefully it's vague enough that I can mold it into something sustainable for the long-term.
The companies that have such codified structures of "what it means to perform at a level" don't understand engineering. They don't understand that people at levels could be asked to move across the spectrum of tasks and might need to do different things at different stages of projects for the company.
E.g. if the company needs to improve reliability in the next six months, and your staff/senior engineer has a quick fix, let them fix it quickly . Stop asking them to produce docs, Jira tickets, distribute it all across other engineers etc.
Perverse incentives are a management problem. Don't make engineers do "things at their level".
It's much bigger than simply decomposing tasks and pairing with juniors all day to get them unstuck.
As an example, if a senior engineer spent last 3 months trying to fix dev environment issues at the expense of RFCs, commits, bug fixes (but at the direction of management) - This is fine and should be recognized.
Recognizing only activities enumerated in some BS levels document is a fools errand that fails to recognize that different stages of different teams and different projects may require different behaviors.
Sounds like what he really meant to write in that gerund was "ini", not "nni"...