I think the whole reason the question seems hard to answer is that whatever metrics you collect, they will likely never correlate to "team performance". A team doesn't perform well because their code output takes on specific characteristics. They perform well when they work in unison.
And if by "team performance" you actually mean individual performance of each team member, then the act of measuring these things might make it impossible for them to work well together. Because then they become competitors trying to outdo each other (or avoid blame) on metrics; it is not in their best interest to help each other.
I was recently tasked to do a "performance review" of my software team. And because I'm old and I'd rather find another job than do something that I consider dehumanizing, I asked them how they wanted to be evaluated (in the context of avoiding a manager passing a subjective judgement). And we had an ad hoc design exercise. What we ultimately came up with was to identify the activities within our department. Then identify which activities (on which products) each team member participated in. And the level at which they participated (Leader, Contributor, Participant). In the end each "review" read almost like a resume. Since it also identified all department activities, it provided team members a look at the different areas they could choose to grow into. It was also pretty uncontroversial. "Hey, didn't you go solo to those customer meetings about the new features they want? Ok, so you were a Contributor in Business Analysis for that product." We even referred to our previous sprints to fill it out. As a hypothetical exercise, we did a retroactive review for last year, and you could clearly see the progress between years. You could also see who was doing different activities on the team and infer how people interacted. If you brought a new manager on board or had to justify some decision, these reviews would tell loads more about the team than any code metrics ever could. And the activities themselves are researchable as to market value.
That is actually very helpful a lot of good food for thought in your experience! Now the question is more about very large codebase with 10+ different teams contributing to it. so the idea here is to look on performance of whole department and no one in particular.
Ah, I appreciate your response. :) So the primary question I would have if tasked with this is Why? and what kind of actions is this data informing? I'm having trouble imagining how aggregate performance across a dozen teams will be actionable. (Like, what kind of department-wide policies could result from it?) But admittedly, my imagination is not very broad.
Oh I don't see it as policies in any way, it s more of a tool to show people that we are getting better/ worst and I do believe that engineers prefer to work in clean== better quality code, so having this score should reinforce the feeling of project moving in the right direction or reconsider coding practices / pr review system.
My take on this is that the only way to ensure quality work is done is to hire people who actually care and can work well with others. These people are in short supply and/or are hard to find through current hiring practices. So, the next best option is to keep a pulse on how the product is doing.
Revenue
Support volume
Bugs filed
User errors (e.g. API request rejection)
Time spent on each screen
If a lot of people are calling support about specific processes, the natural instinct is to write documentation to explain. But probably a better strategy is to try to redesign it so it needs as little explanation as possible. A lot of managers fall into the trap of judging progress (or being evaluated) by amount of features produced. And they don't want to go back and change a feature that is already there. But sometimes it would make a bigger impact than adding something new.
But I digress. The other thing I wanted to mention is that even being aggregate metrics, if they are going to cause coding practice / PR review changes for example, people are going to game them. At the end of the day your ICs (even ones that genuinely care) will usually look at these as overhead (read: impediments) to doing their actual work. So their best interest is served by keeping code metrics looking good, regardless of whether they reflect any reality. And they will ultimately become a source of false confidence to management.
The only real way to know how the teams are doing is to have someone on the teams tell you. Traditional top-down mgmt structures create a separation that makes it hard for managers to actually be a part of the team and know how it's really doing. I think that's a big reason of the push for servant-leadership nowadays. Everybody appreciates the manager who is always there to lend a hand and keep them informed. But everybody would rather interact as little as possible with that manager who is pushing new initiatives on them.
I apologize, as I may have vented a little previously. Thank you for being a good sport and genuinely seeking answers and improvements -- for being someone who cares.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the whole reason the question seems hard to answer is that whatever metrics you collect, they will likely never correlate to "team performance". A team doesn't perform well because their code output takes on specific characteristics. They perform well when they work in unison.
And if by "team performance" you actually mean individual performance of each team member, then the act of measuring these things might make it impossible for them to work well together. Because then they become competitors trying to outdo each other (or avoid blame) on metrics; it is not in their best interest to help each other.
I was recently tasked to do a "performance review" of my software team. And because I'm old and I'd rather find another job than do something that I consider dehumanizing, I asked them how they wanted to be evaluated (in the context of avoiding a manager passing a subjective judgement). And we had an ad hoc design exercise. What we ultimately came up with was to identify the activities within our department. Then identify which activities (on which products) each team member participated in. And the level at which they participated (Leader, Contributor, Participant). In the end each "review" read almost like a resume. Since it also identified all department activities, it provided team members a look at the different areas they could choose to grow into. It was also pretty uncontroversial. "Hey, didn't you go solo to those customer meetings about the new features they want? Ok, so you were a Contributor in Business Analysis for that product." We even referred to our previous sprints to fill it out. As a hypothetical exercise, we did a retroactive review for last year, and you could clearly see the progress between years. You could also see who was doing different activities on the team and infer how people interacted. If you brought a new manager on board or had to justify some decision, these reviews would tell loads more about the team than any code metrics ever could. And the activities themselves are researchable as to market value.
Anyway, my 2 cents.
That is actually very helpful a lot of good food for thought in your experience! Now the question is more about very large codebase with 10+ different teams contributing to it. so the idea here is to look on performance of whole department and no one in particular.
Ah, I appreciate your response. :) So the primary question I would have if tasked with this is Why? and what kind of actions is this data informing? I'm having trouble imagining how aggregate performance across a dozen teams will be actionable. (Like, what kind of department-wide policies could result from it?) But admittedly, my imagination is not very broad.
Best wishes!
Oh I don't see it as policies in any way, it s more of a tool to show people that we are getting better/ worst and I do believe that engineers prefer to work in clean== better quality code, so having this score should reinforce the feeling of project moving in the right direction or reconsider coding practices / pr review system.
My take on this is that the only way to ensure quality work is done is to hire people who actually care and can work well with others. These people are in short supply and/or are hard to find through current hiring practices. So, the next best option is to keep a pulse on how the product is doing.
If a lot of people are calling support about specific processes, the natural instinct is to write documentation to explain. But probably a better strategy is to try to redesign it so it needs as little explanation as possible. A lot of managers fall into the trap of judging progress (or being evaluated) by amount of features produced. And they don't want to go back and change a feature that is already there. But sometimes it would make a bigger impact than adding something new.
But I digress. The other thing I wanted to mention is that even being aggregate metrics, if they are going to cause coding practice / PR review changes for example, people are going to game them. At the end of the day your ICs (even ones that genuinely care) will usually look at these as overhead (read: impediments) to doing their actual work. So their best interest is served by keeping code metrics looking good, regardless of whether they reflect any reality. And they will ultimately become a source of false confidence to management.
The only real way to know how the teams are doing is to have someone on the teams tell you. Traditional top-down mgmt structures create a separation that makes it hard for managers to actually be a part of the team and know how it's really doing. I think that's a big reason of the push for servant-leadership nowadays. Everybody appreciates the manager who is always there to lend a hand and keep them informed. But everybody would rather interact as little as possible with that manager who is pushing new initiatives on them.
I apologize, as I may have vented a little previously. Thank you for being a good sport and genuinely seeking answers and improvements -- for being someone who cares.