This is achilles heel of non-tech managers. You can link as many articles like that as you want, it will still be a problem. They may be more aware of it, but it will still be, daily struggle. Non-tech manager should be paired with tech-lead with high trust relationship for this not to be a problem.
This example is just one case/symptom of much larger problem.
Non-tech managers will only see fast progress on combination of:
- poor developer
- doing fast progress
- with shitty code
- on good quality codebase
They will see tech lead/good coder as asshole in general, with poor performance in general, who for some unknown reason is respected for their code and sometimes magically ticks off hard problems quickly which "must be a coincidence, overestimated work to begin with or something like that" on combination of:
- person who actually cares about the project
- who repairs shitty code/tech debt
- who thinks more deeply about the problem
- and as a bigger picture issue, not just ticking off ticket with the lowest resistance possible
- writes good quality code
- if the problem breaks current abstrations, refactors abstration itself
- who cares about readers of the code
People who don't know how to write software have to use "boss" heuristics when determining who is a superstar. Qualities that take prominence over quickly writing high-quality software:
1. "Can do" attitude
2. Never backs down from a challenge
3. Being the glue that holds the company together
4. ...
As you can see these are all the kind of things you can't put your finger on but you "know it when you see it". When they see it, it nearly always looks like their reflection.
This rings very true to me. Unfortunately the subtleties of development like code quality aren't well represented if you only look at cards moving on a board.
In a lot of ways what you are describing is how it should work, that the tech lead works on the hard problems and big-picture problems, like abstractions and architectural issues, as well as mentoring junior devs.
In my opinion any manager (especially a non-technical one) should only measure the team as a unit. This is particularly important when evaluating the performance of a tech lead.
One thing I like to look for is natural lines of conflict in a situation that can arise when different individuals are working towards different goals, and question the underlying reasons why a manager may be acting the way they are. In a lot of cases you can get to a win-win situation if everyone is willing to play ball. Of course if the conflict arises from a fundamental organisational flaw, like poor management methods, or poor company culture, then it is time to move on.
This example is just one case/symptom of much larger problem.
Non-tech managers will only see fast progress on combination of: - poor developer - doing fast progress - with shitty code - on good quality codebase
They will see tech lead/good coder as asshole in general, with poor performance in general, who for some unknown reason is respected for their code and sometimes magically ticks off hard problems quickly which "must be a coincidence, overestimated work to begin with or something like that" on combination of: - person who actually cares about the project - who repairs shitty code/tech debt - who thinks more deeply about the problem - and as a bigger picture issue, not just ticking off ticket with the lowest resistance possible - writes good quality code - if the problem breaks current abstrations, refactors abstration itself - who cares about readers of the code