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.
I spend a lot of time thinking about developer productivity, and still believe it is best assessed by "soft" measures (e.g. developer sentiment). But this post reminded me of a great anecdote in the book "Showstopper!" (https://www.goodreads.com/en/book/show/1416925.Show_Stopper_). Great book; takes what could be a dry topic and approaches it like a thriller. Anyway, the anecdote: when Microsoft and IBM were partnering on the development of OS/2, they needed a metric to determine how each side would be compensated. IBM insisted on lines of code written as the metric. Some ways into the project, the Microsoft engineers refactored the code base, greatly reducing the number of lines of code. IBM's response: "You owe us money."
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.
I spend a lot of time thinking about developer productivity, and still believe it is best assessed by "soft" measures (e.g. developer sentiment). But this post reminded me of a great anecdote in the book "Showstopper!" (https://www.goodreads.com/en/book/show/1416925.Show_Stopper_). Great book; takes what could be a dry topic and approaches it like a thriller. Anyway, the anecdote: when Microsoft and IBM were partnering on the development of OS/2, they needed a metric to determine how each side would be compensated. IBM insisted on lines of code written as the metric. Some ways into the project, the Microsoft engineers refactored the code base, greatly reducing the number of lines of code. IBM's response: "You owe us money."