Strategy & Direction: From "Busy Paddling" to "Knowing Where to Swim"
Topic: Strategy & Direction·4 tools
"The core of strategy work is always the same: discovering the critical factors in a situation and designing a way to coordinate and focus actions to deal with them." — Richard Rumelt
This week's thesis: What blocks a tech leader from leveling up is rarely "weak execution" — it's unclear direction. The team is busy, but can't say what value it's pushing toward; there's a long list of goals, but not one line stating "which problem are we actually solving." This issue's four tools answer four escalating questions: which way do we swim (North Star metric), how do we know we've arrived (OKR design), how do we turn direction into words people can act on (the strategy memo), and how do we still dare to set direction when information is never complete (embracing uncertainty).
TOOL 01
The North Star Metric: One Direction Everyone Recognizes
One Number for Value
Direction anchorUser valueLeading cause
The principle in one line
Direction precedes goals. Without a North Star everyone recognizes — the single metric that best captures the core value you create for users — each person pushes in the direction they personally think is right, and the net force is zero. The North Star isn't revenue itself; it's the leading cause of revenue.
In their words
"Your North Star Metric is the single metric that best captures the core value that your product delivers to customers."— Sean Ellis (who coined "North Star Metric") & Morgan Brown, Hacking Growth
Scene
Setup: BigCat runs an internal platform team. His boss asks, "What's your team's goal this year?"
✗ Common move
List a pile of parallel technical metrics: "Cut P99 latency to X, ship 3 features, hit 99.99% availability." Not one of them says "for whom, what value." The boss can't remember it, the team fragments, and by year-end every number is green — yet no one can say how the platform actually got better.
✓ Better move
Set one North Star: "Number of active downstream teams that complete end-to-end calls within latency targets each week." One line anchors "the value we create for internal developers." Latency, availability, new features all step back and become its input levers — not parallel goals fighting each other.
5 tests for picking a North Star
Does it represent user value, or just our internal effort?
Is it a leading indicator of revenue/retention, or a lagging one? (The North Star should be the cause, not the effect.)
Can the team's daily work directly move it?
Is there a guardrail metric to stop quality being sacrificed for it? (e.g. correctness lost to speed)
Can the whole team recite it without opening a doc?
Common mistakes
Treating a vanity metric as your North Star. Total signups, lines of code — they only go up and don't reflect real value.
Choosing revenue as the North Star. Too lagging; the team can't see this week's work move it, so it can't guide daily trade-offs.
More than one North Star. Two or more equals none — the team fractures across numbers again.
Key references
Sean Ellis & Morgan Brown, Hacking Growth — origin and method of the "North Star Metric." Amplitude, The North Star Playbook — practical template for the North Star + input-lever tree.
TOOL 02
OKR Design: Rescue Key Results From "To-Do List"
Key Results Are Outcomes, Not Tasks
Goal settingFalsifiableOutcome vs task
The principle in one line
The Objective answers "where do we want to go" (qualitative, inspiring, directional); the Key Results answer "how will we know we got there" (quantitative, verifiable, falsifiable). The most common failure is writing KRs as a to-do list ("did X") instead of an outcome ("X produced Y").
In their words
"A successful MBO system needs only to answer two questions: Where do I want to go? (The answer provides the Objective.) How will I pace myself to see if I am getting there? (The answer gives us Milestones, or Key Results.)"— Andy Grove, High Output Management, Ch.6
Scene
Setup: BigCat is setting a quarterly OKR for the team on the theme "improve platform stability."
✗ Tasks disguised as KRs
O: Improve platform stability KR1: Complete the monitoring migration KR2: Ship the circuit-breaker KR3: Write 5 runbooks
All three KRs are "what we did." Finish all three and stability may not change at all — downstream still gets paged at 3am.
✓ Outcome KRs
O: Make downstream teams trust our platform won't wake them at night KR1: Downstream on-call pages caused by our incidents drop from 12/mo to ≤3/mo KR2: P0 mean time to recovery (MTTR) drops from 45 min to ≤15 min KR3: Quarterly downstream satisfaction (NSAT) rises from 6.2 to ≥8.0
Migration, circuit-breaker, runbooks still get done — but now they're means to these outcomes, not ends in themselves.
Stress-test your KRs
Is each KR an "outcome" or a "to-do"? (Anything with "complete / ship / deliver" is usually a to-do.)
Does the number have a start and an end? (From X to Y, not just a lone Y.)
If all three KRs land, is the O definitely achieved? (Coverage test.)
Is it a "sure win"? (Grove & Google: a good OKR should hit ~70% to be ambitious enough.)
Can it be honestly falsified? (An unfalsifiable KR is just a slogan.)
Common mistakes
Sandbagging (deliberately low). Lowering targets to secure "100% attainment" turns OKRs into performance insurance and kills ambition.
Binding KRs directly to individual ratings. Once KR = perf score, everyone sets conservative goals. Both Grove and Google stress decoupling OKRs from compensation.
O written like a KR (with hard numbers), KR written like a task. Swap the roles and the whole system breaks.
Key references
John Doerr, Measure What Matters — Google's systematization of OKRs, including the "decouple OKRs from comp" principle. Andy Grove, High Output Management (Ch.6) — the intellectual source of OKRs.
TOOL 03
Writing the Strategy Memo: Wish List vs Real Strategy
Rumelt's Kernel
DiagnosisTrade-offsCoherent action
The principle in one line
Good strategy is neither an inspiring slogan nor a list of goals. Rumelt says a strategy's kernel has just three parts: a diagnosis (what is the problem, really), a guiding policy (the overall approach to deal with it), and coherent actions (a set of concrete, mutually reinforcing, non-contradictory moves). A "strategy" missing the diagnosis is just a wish list.
In their words
"The kernel of a strategy contains three elements: a diagnosis, a guiding policy, and a set of coherent actions."— Richard Rumelt, Good Strategy Bad Strategy
Scene
Setup: BigCat is asked to write a half-year technical strategy memo for his team.
✗ Bad strategy = wish list
"Our strategy is to be the most reliable, fastest, most developer-loved platform — improve stability, improve performance, improve experience." All good words, no diagnosis, no trade-offs, everything at once — which says nothing.
✓ Rumelt's three-part kernel
Diagnosis: "Our biggest pain isn't missing features — it's that downstream doesn't trust us. Last quarter 60% of cross-team escalations pointed to our nightly incidents. This is a trust problem, not a feature problem."
Guiding policy: "This half, we sacrifice new-feature velocity to buy reliability credibility. New requests yield to stability until downstream trust recovers."
Coherent actions: "(1) Freeze non-urgent new features for two months; (2) put 50% of engineering into observability and auto-rollback; (3) send downstream a transparent reliability report monthly." Three moves reinforce each other and all serve one policy.
Is your memo real strategy or a wish list?
Is there an explicit diagnosis — one line naming the core obstacle?
Are there trade-offs? (Real strategy always says "what we won't do." Wanting it all = no strategy.)
Do the three actions reinforce each other, or run separately — even undercut each other?
After reading it, would a newcomer know what to prioritize next week?
Strip out every adjective (best, leading, world-class) — is there substance left?
Common mistakes · A note for women
Mistaking a goal for a strategy. "Double revenue / be #1" is a goal, not a strategy — it doesn't say how.
Dodging trade-offs. Refusing to say "what we won't do" is the #1 signature of bad strategy (Rumelt).
Piling on adjectives. "World-class," "next-gen" substituting for real choices — reads thrilling, impossible to act on.
Female Leader's Note
Research shows that for the same strategy memo, women authors are more likely to be rated "meticulous, strong execution" rather than "strategic" — the "strategic" label carries a gendered attribution bias (see LeanIn & McKinsey, Women in the Workplace, on the language of promotion reviews). A countermove: open the memo with an explicit judgment sentence — "I judge the core problem to be X, therefore I argue for Y" — putting your "judgment" and "claim" on the table, forcing reviewers to confront your strategic judgment itself rather than defaulting to "executes well."
Key references
Richard Rumelt, Good Strategy Bad Strategy — the diagnosis / guiding policy / coherent action "kernel." Will Larson, An Elegant Puzzle ("Vision and strategy") — how to write vision and strategy for engineering teams.
TOOL 04
Embracing Uncertainty: Firm on Direction, Flexible on Path
Bet, Learn, Revise
Strategy always rests on incomplete information. Professionalism isn't "wait until it's clear, then set direction" — it's setting a near, concrete proximate objective in the fog, betting, executing, then revising on feedback. Firm on direction, flexible on path.
In their words
"What makes a decision great is not that it has a great outcome. A great decision is the result of a good process."— Annie Duke, Thinking in Bets
Scene
Setup: BigCat must set next year's tech-stack direction, but a certain AI framework's ecosystem is moving fast, and the team argues "if we commit now, won't we bet wrong?"
✗ Two common traps
Either "wait until it's clearer" — and fall behind competitors; or commit all the way at once, treating a reversible decision as irreversible, going all-in on an unvalidated stack.
"We don't bet on 'which framework wins in five years' — that's unknowable. Set a 3-month proximate objective: build a real-scenario spike on each of two candidates, score them on preset metrics (migration cost, community activity, learning curve). In 3 months we decide on data, not intuition today."
Then one more line to the team: "My current call is A, confidence about 60%. If signal X appears, I'll change it." Naming your confidence and your "conditions to change" gives direction without faking certainty.
Decision-in-the-fog checklist
Am I using "wait for more info" to avoid deciding? (Information is never complete.)
Is this bet reversible? Can it be split into smaller, affordable bets?
Can I state my current confidence (roughly what %)?
Have I pre-defined "what signal makes me change"? (No = sunk cost will hold you hostage.)
When a decision goes wrong, do I review the process or just curse the outcome?
Common mistakes
Resulting (Annie Duke's term). Inferring decision quality from outcome quality — a good outcome can come from a bad decision plus luck; judging by results rewards luck and punishes good process.
"Strong opinions" but not "loosely held." Clinging to one judgment while ignoring new signals is a breeding ground for the sunk-cost fallacy.
Using "embrace uncertainty" as an excuse not to commit. A leader still gives one clear current direction — just openly revisable. Not fence-sitting.
Key references
Annie Duke, Thinking in Bets — probabilistic thinking, resulting, process vs outcome. Richard Rumelt, Good Strategy Bad Strategy — the "proximate objective": pick a target close enough to be feasible as your handle.
This Week's Exercise · Your Day 16 Action
This week, do one concrete thing — not reflection, not reading:
Pick one area where your team's direction is unclear. Write half a page, stringing today's tools together: (1) one line of diagnosis (what's the core obstacle, really); (2) one North Star metric candidate; (3) turn it into 1 O + 3 outcome KRs (hard rule: no "complete / ship / deliver" verbs allowed in the KRs).
Take it to the team for review, and ask just one question: "If all three KRs land, do you trust that our direction was right?" If anyone hesitates, your KRs don't yet cover the O — go back and fill the gap.
Going Deeper
Can a North Star metric be "gamed" by the team?
Goodhart's law: "When a measure becomes a target, it ceases to be a good measure." Teams optimize the number itself rather than the value behind it — e.g. inflating "active downstream teams" with meaningless calls. Two countermoves: (1) always pair the North Star with a guardrail metric (quality, correctness); (2) periodically step up a level and ask "does this number still represent user value?" rather than only watching whether it rose. The metric is the map, not the territory.
Do OKRs work for exploratory / research teams (e.g. frontier AI research)?
Outcome KRs work best for delivery teams, but in highly uncertain research, hard-coding "improve model accuracy by X%" can push the team toward safe projects that guarantee the number — strangling real exploration. One adjustment: write research OKRs as "learning goals" rather than "output goals" — e.g. "run 3 experiments that clearly confirm or refute a given hypothesis," rewarding high-quality learning over guaranteed output. The framework should serve the nature of the work, not the reverse.
How stable should a strategy be? How often to rewrite it?
Two failure modes: constant flip-flopping (the team is adrift, no one dares invest long-term) vs clinging to a dead plan (the environment changed but the strategy didn't, still chanting slogans into a wall). Rule of thumb: direction (diagnosis + guiding policy) should hold for six months to a year; what changes frequently is tactics. The trigger to rewrite isn't the calendar but "have the key facts in the diagnosis become invalid?" — if the original core obstacle no longer holds, re-diagnose; otherwise leave it alone.
How to balance "embracing uncertainty" with "giving the team certainty"?
The team needs certainty to commit; the leader must stay honest about the unknown — a real tension. A workable approach is to layer it: give certainty on direction ("we do reliability and only that for six months, that won't change"), and stay honest with room on path ("which exact approach we use, we'll decide in 3 months on data"). Confine "uncertainty" to the revisable tactical layer, rather than letting the team feel the whole direction is adrift.
In a big company, how much room is there for bottom-up strategy?
Your team's strategy is always constrained by the layer above — that's not a limit but information. Real tech-leader strategy is often "finding, in the seams of the upper direction, a specific battlefield the layer above hasn't seen clearly but where you can win." Rather than complaining about a lack of freedom, treat the upper goal as your diagnostic input: they want X, and the real bottleneck to X at your layer is Y — make Y your team's strategy, both aligned upward and carrying your own claim.