Leading and Lagging Indicator
The distinction between a measure that predicts an outcome and one that confirms it after the fact, determining whether a metric can be acted on.
Lagging indicators confirm; leading indicators predict. Revenue, churn and customer satisfaction are lagging: accurate, trusted, and they arrive too late to change the result they measure.
Leading indicators move first and can be acted on: trial-to-paid conversion, time to first successful use, support contact rate, feature adoption depth, deployment lead time.
The pairing is what makes a metric set useful. Every lagging indicator that matters should have one or two leading indicators the organisation believes drive it — and that belief is a hypothesis to be tested, not a fact. Many assumed relationships turn out not to hold, and discovering that is valuable.
For architecture work specifically, the leading indicators that connect technical change to business outcome are worth establishing explicitly: latency against conversion rate, availability against churn, deployment frequency against feature adoption, error rate against support cost. Without them, technical improvement is funded on faith and defunded on the first budget review.
The failure mode to avoid: too many metrics. A dashboard of forty indicators is not measured, it is displayed. Three to five per outcome, with a named owner, is what gets acted on.