There’s a body of work studying metrics and performance in software development/engineering.
The push for Lean (by way of Agile) has been more pronounced within IT/tech than any other non-manufacturing industry that I know. We’ve been collecting metrics for as long as I can remember, and reported them.
What is interesting here is that studies out there on knowledge work indicate that most of it is wasteful.
What you need to have for a team to perform is clarity, relevant competency and freedom to do the work - all of which are managements real job to put in place.
This can be hard to grasp coming from sales; the value of flow, the detrimental effect deadlines and hard estimates have on team performance.
The individual team need to identify what they can do to become better and they should measure this. But not in any way should we put this relative to other teams metrics.
For example: one team might frequently end up in wait state due to a stakeholder or customer, when touching specific parts of the code/system. This usually leads to the team picking up new work while waiting, increasing WIP and context switching.
Another team have to deal with a lot of legacy code within their domain, that doesn’t build or test well. This have to be prioritized if this is important software or else this team will be a hog for eternity.
Measuring these things is important, and most definitely possible - you just have to understand the profession.