Home › Goals & Metrics › Leading vs. Lagging Indicators
Goals & Metrics · Balanced Scorecard

Leading vs. Lagging Indicators

By the time the result comes in, it's too late to change it. Watch what moves first.

◷ 4 min read▤ 2 true storiesWorks the same with AISee its neighbors on the map →

On March 17, 2005, the business unit leader in charge of BP’s Texas City refinery sent a summary to all of the site’s supervisors. It passed on hard findings from a safety-culture survey, including the concern about “the conflict between production and safety.” But the summary carried good news too. The site had got off to a good start in 2005, with safety performance that “may be the best ever.”

The safety performance in question was the kind BP measured most closely: how often its workers got hurt. In 2004, according to the U.S. Chemical Safety Board, Texas City had the lowest OSHA recordable injury rate in its history, nearly a third of the average for oil refineries. Yet three people had died at the refinery that year, in three major accidents.

Six days after the email, on March 23, explosions and fire at the refinery killed 15 people and injured 180.

Driving by the mirror

By the time the result comes in, it’s too late to change it. Watch what moves first.

An injury rate is a lagging indicator. It counts harm that has already happened, and mostly the frequent, low-consequence kind, such as falls. The Chemical Safety Board’s report quoted the process safety expert Trevor Kletz: “The lost time rate is not a measure of process safety.” Process accidents, the Baker panel that later reviewed BP’s US refineries wrote, occur infrequently and often have unrelated causes, so past ones “have limited value in predicting” the next.

The board borrowed an image for relying on lagging numbers alone: trying to drive down the road looking only in the rear-view mirror. Leading indicators, in its description, check whether the system is working: whether needed work has been done, such as equipment inspections finished by their due date.

By the day of the explosion, some of what a leading indicator might have counted was already known to someone. The tower that overfilled had a level transmitter that operators had reported as giving inaccurate readings; its repair had been put off until after startup. The day before, technicians checking the critical alarms had been told there was no time for more checks. None of that showed up in an injury rate.

The board recommended that the oil industry write a standard with both “leading and lagging” indicators for process safety. Both reports pointed to a 2006 guide from Britain’s Health and Safety Executive, Developing Process Safety Indicators. As the Baker panel described it, the guide proposed “dual assurance”: both kinds, used together. One example leading indicator the Chemical Safety Board cited from it was the share of instruments and equipment tested by the target date.

A leading number is a guess

Leading indicators come with a catch, and the Baker panel spelled it out. They measure something “believed to be an indicator or precursor of future safety performance,” and while useful, they “are not absolutely predictive.” Its example: “even if equipment inspections are current, equipment failures can still occur.”

A leading indicator is a bet about cause and effect. Some bets are good. Others are just early numbers that never turn out to predict anything. And once a leading number becomes a target, it can be met on paper, as Goodhart’s Law would predict. An inspection can be signed off without anyone looking closely.

The renewal you can’t see coming

Imagine you run customer success at a software company. The number your boss watches is annual renewals, and it arrives once a year, long after anything could be done. Someone suggests a leading indicator: how often each customer’s admin logs in.

Before you build a dashboard around it, you test the bet on last year’s data. Of the 30 customers who didn’t renew, how many had logins drop in the three months before? If it’s 25, you have a signal worth watching, though still not proof that logins cause renewals. If it’s 9, and logins dropped just as often among customers who stayed, the login count would have kept you busy and told you nothing. You’d go looking for a different early sign, perhaps in the support tickets.

When the agent says it’s done

Imagine your team hands routine bug fixes to an AI coding agent. The lagging number is rework: how many of its fixes come back within a month because something broke. By the time that number arrives, the fixes have shipped.

A candidate leading number arrives with each hand-off: whether the checks you asked for were actually done before the work reached you. Did the agent run the tests and show their output, or only say it had? Did someone read the change before it was merged? You can record that the same day.

It’s still a bet. Before you steer by it, go back over the last few months of the agent’s fixes, mark the ones that came with checks actually run, and see whether those came back less often. If both groups came back at about the same rate, the checklist is keeping you busy, not warning you. Keep logging both numbers afterward, too. A link that held last quarter can fade once people start ticking the box to hit a target.

At 1:04 p.m. on March 23, 2005, the control system at Texas City showed operators 7.9 feet of liquid in the tower. The real level was 158 feet.

Stories behind it

Play it

Sources

  1. U.S. Chemical Safety and Hazard Investigation Board, Investigation Report, Refinery Explosion and Fire, BP Texas City, March 23, 2005 (Report No. 2005-04-I-TX), March 2007
  2. The Report of the BP U.S. Refineries Independent Safety Review Panel (the Baker Panel), January 2007
  3. Computer History Museum, Intel Crush Oral History Panel (Davidow, House, Katz, Bader, McKenna), recorded October 14, 2013
  4. John Doerr, OKR Example, Operation Crush (video transcript), What Matters
  5. Intel, Intel's First 16-bit Microprocessor (8086 and Operation Crush), Intel Virtual Vault