Mission to Metrics
How aspiration becomes execution at scale
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, time-consuming, 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.
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 company 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.
In my Effective Communication article, I described a charter as mission, vision & strategy. You’ll notice here that I only included mission and strategy. The more I think about it, the vision is just a great tool to communicate the goals you’re trying to accomplish. Like goals, visions are time-bounded. Illustrating what your outcomes look like in practice brings people along.
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.
Exhaustive without overlap. Teams own their own metrics, but leadership approves the breakdown and holds teams accountable to them. The hard part is drawing the breakdown so it’s exhaustive without overlap. If the teams’ surface areas don’t fully cover the parent’s charter, parts of the product go unowned. If they overlap, teams spend their time colliding and deduping instead of shipping.
Lived Example
One of my platforms at Block powered the company’s fintech operations: i.e. fraud detection, risk dispute handling, compliance KYC flows, customer success. Most companies anchor their top-line mission to how they make money. We were a platform team on the cost side of the house, so our contribution ran along a different line: every hour of employee work our tools removed was money the company kept. (Side note: platform teams live with this problem constantly. Their impact is one degree removed: it shows up as productivity gains for the teams they serve, not as revenue they can point to.)
Our Mission: Reduce the cost of running Block
Our Top-line Metric: $ saved
From there, the metric decomposed cleanly along the shape of the platform:
Operations tooling: direct calculation of employee time saved, translated into dollars.
Safety and trust: dollars of fines and losses prevented.
Machine learning: projected savings from model improvements, reported with a confidence interval. ML work is inherently experimental: a project either wins big or returns nothing, so comparing it head-to-head against deterministic teams is unfair without a range around the estimate.
Lived Example
Facebook was built on this framework. During my time there, the company anchored on a single apex metric: Revenue. The logic traced cleanly to the business model. Here’s the shape of how the Facebook product org and the Ads org worked together as two cascades under one company.
Facebook monetizes through advertising, so revenue is roughly a function of ads shown × conversion rate. That split into two charters:
the Ads org owned making sure the right ads reached the right users
the Product org owned getting users to open the app and stay in it long enough to see them.
Both cascades rolled up to the same apex. Ads could tie their work directly to revenue generated. Product used Sessions, the number of times a user opened the app, as their leading indicator.
This worked for years, but cracks started to show as the company scaled. Team charters and metrics kept accreting overlap, so any new product idea had to negotiate its way past three or four teams whose surface areas it touched. Most ideas died in that negotiation. The ones that survived arrived late.
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. They are the layer where aspirational direction becomes something a scaled org can actually execute against. Metrics don’t fix the layers above. If the metrics feel arbitrary, i.e. 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.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.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.
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.
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 KPI punishes what’s new. Mature products win engagement metrics by default. New features and 0-to-1 bets will always look worse on the same metric, not because they’re bad but because they haven’t had time to compound. If every idea has to clear the mature product’s bar on day one, innovation collapses into a narrow band: teams can only ship small optimizations to what’s already working. Anything that needs time to bake never gets funded, because the metric drops before the idea has a chance to pay off. A workaround is either a separate metric layer for early-stage work, a defined runway during which new bets aren’t judged on the apex, or a guardrail that reserves headroom for new initiatives. Getting the mechanics right is genuinely hard.
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.
Public Example
Prior to my time, Facebook’s Meaningful Social Interactions (MSI) shift in 2018 became the well-documented version of Goodhart’s ‘losing sight of the mission’ pitfall. The mission was to make time on the platform better for users. The metric was interactions between people, on the theory that active engagement correlates with well-being while passive scrolling doesn’t. Reasonable hypothesis. But once ranking was tied to it, the metric started pulling away from the mission because content that provoked argument generated more interactions than content that didn’t, so the feed skewed toward outrage. Internal research eventually showed the platform was getting angrier, not more meaningful.
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 logic explanation of how it traces up to the company’s apex metrics and contributes to the mission. A new hire can answer “how does this company make money?” in their first week by reading the cascade.
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.