Ask HN: How do you turn engineering metrics into help and not blame?
1•harryosgood•3h ago
We flag PRs open >24h into an engineering performance board in monday dev and embed daily snapshots in a slack channel. Review times improved but I worry about the “gotcha” vibe. What norms, reviewer rotations or VS Code editor-integrations (quick PR links, inline TODOs) have helped teams act on metrics constructively?
Comments
codingdave•2h ago
Well, the first step is not taking measurements that are only used to cast blame.
Instead of flagging > 24 hrs as a bad thing, flag < 1 hr as a good thing. If your board is supposed to be about engineering performance, then highlight actual performance and don't highlight negatives. Slow PRs are a problem to be discussed within the team, and often can be resolved with a simple request: "I just put up a PR that needs to be reviews so I am not blocked..." That would encourage people to help each other, instead of building a culture that say 23 hours to review a PR is fine because it isn't on the board.
We resolved this concern on my last team without breaking people's dev flow by formalizing a practice that every time you step out of flow or finish a task, you review PRs before getting back into flow. It worked great for that team. Focus on those types of solutions.
And as far as any other metrics, take the same approach, seeking the positivity. There are two sides to every story, so choose to measure the good side.
codingdave•2h ago
Instead of flagging > 24 hrs as a bad thing, flag < 1 hr as a good thing. If your board is supposed to be about engineering performance, then highlight actual performance and don't highlight negatives. Slow PRs are a problem to be discussed within the team, and often can be resolved with a simple request: "I just put up a PR that needs to be reviews so I am not blocked..." That would encourage people to help each other, instead of building a culture that say 23 hours to review a PR is fine because it isn't on the board.
We resolved this concern on my last team without breaking people's dev flow by formalizing a practice that every time you step out of flow or finish a task, you review PRs before getting back into flow. It worked great for that team. Focus on those types of solutions.
And as far as any other metrics, take the same approach, seeking the positivity. There are two sides to every story, so choose to measure the good side.