Mission to Metrics
How aspiration becomes execution at scale
Two teams ship in the same quarter. Both hit their numbers. Both get celebrated. Six months later you discover they were pulling the company in opposite directions the entire time: and both can prove, with dashboards, that they did their jobs. Nothing in your org caught it, because nothing in your org connects what teams measure to what the company means.
Every scaling org hits the same wall. In the early days, alignment was cheap: everyone was in the room, and priorities were held in people’s heads, but growth breaks it. Decisions collect at the top, teams pull in different directions, and leadership spends its weeks re-aligning the org instead of shipping.
The instinct is more meetings, more coordinators, more OKRs. The extreme version is a giant recurring meeting where every leader sits in the room and the decision-maker closes every open question live. It works, but it’s expensive, non-durable, and doesn’t scale past the size of the room. None of these instincts fix the underlying problem: the org has no shared framework teams can use to make decisions on their own while staying aligned to the top.
Mission to Metrics is that framework. It’s a written cascade, running from why the org exists down to the numbers that measure whether it’s getting there. Every team’s plan is a more detailed version of one slice of the layer above. Every metric traces back to the mission. Once it’s written, anyone in the org can read the page and understand how their work connects to the company mission.
The framework
Mission is the abstract statement of purpose: why the org exists. Metrics are the concrete numbers that show whether it’s getting there. The whole framework is one long translation between them, and every layer in the middle exists to make the translation legible. Metrics only work if moving them actually moves the org toward the mission. If they don’t, they’re measuring something else: an activity, a proxy, or a symptom of progress rather than progress itself.
The framework has four layers. Each layer answers one question:
Mission — Why does the org exist?
Strategy — How is the org going to accomplish the mission?
Goals — What outcomes must be accomplished to prove the strategy is working?
Metrics — Which numbers measure how close the org is to those outcomes, and by how much?
Note: Mission is timeless; goals are time-bound. The mission is why the org exists (evergreen). Goals are the specific outcomes to hit in a defined window (a year, a quarter) that prove the strategy is working. A goal is something you commit to and can either hit or miss on a deadline; a mission is something you pursue.
Tactics come next: every project is tied to a metric it moves. The roadmap is prioritized against those metrics: balanced against partner requests, compliance, and operational realities that don’t always trace to a metric. The framework doesn’t kill those inputs; it makes them visible as trade-offs against metric-driven work.
The cascade has two properties.
Recursive. The top of the org sets direction and breaks it into a handful of areas. Each area gets an owning team, and that team runs the same four-layer framework at their level — their own mission, strategy, goals, and metrics under that area. If the team is itself large enough, they may split their area into sub-areas, each with an owner. Every team’s plan is a more detailed version of one slice of its parent’s plan. The payoff: decisions can happen in distributed places but stay aligned.
Bidirectional. Parents publish direction; teams propose the layer beneath. Teams own their own metrics, but leadership approves the breakdown and holds teams accountable to them. Pure top-down cascading fails predictably: strategy degrades at each translation (the telephone effect), teams stall waiting for the layer above to finalize, and ownership erodes when people execute goals they were handed rather than goals they authored.
Metrics are the mission in practice
Most orgs believe they have layers 1–3. They have a mission statement, a strategy deck, quarterly goals. What they don’t have is metrics that trace cleanly to those upper layers. That’s because the upper layers weren’t written with enough specificity to be measured.
The metrics layer is the pressure test. If the goal is “grow the business,” someone has to define what growth means for the business. If the strategy is “win by being the best at X,” someone has to define what “best” is. The failure will surface as a metrics problem, but the root is usually higher up the cascade.
The rest of this doc focuses on metrics. Metrics don’t fix the layers above, but they are the layer where aspirational direction becomes something a scaled org can actually execute against. If the metrics feel arbitrary, ie no one can say what number success looks like, the fix is rarely better metrics. It’s a sharper mission, strategy, or goal. The answer is to walk back up the cascade. Writing the upper layers well: a mission worth pursuing, a strategy over its alternatives, goals that actually matter, is some of the hardest work an organizational leader does, and a topic for a different article.
Anchoring the cascade
At the top of the metrics layer sits the apex metric: the one number the business ultimately lives or dies on. Everything below recurses from it. The apex metric is the closest number we have to measuring the mission itself. Without it, teams optimize whichever number their local doc happened to cite, and the numbers don’t add up.
Lagging at the top, leading below. Apex metrics are lagging: revenue moves months after the decisions that moved it. A healthy cascade names both: lagging indicators at the top (what the business is judged on) and leading indicators at the team level (the earlier signals a team believes will cause the lagging ones to move). Leading indicators only work when paired with a written hypothesis connecting them to the lagging one, tested against reality. When a leading indicator moves and the lagging one doesn’t, the hypothesis was wrong.
Three kinds of metrics
Not every number in a dashboard plays the same role. Understanding the different types, and how each one is used to track progress, is what stops teams from optimizing the wrong thing. The three categories below are the ones that enter the cascade and drive team behavior. Other kinds of numbers exist; those either fold into one of these three or sit outside the framework entirely.
Target numbers a team is actively trying to move. Every target traces upward to a strategy and goal.
- Examples: revenue, active users, gross margin.
- Rule: have goals set against them. If a team can’t state the number it’s aiming for, it’s not a target yet.Guardrail a counter-metric paired with a target, to catch damage done chasing the target.
- Examples: customer retention paired with revenue growth; uptime paired with feature velocity; CS escalation rate paired with product change velocity.
- Rule: reported alongside the target, always. Breaching one triggers a stop-condition, not a goal.Diagnostic numbers that explain movement in targets or guardrails. A diagnostic tells you why, not whether.
- Examples: funnel step conversion rates, cohort breakdowns, per-segment retention.
- Rule: watched, not measured. Never set a goal against one.
Common failure: someone sees a diagnostic in a dashboard and sets a team goal against it. Now the team is optimizing a metric that was never meant to be moved, and the cascade drifts. Categorize every metric before it enters a plan.
Rules of the game
Everything traces upward. Every target metric connects to a company metric; every tactic names the goal it moves. If it can’t, cut it.
Written, publicly readable, not verbal. The cascade lives in a doc, not a meeting. Meetings edit the doc, they don’t replace it. Internally public — distributed decisions are only checkable if the layer above them is legible to everyone below.
Every KPI has a definition and a hypothesis. Definition: numerator, denominator, window, unit, grain. Hypothesis: “moving X will move Y, because Z.” No definition, no metric. No hypothesis, no goal.
Every target ships with a paired guardrail. A named counter-metric, reported alongside, so a local win that regresses a parent metric shows up immediately.
Decompose along the causal graph, not the org chart. A single strategy arrow can span three teams. Decompose first, assign owners second.
3–5 areas per level. Fewer isn’t decomposing; more isn’t prioritizing.
Different layers, different cadences. Metrics weekly, goals quarterly, strategy semiannually (or on a triggering event), mission should be evergreen.
A stale cascade is worse than no cascade. It lies with authority. Revise or retire; don’t leave it as decoration.
Where KPIs go wrong
The KPI becomes the goal (Goodhart). Attach status, headcount, or comp to a number and people optimize the number, not the thing it was meant to represent. Same failure at strategy scale: when a team defends a KPI instead of the mission, the cascade has inverted.
The proxy is not the outcome. Every KPI is a proxy for something the org actually cares about. When they diverge, follow the outcome. If NPS is up but retention is down, retention is what matters. Rebuild the proxy.
Local wins, global losses. A team can move its KPI up while dragging a company metric down. This is what paired guardrails exist to catch.
Vanity metrics wearing a suit. Activity dressed up as outcome: features shipped, tickets closed, dashboards built. Same failure at project scale: every project scoped to “unblock the next launch” without asking whether the launch actually moves the strategy.
The metric outlived the reasoning. Strategy shifts, KPIs don’t. Or a KPI moved and nobody wrote down whether the strategy caused it or seasonality did. A metric without a live causal story is decoration, and worse than no metric because it feels like signal.
The fix. Walk the metric back up the cascade. If it doesn’t connect to a goal, and the goal doesn’t connect to a strategy, and the strategy doesn’t connect to the mission, cut it.
What good looks like
A healthy cascade is what lets an org operate at scale. Decisions close in distributed places, without leadership in the room to make the call. When strategy shifts, everyone can see which metrics went stale and which projects need reframing. When someone asks “why are we doing this?”, the answer is a link, not a story. And a new hire can answer “how does this company make money?” in their first week by reading the cascade, not by attending twelve meetings.
Anti-patterns: a dashboard with no narrative; OKRs that don’t name the parent goal they serve; a cascade only leadership has read; teams defending a metric instead of the mission it was meant to serve.
Mission to metrics is a simple framework, but brutally hard to get right in practice. Once you’ve figured it out, the whole thing reads as obvious in retrospect. Getting there is anything but. If you’ve implemented something like this, or watched it fail, I’d love to hear what it took.