In order to add value to a dev team as a manager, one must have an intimate understanding of the work developers do. There isn't any value in abstracting away from that work when evaluating the contribution of team members.
"Context, action, outcome" is a sufficiently standardized formalism for evaluating performance (assuming outcomes are measured in terms of business value). Accurately reporting context, action, outcome requires understanding both what devs do, why they do it, and how it ultimately produces business value. There's no shortcut. If your management can't meaningfully do that because they are non technical or managing too many people, or whatever, then they are actively harming your team and should be removed with prejudice.
There is no reasonable way to conclude that devs can be effectively measured with garbage stats. Even suggesting it seriously indicates incompetence or laziness.
"Context, action, outcome" is a sufficiently standardized formalism for evaluating performance (assuming outcomes are measured in terms of business value). Accurately reporting context, action, outcome requires understanding both what devs do, why they do it, and how it ultimately produces business value. There's no shortcut. If your management can't meaningfully do that because they are non technical or managing too many people, or whatever, then they are actively harming your team and should be removed with prejudice.
There is no reasonable way to conclude that devs can be effectively measured with garbage stats. Even suggesting it seriously indicates incompetence or laziness.