When I was a baby engineer, the VP of Engineering where I worked decided to measure build breaks as a proxy for quality. He was so excited by this, he then went wild with power and decreed that no developer can break the build more than once per quarter. So much quality, right?
You can guess what happened next – no developer committed to the code base more than once every four months, those changes were huge, and tracking down where the build was broken took months.
This is an example of Goodhart’s Law:
As soon as you start using metrics to manage people, those people will change their behaviour to game those metrics. It’s better to use measurements as a temperature check to examine your Engineering system then zooming into areas that aren’t working using qualitative techniques (a fancy way of saying TALK TO YOUR ENGINEERS).
What metrics are best?
In Working Backwards, Colin Bryar and Bill Carr at Amazon describe two types of measures: Output and Input metrics.
- Output metrics: Measure how successful a process or activity is.
- Input metrics: The activities that lead to changes in output metrics,
Most of us concentrate on output metrics, for example looking at defect rates, but forget that there is little we can do to directly improve that measure. To drive down defect rates, we might think about how much testing is automated and how often those tests run – this is your input metric.
Choose output metrics that align with the value you want to give to your customers and choose input metrics that you think will improve those. Always start with customer value.
Measure multiple dimensions
Don’t be like the VP – balance your metrics across multiple dimensions. Nicole Forsgren describes five dimensions for highly effective engineering teams:
- Satisfaction and Wellbeing
- Performance
- Activity
- Communication and Collaboration
- Efficiency and Flow
You want your metrics to balance across two or three of these to avoid forcing your teams into strange behaviours.
Another example, if you’re measuring number of commits (activity) only, then it’s going to be really easy for teams to stop helping each other while trying to optimise getting code into mainline.
Balance is the key.
Being data-driven is really fashionable, especially as business push to do more with fewer people. Being only data-driven is not enough, remember your teams are people, remember your teams need to collaborate. In the end, engineering is a human endeavor.