> Silicon Valley will continue to suffer as long as we entrust the future to management consultants and showmen who don’t build software.
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.
> 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.
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".
Agree. Staff/principal level engs should be seen as people with broad responsibility who have unilateral authority to do what's necessary to keep things moving.
It's much bigger than simply decomposing tasks and pairing with juniors all day to get them unstuck.
Same for senior level and mid level. There needs to be less "demonstration of work" that fits the career ladder document but more autonomous work that provides value. That's it.
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.
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.
> 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.
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.
Not really. Google for example will let you stay at L5 (and now even L4) for your whole life. In fact there are tons of such people who have been at Google for say 10+ years and are L5.
(It's a different matter now that you can be laid off. But you won't be dinged for being a well-performing L5).
Google is an extreme outlier as far as employers go. What Google does only has bearing on the employment experience of most of the people here, and software engineers in general, in terms of companies trying to emulate Google by building runways out of bamboo.
Can you name any major company where an L5 equivalent level is not terminal? Many people stay ICT4 at Apple for a long time.
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.
Apple is another outlier. Is Facebook or Amazon going to be the next example?
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 mean, if you feel 4 of the biggest Tech employers are not representative of at least some trends about the industry, then I don't think we can have a meaningful discussion.
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?
Sure. I just think that talking about Google, Apple, etc. is like talking about how your family does things, and then bringing up that the British royal family does things differently.
Boy this is a long screed by someone who doesn't seem to understand that companies' main goal is to make money, not great products. Yes, we are in a period of enshittification, and yes this names a lot of the people and processes responsible. But if you don't understand that the owners and investors are extremely happy with how this has gone so far, you're just shouting at clouds.
I think they know that company’s exist solely to make money and that shareholders love it. Why else would they write this article about how bad that is?
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?