Agile processes usually have a retrospective meeting at the end of each two-week development sprint, where you discuss what happened during the sprint and pick a few events — good, bad, or neutral — to discuss in detail. Whether you work in an agile methodology or some other fashion, the regular process retrospective has a lot of value for detecting patterns and forcing a reckoning with the outcome of decisions. Is the team feeling good about how they get requirements? Do they feel good about the code quality? This process helps you learn how the decisions you make over time affect the way your team operates in the day-to-day. This approach is more subjective than gathering data about the team’s health, but it’s arguably even more valuable than many objective measures, because it comes from the things the team itself is noticing and struggling with or celebrating.