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.
The way you describe a technical team is how high-performing sales teams operate. Millions of dollars are at stake, we will rape every angle till it's raw to make sure we close the deal. I know a customer's birthday, their children's sports, their hobbies, and what they give a fuck about in a non-invasive way because at the end of the day a customer buys because they trust that you will deliver and not because you have a bunch of PhDs in Comp Sci. I closed a multi-million dollar deal because my competitor didn't pick up his phone at 8pm when his car was towed after a day of talking to press. He left his wallet in his car and couldn't get it out of the impound lot. Luckily he had my number and I bailed out his car with my corp CC. Meanwhile, our competitor thought the deal was sealed, but I fucking snatched that from their mouth and ran the most successful campaigns in company history. Sondors e-bikes if anyone is curious.
This is good sales work, but far removed from knowledge work.
They need to be treated differently as your driver probably differs by miles from what drives my team of system developers. For someone in sales, maybe with compensation in the form of commission you have clear metrics every month. I can have guys sit around and think for a couple of months with the benefit of us staying agile and malleable two years from now. This is where the disciplines differ by a lot and must be treated and measured differently.
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.