Vision and Strategic Leadership Questions

Draft goals (illustrative numbers, annual, using the OKR format): an OKR pairs one Objective (a qualitative direction) with 3 to 5 Key Results (measurable outcomes). Andy Grove introduced the method at Intel and John Doerr spread it.

• Objective 1: Prototypes become shipped product. KR1: 6 of the 8 prototypes started this year reach production use by Q4. KR2: median time from prototype start to a pilot with real users drops from 14 weeks to 6. KR3: each shipped feature has a named owner and an on-call path (a named person or rota who gets paged when it breaks).
• Objective 2: Shipped work moves a customer metric. KR1: 3 launches each raise 30-day retention (the share of new users still active 30 days later) by at least 2 points, for example 40% to 42%, measured against a holdout group (a randomly chosen set of users who keep the old experience, so you can compare), with the gap large enough that chance alone is unlikely to explain it. Size this before committing: detecting a 2-point lift from 40% to 42% at the usual 5% significance and 80% power needs roughly 9,500 users in each group (a standard two-proportion calculation), so if a launch will not reach that many new users in the year, either lower the bar to a bigger lift, lengthen the window, or report the result as directional rather than proven. Activation, the share of new users who complete a first key action, is an alternative metric. KR2: weekly active use of shipped features reaches 25% of eligible accounts (customers who have access to the feature). KR3: every launch reports its retention or activation result to the quarterly review within 60 days of release, win or lose.
• Objective 3: Build the habit. KR1: every launch has a written hypothesis and success metric before build starts. KR2: by the end of Q2, every prototype in flight has a named owner and a dated go or stop decision. KR3: at least 2 prototypes are stopped on purpose during the year, each with a one-page note on what was learned (stopping a weak prototype counts as progress, not failure).

Test: real goal or slogan or task list?

1. Slogan test: "Drive product excellence" fails. Ask "what would we see in the data if this were true or false?" If nothing, it is a slogan.
   • Rewrite: "Drive product excellence" becomes "Cut median prototype-to-pilot time from 14 weeks to 6 by Q3."
2. Task-list test: "Launch 5 features" is output, not outcome. Ask "if we did all of it and nothing improved, would we call the year a success?" If yes, it is a task list.
   • Rewrite: "Launch 5 features" becomes "Of 5 launches, at least 3 raise 30-day retention by 2 points or more against a holdout."
3. Ownership and baseline: each KR has one owner, a starting value and a date.
4. Stretch check: a KR we are certain to hit is too soft.

Review: read the goals aloud to a skeptical engineer and an executive; if they disagree on what "done" means, rewrite.

The three-minute pitch: opening, year one, and proof.

"Today our meetings argue about opinions. In three years I want every important decision here to start with a question and end with evidence: a team proposing a launch states a hypothesis (what they expect to happen and why), checks it, and tells us what they learned, whether it won or lost. That makes us faster, because we stop relitigating (re-arguing the same decision again and again), and safer, because we catch wrong bets early. Year one is about trust and habit, not tools."

Year one:

• Quarter 1: pick 5 decisions that matter and the 3 metrics behind them (for example, pricing changes judged on conversion rate, onboarding changes on week-1 activation, support staffing on time to first reply); agree a single written definition for each (what counts as "active", over what window) so numbers stop being disputed.
• Quarter 2: make the data available and reliable (one place, known freshness); train managers to ask for the evidence.
• Quarter 3: run decisions for two teams through a lightweight review (one page, 15 minutes): hypothesis, metric, result.
• Quarter 4: publish what was learned, including the failures, and extend to more teams.

The rest of the pitch, spoken (together with the opening, about 320 words, which is roughly two and a half minutes at a normal speaking pace of 130 words a minute, leaving room for a pause or a question to fill three): "Here is what I will do in the first year. In the first quarter I pick five decisions that matter and agree one definition for the numbers behind them, so we stop arguing about whose dashboard is right. By mid-year the data is in one place with a known freshness, and managers have learned to ask 'what evidence do we have?' In the third quarter two teams run their launches through a one-page review. By year end we publish what we learned, including what failed, and extend to more teams. Tools are the last thing I buy, because trust and habit come first. And I need one thing from this room: when the evidence says no, someone senior visibly changes their mind. Here is how you will know it is working. Early on, you will see the share of launches that start with a written hypothesis and a metric climb from about one in ten to eight in ten. Later, you will see fewer decisions reversed after the fact, and decisions made faster. And at any time you can test me: ask any manager to name the last decision that data changed. If they cannot, we have built dashboards and theatre, and I will say so out loud. If I get one year, I will bring you that answer, with the failures included, so that next year we can argue about evidence instead of opinions."

Showing it works: leading signs (early, quick to move) are the share of launches with a written hypothesis and metric, and how often dashboards are used in reviews. Lagging signs (slow to appear) are fewer reversed decisions and shorter time to decide. Example targets (illustrative): launches with a written hypothesis from about 10% at the start to 80% by year end across the teams that have joined the review (only two teams are in the review by Quarter 3, so the company-wide share will be lower until Quarter 4 extends it); reversed decisions down from 6 a year to 3. Pair them with a simple check: ask people to name the last decision changed by data. Beware theatre: dashboards and reviews that exist but change no decisions.

Warning: tools without trust or leadership modelling it fail; the executive team must visibly change a decision because of evidence.

Direct answer

I turn each headline target into a workstream (one strand of work) with one owner, then plan by quarter with milestones that each have a measure. I split capacity deliberately between near-term wins and long-term investment, shifting from wins toward investment as credibility builds. A fixed review cadence and clear decision rights (who has the final say on which kind of decision) keep the plan honest.

Step 1: Make targets measurable (illustrative targets)

• Fewer failures: change-failure rate (the share of releases that cause an incident) from 12% to 6% by year end.
• Faster queries: 95th-percentile query latency (the time within which 95% of queries finish) from 2.0 s to 1.0 s.
• New capability: self-serve data export live for customers by Q4.

Step 2: Capacity first

10 engineers x 13 weeks = 130 person-weeks per quarter. About 70% is plannable (available for planned work) after leave, on-call (being paged for live problems) and meetings. 70% is a common planning assumption, not a law; check it against your own calendar. One illustrative breakdown of the lost 39 person-weeks: 10 for leave, 10 for on-call and support, 19 for meetings, hiring and training. 130 x 0.7 = 91, rounded down to 90 to keep the numbers clean. Split the 90 into near-term wins (quick, visible improvements), long-term investment (foundational work), and a buffer for unplanned work.

Why this shape: Q1 is 50% wins, 30% investment, 20% buffer, because a new plan needs visible results before it is trusted; each later quarter moves 10 points from wins to investment until Q3, when investment reaches 50%, because foundational work only pays off in later quarters. The buffer stays fixed at 20%.

Year: 135 wins (37.5%), 153 investment (42.5%), 72 buffer (20%), 360 total.

Buffer in action: a major customer escalation takes 6 person-weeks in Q2. The buffer drops from 18 to 12 and the plan holds. If it took 30, the buffer would be gone and we would have to cut a milestone, which is why the buffer exists.

Step 3: Workstreams, owners, milestones and measures

Each row has one owner, and each cell holds a milestone with a success measure. For reliability and query speed the measure is the number shown. For data export the measures are adoption evidence (illustrative): Q1 discovery finished with all 5 customers and a ranked list of needs agreed with the sponsor; Q2 prototype accepted by at least 4 of those 5 customers in review; Q3 beta used weekly by at least 2 of the 3 beta customers; Q4 general availability, with an adoption target set from the beta results. For example, Reliability Q2: the reliability lead is answerable, and the measure is the change-failure rate falling from 10% to 8%.

Step 4: Cadence and decision rights

• Weekly: each owner reports milestone status. Monthly: review measures with the executive sponsor (the senior leader who backs the plan and unblocks it). Quarterly: replan using the next quarter's capacity.
• Owners decide within their workstream. Trade-offs between workstreams go to the function lead within two days. Changing an annual target needs the sponsor.
• A milestone that misses twice is escalated, not quietly rolled forward.

Pitfalls: all-wins plans that starve the platform, and plans with no buffer, which collapse on the first incident.

Direct answer

A list of features with quarters is a roadmap: it says what will be built and roughly when. A vision says where we are trying to take customers and why, and it should stay true even if every feature on the list changes. I would show my peer that the list tells the reader nothing about the problem being solved, who it is for, or what we will say no to, then help them write a short vision and place the feature list underneath as one possible path.

Vocabulary

• Vision: the future you want to create for customers, and why it matters.
• Strategy: the choices about how to get there and what to give up.
• Roadmap: the dated sequence of work. It is a plan, and it changes.

The conversation I would have

I would start with a question, not a verdict. "If all four of these shipped on time and customers did nothing differently, would you call that success?" Most people say no, which shows that the features are means and the vision lives in what customers do differently.

Example (illustrative)

The peer's page: "Q1 dashboards. Q2 single sign-on. Q3 mobile app. Q4 AI summaries."

Problems I would point out:

• No customer or problem is named.
• Nothing is ruled out, so it cannot settle a disagreement.
• If Q2 slips, the "vision" has changed.
• Nobody can tell whether it worked.

What I would help them write instead

Three questions, answered in a few sentences:

1. Who are we building for, and what is hard for them today?
2. What will be true for them in three years that is not true now?
3. What will we not do?

A resulting vision: "Operations leaders at mid-size companies can see what is going wrong in their business before the Monday meeting, without asking an analyst. We will serve a single operational data model, not custom reporting." The four features then reappear as a roadmap that serves that picture, and each is judged by whether it moves customers toward it. Some may be dropped.

Trade-offs and pitfalls

• Do not turn it into a lecture on definitions. Peers adopt a better artifact, not a correction.
• A vision with no features at all can feel empty. Offer one or two examples of how it would show up for a customer.
• If the peer's real need is a roadmap for a partner or sales team, a roadmap is fine. The mistake is calling it the vision.

Direct answer

I spend the first 30 days listening and diagnosing, days 31 to 60 drafting a direction with the people who must live with it, and days 61 to 90 getting it agreed and visibly started. I do not announce a vision on day one; one built without product, engineering and design is one nobody owns.

Days 1 to 30: listen and diagnose

• Meet product, engineering and design leads, top stakeholders and several customers. Ask: what is working, what is painful, what would you stop?
• Collect evidence: roadmap docs, incident and support trends, customer feedback, where time actually goes.
• Write a short diagnosis: what the real problem is, in plain terms. It is the first part of Richard Rumelt's "kernel" of good strategy, which has three parts: a diagnosis (what is going on), a guiding policy (the overall approach chosen to deal with it) and coherent actions (steps that reinforce each other). Share it back and ask "have I got this right?"
• Example diagnosis: "Three teams ship separately, so customers see inconsistent behaviour, and roughly a third of engineering time goes on fixing integration problems rather than building features." (illustrative.) Notice it names a problem, not a goal.
• Quick win: fix one irritant that people named repeatedly, so the team sees listening lead to action.

Days 31 to 60: draft together

• Draft a one-page direction: where we want to be in about three years, what we will focus on, what we will not do. Illustrative draft: "In three years customers use one product, not three. We focus on a shared core and a common design system. We will not build new features that only one team can use. First two quarters: unify sign-in and the design components."
• Run a working session with product, engineering and design where each discipline edits the draft. Capture disagreements openly.
• Test it: does each team find their current work in it or see what changes?

Days 61 to 90: align and commit

• Review with leadership, adjust, and publish with the first 2 or 3 priorities for the next two quarters, each with an owner and a measure.
• Agree a shared forum (a fortnightly cross-discipline review) and decision rights: who has the final say on which kind of decision (for example, design owns look and feel, engineering owns architecture, product owns priorities, and ties go to the head of the function).
• Define how you will know it is landing: for example whether team members can state the direction in their own words, and early movement in one or two measures.

Same pattern for a cross-org initiative (one that spans several organisations you do not manage):

• Days 1 to 30: discovery with each contributing org; write a diagnosis they confirm; one quick win that helps all of them.
• By day 60: an alignment milestone: a written sign-off from each contributing org on the goal and on what each will contribute.
• By day 90: a committed plan with owners, dates, and a named forum where cross-org conflicts are settled.

Pitfalls: presenting a finished vision too early, ignoring a discipline (design is often brought in last), and a document that never becomes owned work.