I'm putting feelers out for a tool I'm building in the same vein: https://bldbtr.tech/ https://bldbtr.tech/. What makes engineering metrics hard is that every

I'm putting feelers out for a tool I'm building in the same vein: https://bldbtr.tech/ https://bldbtr.tech/. What makes engineering metrics hard is that every team is different. We can talk about cycle time, deploy frequency, bug counts, but not every team can pull the same levers and those levers don't always yield the same results. So the teams and the manager need to know how to create metrics that matter and metrics that the team has the ability to affect. You also need to take into account what is organizationally important. I've been in startups that valued deployments more than quality and enterprises in compliance heavy industries that valued quality over deployments. If your metrics don't align with your culture, it never feels right. Then the biggest thing is to not compare teams. This is a game of "better than yesterday", not a competition. As a team, you want to find what equilibrium is and use your retro to find ways to iterate. As you have more discussions around performance, you'll find more things to measure, you just need to decide if it's worth it.