Then you can see where in the first scenario you had to hire two people and only one in the second case, and in the second case you're getting even more additional value with your senior engineer doing partial manager-y things. So now the second individual is maybe 2x as valuable to the company as the first, and you can see it's a no-brainer for the company which to go with.
A senior doesn't have to be a leader.
Think of these as things which become critical after the engineer has mastered the skill of solving a hard problem.
There's only so much you can improve if the output is low. After all, if all your seniors spend their days managing, who does the actual coding? Juniors. And what happens with them after they've "mastered the skill of solving a hard problem"? They become seniors, stop coding and start teaching the next batch of juniors.
This seems like purposefully limiting the quality of the work, and increasing the time it takes.
> there becomes a point of diminishing returns in terms of pure engineering skill
It's quite surprising, if we think about it - software engineering is about as close as you can get to pure productivity multiplier. It shouldn't have diminishing returns, not so soon. It should have exponential returns. After all, the same skills that can be applied to a problem, can be also applied to a meta-problem of solving the problem faster.
By that town, all managers need to go do some technical work and get better at that.
Being mediocre at coding is fine if you can make up for it with other skills. Being downright bad is not.
Same thing for running meetings, writing passable English, being able to explain technical concepts to laymen and so on.
These are more lead developer skills.
#1 Running meeting and knowing how they work is a really good skill for every one to have
A lot of growth I've seen is about having people get opportunities to do things more commonly done by people at higher levels. While most design documents are written by seniors or above sometimes mid level/junior engineers get an opportunity to write one and all design documents get a lot of feedback anyway.
I was not familiar with the term, but useful concept. Reminds me of something I read recently about the “Goat”, the West Point cadet finishing at the bottom of his class.
I don't think you can. You can be good developer and amazing and mentorship or social aspect. But if you are mediocre one, you can teach others what you dont know.