Do not track dev productivity. That is a concern of the engineering manager, not the PM. If a product manager needs analytics, dig into what they are trying to accomplish. Most of the time, they are trying to understand delivery velocity in order to plan roadmaps and communications, and do not truly care about productivity of individual devs. This is why Scrum got popular - not because it is good for the devs, but because it is predictable for the PMs.
So you are on the right track of pulling info from your system. Continue to treat this as a consulting gig - work with them on metrics they can pull from your systems to give them the answers they really want. Depending on how easy they are to work with, and how open to change, suggest that they change their communication patterns, and do not promise timelines to stakeholders or customers. If they limit customer transparency to roadmaps and priorities, it is amazing how little they need to track from the devs. And in my experience, the increased autonomy that gives the dev team results in feaster delivery, anyway.
Most systems I’ve seen can be easily gamed. The ones who don’t waste time trying to game the system to look more productive are probably your most productive devs.
If they want to turn it into a game, I'll play the game.
Back when they were tracking it, I would split a PR into as many commits as possible and put in a commit on the weekends too so it that it would show me committing 7 days/week while the tech lead would commit 2-3 days/week. Also I'd make sure to hold back the commits done in the WFO days and hammer them in on the WFH days. And I'd be extra sure to have more stuff in closer to performance review so it was an upwards trend.
One dude in my team would comment "LGTM" on each PR to boost PR comments.
Thankfully, management were not dumb and didn't associate bonuses or anything to it. They were used only to evaluate policies like how much to refactor and whether 2 meeting days were more efficient than daily meetings. Or checking on someone they suspected of quiet quitting. After we got the data, we just unsubscribed it
For me it is understanding the task and actively asking in certain intervals that don't hurt the zone. No measure can replace understanding and direct communication.
What exactly are you trying to measure? What is productivity? The only one that ever made sense to me was predictability. If someone says it would take x time it should take x time. But even that can be gamed. Trying to measure dev productivity analytically has been historically a fool's errand. It never makes more money for you.
Do not track dev productivity. That is a concern of the engineering manager, not the PM. If a product manager needs analytics, dig into what they are trying to accomplish. Most of the time, they are trying to understand delivery velocity in order to plan roadmaps and communications, and do not truly care about productivity of individual devs. This is why Scrum got popular - not because it is good for the devs, but because it is predictable for the PMs.
So you are on the right track of pulling info from your system. Continue to treat this as a consulting gig - work with them on metrics they can pull from your systems to give them the answers they really want. Depending on how easy they are to work with, and how open to change, suggest that they change their communication patterns, and do not promise timelines to stakeholders or customers. If they limit customer transparency to roadmaps and priorities, it is amazing how little they need to track from the devs. And in my experience, the increased autonomy that gives the dev team results in feaster delivery, anyway.
My job just does it via Jira tickets, but yes, anything can be gamed
Most systems I’ve seen can be easily gamed. The ones who don’t waste time trying to game the system to look more productive are probably your most productive devs.
If they want to turn it into a game, I'll play the game.
Back when they were tracking it, I would split a PR into as many commits as possible and put in a commit on the weekends too so it that it would show me committing 7 days/week while the tech lead would commit 2-3 days/week. Also I'd make sure to hold back the commits done in the WFO days and hammer them in on the WFH days. And I'd be extra sure to have more stuff in closer to performance review so it was an upwards trend.
One dude in my team would comment "LGTM" on each PR to boost PR comments.
Thankfully, management were not dumb and didn't associate bonuses or anything to it. They were used only to evaluate policies like how much to refactor and whether 2 meeting days were more efficient than daily meetings. Or checking on someone they suspected of quiet quitting. After we got the data, we just unsubscribed it
For me it is understanding the task and actively asking in certain intervals that don't hurt the zone. No measure can replace understanding and direct communication.
What was it about when a measure becomes a metric it ceases to be a good measure, or something like that?
Target as in "optimization target".
Measures and metrics (the formal mathematical meanings) are probably considered equivalent by managers.
Define dev productivity.
What exactly are you trying to measure? What is productivity? The only one that ever made sense to me was predictability. If someone says it would take x time it should take x time. But even that can be gamed. Trying to measure dev productivity analytically has been historically a fool's errand. It never makes more money for you.