Leading Vs. Trailing

Indicators and metrics, that is. Or maybe we should call them drivers and outcomes. Leading indicators are predictors. Done right they help you know what’s going to happen in the future. Trailing indicators, on the other hand, are all about what happened. Consider a car without a fuel gauge. From experience you know you’ve got 6 hours of fuel. After 5 hours driving down the highway you can predict that you’re low on fuel. Hours driven is a leading indicator. But since you’re on vacation and the car has a lot of luggage in it after 5 ½ hours the engine sputters and dies. You’ve run out of fuel. RPM going to zero is a trailing indicator.

Let’s start with a reality. Anything you measure has happened. In that respect all metrics are trailing indicators. The hours you drove that car is a measure of what happened. On the other hand, you can also make predictions based on any metric, so they’re also leading indicators. If your car engine’s RPMs stay high you probably haven’t run out of fuel, so you can make a short term prediction.

It’s really about what you want and what you need to do to achieve it. Your key performance indicators (KPIs) tell you if you’re achieving the desired results. Meet them and you did. Don’t meet them and you’re not. But past performance is not a guarantee of future results. Failing to meet your KPIs won’t tell you what you need to do to fix the problem. That’s just the way trailing indicators are. When you’ve run out of gas, you don’t know why. Maybe you were going faster than usual. Maybe your watch is slow. Maybe you’ve got a rooftop cargo box on your car now. Maybe your fuel tank has a leak.

In this case, hours driven (or hours remaining) is one way to predict if you’ll meet the KPI (have enough fuel). But it’s not enough. Or accurate enough. A better one is fuel burn rate. Better if you combine it with distance traveled. Average miles per gallon is a pretty good leading indicator of how many more miles you can drive. But it’s not perfect. You might have a leak. Or the conditions you’ve averaged over are different enough from your current situation. So you want trailing indicators on your leading indicators to improve confidence.

Obviously this kind of thing has a lot to do with writing code to predict things, But what has this got to do with development in general? Consider the development process. A couple of the big things we measure and report on are time for a build and time to fix a broken build. Critical things to keep low. But their trailing indicators, and as such are great for telling us there’s a problem, but not so good at telling us what to change. For that we need to measure a bunch of other things. Like time from diff creation to approval. Number of changes to a diff before approval. Time from diff submission to test start time, The number of tests run. The number of tests that can be run at once. The reliability of the tests. The time that it takes to run all the tests.

There’s no silver bullet in that list. No one thing that will always make it better. What it points to is that you need to understand the drivers of the system (leading indicators) before you can get the results (trailing indicators) you want.

So what’s driving the result you’re looking for?