Hacker News new | ask | show | jobs
by thenerdhead 1574 days ago
> Each organization can set a wide range of metrics to follow every week, such as:

> Number of commits.

> Average commit size.

> Frequency of code reviews.

> Number of code reviews.

> Time to review.

> and so on...

No. This has been tried many times and companies think this is how you measure productivity, but it is not even sustainable. Developer productivity is not about moving the needle, it is about outcomes, and not outputs.

An outcome is finally merging an unsustainable PR that has sat for a month. It is not how many comments, reviews, meetings, or commits needed to get to the outcome.

The only people I know who want to implement these terrible measurements are the type of people who have ambitions as large as Mount Everest but die on the decline back down. The real goal is to be more like a f1 pit crew where you leave out the metrics and end up performing better than if you measured them.

2 comments

>Developer productivity is not about moving the needle, it is about outcomes, and not outputs.

What criteria does your team use to measure the outcomes and/or during a post-mortem?

> The real goal is to be more like a f1 pit crew where you leave out the metrics and end up performing better than if you measured them.

But all F1 pit crews have defined measurable metrics for success. I don't see the analogy here? Can you help me understand it?

We measure happiness and various sentiments towards these areas like knowledge transfer, documentation, ci/cd reliability, pr velocity, etc.

The f1 pit crew analogy refers to how certain teams realized that measuring KPIs too religiously meant the vary difference of performance when it mattered.

Similar to other sports where coaching actually matters and these metrics are rather useless unless there’s a coaching role to be deliberate with them.

>We measure happiness and various sentiments towards these areas like knowledge transfer, documentation, ci/cd reliability, pr velocity, etc.

I see, so you guys don't measure anything specific that is actionable? Did you face any challenges dealing with non-performers or under-performers dragging the team down?

Yes. Those people tend to also be happiest with each of these areas and have coaching plans with their managers given they are also early in career. Unhappiest are the senior and principal talent, but not by much more.
Okay, interesting. If you don't mind saying, what is the size of your team?
30+ ICs between two major OSS codebases.
>An outcome is finally merging an unsustainable PR that has sat for a month.

Ultimately the desired outcome is money arriving in the bank. Which is even less fathomable.