[notmyfuture]

I’m a manager of ~25 developers (who report through a few leads). I also come from a dev background. IMO metrics are dangerous, but can also be useful. Often I find basic code metrics useful as smell tests, but would never use them alone, wouldn’t set them as goals, and wouldn’t use them alone to rank performance in a team.

If someone has a very low number of commits relative to others on their team, I’ll investigate deeper - review a few Pull Requests, check if they’re working on something outside source control etc. sometimes I find problems, other times not.

I’m curious what people think of this approach?

[_Marak_]

I would think this is a common approach. I use the same approach. Scales up to hundreds of developers.

I do generally try to enforce the goal that on any working day there should be at least one commit from the developer. If I notice a developer is consistently missing this metric it usually indicates trouble in the project they are working on or that the developer is just not delivering enough.

[lazyant]

I agree, like many tests (IQ for ex) it's only useful to identify the outliers and investigate further.