In most cases there becomes a point of diminishing returns in terms of pure engineering skill. At that point it is far more efficient to be able to improve over all output, not just your own. That's where these skills come in.
Think of these as things which become critical after the engineer has mastered the skill of solving a hard problem.
> At that point it is far more efficient to be able to improve over all output, not just your own.
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.
As I have learned in offshoring projects, that is a matter of scale, you just need to scale the amount of juniors carring stones, the quality is overrated as long as the product line (completly unrelated to software) keeps working.
Yes but someone who can't effectively determine what problems need to be solved doesn't scale, not does this engineer scale to problems big/hard enough that they require more than one person
A senior doesn't have to be a leader.