Measuring Performance Across Three Time Horizons

Performance in an operating role is rarely captured by one number. Some goals concern today’s results. Others build the capabilities needed for future scale. A third set protects the organization from risks that current performance may conceal.

I organize these responsibilities across three time horizons:

Horizon	Objective	Primary evidence
Run the business	Improve current performance, service, and efficiency	Outcomes, quality, unit cost, and service levels
Build scale	Create capabilities that allow the organization to grow efficiently	Coverage, access, adoption, reliability, and productivity
Control risk	Identify exposure and act before it becomes a material loss	Review coverage, limits, alerts, and mitigation closure

This framework can apply across functions. The underlying metrics will change, but the questions remain stable:

• Is the business performing today?
• Are we building the capabilities required for tomorrow?
• Are we controlling the risks created by both?

1. Run the Business

The first responsibility is to improve day-to-day performance and efficiency.

No operating metric should be read alone. A better primary result is not sustainable if it raises complaints, weakens quality, or creates compliance problems. A lower unit cost is not progress if unresolved work merely moves into a later period.

The scorecard therefore needs both primary outcomes and balancing measures.

Primary outcomes show whether the function improved what it is responsible for: throughput, recovery, conversion, service, quality, or cost. Balancing measures show whether it achieved that result responsibly. These may include:

• Customer complaints
• Compliance exceptions
• Quality failures
• Work completed within service targets
• Repeat contacts or rework
• Employee capacity

Performance also does not move in a straight line. Weekly results vary because of volume, mix, timing, and external conditions. The more useful test is whether performance remains stronger over a meaningful period and whether the process is becoming more reliable.

In my own role, several operating measures have improved and remained stronger on average, though not every measure improves every week. Most of that progress has come from better day-to-day execution. New capabilities may improve the run rate later, but they should not receive credit for results they have not yet produced.

2. Build Scale

The second responsibility is to build capabilities that allow the organization to grow without adding cost or headcount at the same rate.

This horizon requires a different scorecard. A capability may be delivered without being adopted, and it may be adopted without producing a measurable benefit.

The evidence should therefore progress through four stages:

1. Delivery: Does the capability exist and work?
2. Adoption: Are the intended users applying it?
3. Impact: Does it improve speed, quality, cost, or decisions?
4. Durability: Does the benefit continue under normal operating conditions?

Data provides a useful example. Coverage alone is insufficient. Data must be:

• Complete: The required sources, records, and fields are present.
• Timely: It arrives within the period required for the decision.
• Accurate: It reflects what occurred in the source process.
• Accessible: Authorized employees can find and use it through governed access.

AI creates a similar distinction. Providing access to a tool is a delivery milestone. It becomes useful only when employees apply it to suitable tasks and the results meet defined standards.

Early uses should focus on work where a person can review the result. Reviewer acceptance, corrections, and rejections create evidence about reliability. Human review should be reduced only when measured performance justifies it and the consequences of an error remain within an agreed tolerance.

Resilience also matters. A capability is not ready to support scale if the organization depends on one system without an alternative. Availability, provider resilience, cost, and recovery from failure belong in the scorecard alongside adoption and productivity.

The aim is not technology adoption for its own sake. It is a repeatable capability that improves the work.

3. Control Risk

The third responsibility is to identify risks that may grow faster than current performance reveals.

Creating a team, policy, or committee establishes ownership. It does not prove that risk is controlled.

The evidence should show whether the organization can:

• Identify relevant exposure
• Assess it consistently
• Detect changes early
• Operate within approved limits
• Assign and complete mitigation
• Escalate exceptions to an accountable decision-maker

This horizon is easy to underweight because success often means that a loss does not occur. It is also easy to overstate because the absence of a loss does not prove that the controls worked.

The strongest measures therefore focus on observable control performance:

• Percentage of exposure reviewed
• Exposure outside approved limits
• Alerts addressed within target
• Age of unresolved mitigation actions
• Exceptions accepted by the appropriate authority
• Losses or failures that occurred despite the controls

Growth makes this discipline more important. Average results can remain healthy while concentration or tail risk increases underneath them. Good measurement asks not only what return the organization expects, but what could happen outside the average case and whether the return compensates for that exposure.

How the Horizons Work Together

The three horizons should not be managed independently.

Running the business generates the evidence needed to build scale. New capabilities should improve current performance. Risk controls determine whether those improvements are sustainable.

graph LR
    R[Run the business] -->|Operating evidence| B[Build scale]
    B -->|New capability| R
    R -->|New exposure| C[Control risk]
    B -->|New exposure| C
    C -->|Limits and feedback| R
    C -->|Design constraints| B

The connections matter:

• Operating data reveals where a process needs improvement.
• Scalable tools change how the process performs.
• Risk measures show whether those changes create unintended exposure.
• The resulting evidence informs the next operating decision.

A leader can perform well in one horizon and still leave the organization weaker overall.

Strong current results may hide neglected infrastructure. A successful technology launch may have no adoption. Tight risk controls may prevent useful experimentation. The purpose of the framework is not to maximize every metric independently, but to make the trade-offs visible.

Have I Exceeded the Goals?

The honest answer may differ by horizon.

For running the business, the evidence may show sustained improvement in current operating measures.

For building scale, the organization may have delivered the foundation while adoption and measurable impact are still developing.

For controlling risk, ownership and monitoring may be in place while the effect on exposure and loss requires more time to evaluate.

This distinction prevents a common mistake: treating a launch as an outcome.

• A favorable week is not sustained performance.
• A tool going live is not adoption.
• Adoption is not measurable impact.
• Creating a risk function is not the same as reducing risk.

The scorecard should identify where each objective sits:

Stage	Question
Delivered	Does the process, tool, or control exist?
Adopted	Are the intended users applying it?
Effective	Has it improved a measured outcome?
Durable	Has the improvement persisted without unacceptable trade-offs?

This creates a two-dimensional framework:

• Horizons describe what a leader must manage.
• Stages describe how far each objective has progressed.