“Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes. It is wrong to suppose that if you can’t measure it, you can’t manage it” – W. Edwards Demming

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:

“Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”

Charles Goodhart

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.

Elbow Patches, Redux

This is the time of the year when the excitement of a new set of books and a new course with the OU fades with the onset of the first Tutor Marked Assignment.

For the past couple of years, I’ve been leaving these to the last minute, which has ended up with me writing all night before it needs to be in and trying to buy time travel delivery from the local Post Office.

This year, however, I’m trying to be grown up so I’ve decided to get cracking a week and a half early. I’ve used Mind Maps before when taking notes so tried this
open source application
. I’ve managed to create my entire outline in the time it’s taken the boss to have a bath. Maybe I won’t be sneaking envelopes through my tutor’s door this year.