The One Metric that Matters
The more I measure the more successful I am. I’ve known this for a while, but I realize that the lack of measurement is still the thing that is holding my career back. I’ve already written about how measurement is key to The Lean Startup Cycle of using the scientific method to find innovation in your organization. So I’m hooked with this idea, but I desperately want to implement it in a good way. I want to have a breakthrough.
The Lean Enterprise book cites the Lean Analytics book concept of The One Metric That Matters (OMTM):
OMTM is a single metric that we prioritize as the most important to drive decisions depending on the stage of our product lifecycle and our business model…We focus on One Metric that Matters to:
- Answer the most pressing question we have by linking it to the assumptions in the hypothesis we want to test
- Create focus, conversation, and thought to identify problems and simulate improvement
- Provide transparency and a shared understanding across the team and wider organization
- Support a culture of experimentation by basing it on rates or ratios, not averages or totals, relevant to our historical data set
When I started out my current project in 2008, my boss for a very short time was Jeff Hughes, who is a genius at innovating software. The project I was doing was related to software quality, so Jeff gave me a metric for the first year: make defect containment go up, as defined by the percentage of software defects found inside the company related to the software defects found by our customers. He gave me the one metric that matters, and with that direction I was able to take the project in the direction it needed to go. At first we thought that we were going to stick with testing just customer situations, but we ended up having a mixture of customer situations and vanilla, or regression, situations. Without that “one metric that matters”, I wouldn’t have had the freedom to do that.
Fast forward to last year, I started a project to improve the installation experience for all of our products that get installed in restaurants. Everyone seemed to want this to be better so I didn’t stop and create the one metric that matters. I rushed ahead and started on the solution. My one metric that mattered internally was lowered cycle time from a release to working software. But I didn’t bother to define where we were before I started, and how my changes had improved the situation.
This led to a lot of unnecessary drama. People would question why we were taking a particular approach. People would question whether an improvement was warranted in the first place (even after agreeing that it was warranted before). It’s easy to point fingers and talk about how people don’t understand or care, but they do understand and they do care. I just didn’t take the time to create a metric that would measure what outcome I’m trying to create.
This is not a lesson I will soon forget. I hope that I will be able to fundamentally transform my approach to include measurement as one of the key aspects.