I'm building these out now in my org. My goal is to measure the process, not the engineers. The big metric being "cycle time" - the time it takes from issue c

I'm building these out now in my org. My goal is to measure the process, not the engineers. The big metric being "cycle time" - the time it takes from issue created to deployment. I'll be able to further divide the metric to see what's slowing the process down: QA, DevOps, Product, or Engineering. I'll also be looking at reviews and comment counts as my org has a habit of siloing and I'm driving more collaboration. And the reality of the situation is that these metrics will be brought down to the individual level and used in performance management. As a manager, I'll have to track that 1) I'm measuring things that matter and 2) that engineers have control over the metrics. I also don't treat the metrics as a silver bullet where changes need to be investigated and not managed to. There's definitely risks and some managers probably do this poorly, but I think metrics are useful and if done well, are effective.