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.

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.