North Star Translation Layer
Give every team a metric they can directly move, then convert each into a single company North Star using a shared translation factor.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 90%
Rather than force every team to optimize revenue (too lagging) or a shared high-level metric they can't directly influence, Batchu has each team own a local metric they can move, and the finance/data team maintains a 'translation factor' converting that local metric into the one North Star. This creates a common currency for cross-team prioritization and resource allocation, while keeping day-to-day work concrete and accountable.
Origin
Practiced by Batchu at Instacart (North Star: monthly active orders) and adapted at Ramp (North Star: dollars of SQL pipeline); he notes Facebook used a similar structure with long-term holdouts.
Core principles
- 01Pick one, at most two North Star metrics
- 02Hold teams accountable only for metrics they can directly influence
- 03Maintain an explicit translation factor from each local metric to the North Star
- 04Use the translation layer only to remove obvious decisions from cognitive load; decide genuinely marginal calls by judgment
- 05Refresh translation factors on a fixed cadence as you learn
How to run it
- 1
Choose one North Star with dual properties
Select a metric with a clear linkage to value creation AND that is intuitive enough that people working on minutiae can see how their work moves it. Sit it between lagging revenue and unrelatable micro-metrics.
Pro tip Aim for two metrics total: one on volume/growth, one on efficiency.
Watch out Revenue alone is usually too far down the line for a growth team to feel it can directly impact.
- 2
Give each team a directly-influenceable local metric
Assign every sub-team a metric they own for their sprints and day-to-day, such as app load time, checkout conversion, or email-submission rate.
- 3
Build the translation factor
Have the finance/data team derive, often via regression analysis, how a unit change in each local metric maps to the North Star (e.g. one extra weekly order from the same customer = X impact on monthly active orders).
Pro tip Long-term holdouts per surface area let you validate the cumulative real-world impact of each team's work, not just the modeled estimate.
Watch out The formula is never perfect; treat it as roughly 70/30 or 80/20 accurate.
- 4
Roll everything up for planning and prioritization
Convert all project plans and impact estimates into the common North Star currency to compare 'North-Star-per-dollar' or 'per-engineer' across teams and allocate resources.
Watch out Do not use the translation factor to settle marginal (5-10% difference) decisions; those are marginal for a reason and should be judgment calls.
- 5
Refresh the translations on cadence
Update all translation factors every six months for the new planning cycle based on what you have learned about how moving X actually affects the North Star.
In the wild
With 300+ people in growth and engineering, a team improving checkout speed couldn't obviously see its effect on the company metric. Instacart gave each team a local metric (e.g. app load time) and had finance/data build a translation into monthly active orders, then rolled all project impact back into that single number and refreshed the factors every six months.
→ Unified prioritization across many teams and easier cross-allocation of budget and engineers by comparing North-Star impact per resource.
Common mistakes
Holding teams accountable for metrics they can't move
If a checkout team is judged on the company North Star directly, the link is too weak to drive accountability; give them a metric they directly influence and translate it upward instead.
Trusting the translation formula on marginal calls
The formula is only ~70-80% accurate, so using it to decide 5-10% differences creates false precision; reserve those decisions for human judgment.
Is it for you?
Best for
Growth or product leaders at mid-to-large companies with many teams competing for shared resources
Not ideal for
Very small startups with one team and one obvious metric, where the translation overhead adds no value
From the transcript
“the actual you know local team has their own metric that they can directly influence like you want to actually you know hold people accountable…”
“we would actually update all of the translations every six months uh for the new planning cycle”
“setting a culture of like we know this isn't perfect this is like 70 30 80 20”
From the episode
Lessons from scaling Ramp
Sri Batchu (Ramp, Instacart, Opendoor)