Another fantastic article, Mike. One approach I have used in setting metrics is to have the owner of the process, outcome, or team, develop their own metric. I ask them to consider, “How would you define success at the end of the month/quarter/year?” If you said it was a great performance, how could you demonstrate it? We then build a set of metrics that try to measure that success, as you mention, holistically.
Another fantastic article, Mike. One approach I have used in setting metrics is to have the owner of the process, outcome, or team, develop their own metric. I ask them to consider, “How would you define success at the end of the month/quarter/year?” If you said it was a great performance, how could you demonstrate it? We then build a set of metrics that try to measure that success, as you mention, holistically.
Agreed, a great piece.. I like Mike's thinking, and am reminded of another approach that tackles the shackles - see what I did there - of ridiculously audit-like Well Architected Framework reviews. https://theserverlessedge.com/making-well-architected-work-for-organisations-the-security-cost-opex-reliability-performance-scorp-process-cycle-part-2/ SCORP or SCORPS as it is now (we added Sustainability!) encourages Dev teams to build their own dashboards and measures to show how they're building to good standards - I simplify, of course.