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.

What makes a good Objective: an OKR (Objectives and Key Results, a goal-setting method from Andy Grove at Intel, brought to Google by John Doerr) pairs an Objective with Key Results. The Objective is a qualitative, inspiring statement of what you want to achieve, owned by one team and achievable in a quarter or year. Not a task list.

What makes a good Key Result: it is measurable with a number, so at the end nobody argues about whether it happened. It measures an outcome (a change in customer or business behavior), not an output (something you shipped). Commonly cited guidance is about 3 to 5 per Objective (Google's re:Work guide says around three), so each stays checkable.

Example (illustrative B2B SaaS team, growth plus retention):

• Objective: Become the product that enterprise customers renew early and expand.
• KR1: Grow ARR (annual recurring revenue) from $20.0M to $25.0M (+25%).
• KR2: Raise gross revenue retention (share of last year's revenue kept, ignoring upsell) from 88% to 92%.
• KR3: Raise the share of customers using 3 or more modules from 31% to 45%.

KR1 covers growth, KR2 covers keeping customers, and KR3 is a leading indicator (an early signal) that should move before retention does.

Common mistakes: a KR such as "launch the new dashboard" is an output; fix it by asking what changes when it launches. Too many OKRs dilute focus. The strategy comes first: the OKRs should be the near-term slice of the three-year direction. One more convention: Google grades Key Results from 0.0 to 1.0 and treats about 0.6 to 0.7 as the healthy average for stretch (aspirational) OKRs, while committed OKRs are expected to be fully hit; that is a Google convention, not universal, so state which kind each Key Result is when you set it.

Direct answer

Pick one initiative that ran more than a quarter, had a named business outcome, and where your own decisions changed the result. Tell it as a story: why it mattered, how you set it up (outcome, owner, plan), how you kept it on course (checkpoints and a trade-off you made), and how you proved the outcome with a before/after comparison the business already trusted.

Terms used below

• A baseline is the measured starting value of a number, written down before the work begins, so you can later show how far it moved.
• A pipeline here is the automated sequence of steps that builds, tests and ships code to customers. Test reliability means automated tests that pass or fail for real reasons, not at random. Rollout safety means releasing gradually so a bad release can be caught and reversed quickly.
• Merge to production is the time from a developer's finished change being accepted into the main code to it running for customers.
• On-call engineers are the ones paged when live systems break.
• A workstream is one strand of the work with its own owner; a sponsor is a senior person who clears blockers for you; "ramped up" means new people become productive.

Story skeleton (illustrative example; replace with your real facts and numbers)

• Situation. Three product teams each ran their own manual release process, and releases kept slipping. Leadership wanted fewer release-related incidents and faster delivery within three quarters. I was the engineering lead accountable for the outcome.
• Setup. I turned "improve releases" into one sentence: cut the share of releases that cause an incident, and shorten the time from merge to production. I wrote down a baseline for both measures before touching anything: 6 of the last 36 releases caused an incident (one in six, about 17%), and the median time from merge to production was 5 days. I named one owner per workstream (pipeline, test reliability, rollout safety), agreed what we would stop doing to make capacity, and got a sponsor (a director) to unblock cross-team asks.
• Keeping it on course. A 30-minute weekly check-in against milestones; a monthly review with the sponsor that showed the two measures, not just activity. In quarter two the test-reliability work slipped. The choice was to add scope cuts or add people; I cut the planned dashboard (nice to have) and kept the pipeline work, because adding people late would have slowed the team down while they ramped up.
• Proving the outcome. I compared the same two measures against the written baseline, using the incident log and deploy history the business already trusted, so nobody had to take my word for it. I also reported what did not move. I was also honest about sample size: 6 of 36 versus 3 of 30 releases is too few events to call the incident improvement proven by itself (a standard significance test on those counts gives a two-sided p-value of about 0.49, meaning a gap this size would appear by chance about half the time). So I presented the incident rate as a direction, led with the median time to production, where a drop from 5 days to 2 across every release is much harder to explain by luck, and kept tracking incidents for two more quarters before claiming the full effect.
• Result and reflection. Say the result in terms the story supports. Only state figures you can defend. Then name one thing you would change, such as involving the on-call engineers in design from week one.

What it sounds like when spoken (illustrative)

"Three teams were shipping by hand and one release in six caused an incident, with a median of five days from merge to production. I owned the outcome. I wrote those two numbers down first, split the work into three owned streams, and met the director monthly with just those two numbers. Test reliability slipped in quarter two, so I dropped the dashboard rather than add people late. By the end of quarter three, 3 of the last 30 releases caused an incident (one in ten), and the median time to production fell from five days to two. Compared against the same incident log, so nobody had to trust my word. With only 30 releases the incident drop is a direction rather than proof, so I kept tracking it for two more quarters, and I led with the time-to-production result, which is the larger and clearer change. Next time I would bring the on-call engineers into the design in week one."

What separates strong answers

• Outcome, not output. "Shipped the pipeline" is an output; "fewer incident-causing releases" is an outcome.
• A baseline before the work, so the improvement is provable.
• One real trade-off you made mid-flight, and why.
• Honesty about what you did versus the team. Use "I" for your decisions.

Principle: a strategy has several audiences who each care about a different thing. Translate, do not repeat the same deck. A sponsor is a senior person who publicly backs the work, gives it capacity and clears obstacles.

Example strategy used below (illustrative): consolidate four separate deployment pipelines into one, over three quarters.

1. Take it to each audience.

• Product leaders care about customer outcomes and delivery dates: show how the strategy speeds or protects the roadmap, what it costs in capacity, and what they get in return. Say: "Releases that take two days to coordinate today take two hours after the first quarter, so your Q3 launch dates stop slipping. It costs you one feature's worth of engineering time."
• Engineering leaders care about people, technical risk and focus: show the sequence, what stops, and who owns what. Say: "Three teams stop maintaining their own pipelines after Q2, one named owner runs the shared one, and we migrate the riskiest service first."
• Both: meet them one to one before any group meeting so no one is surprised, and ask for a specific commitment (a sponsor, a capacity share, a decision date). A capacity share is a fraction of people's time. Sample ask: "I need two engineers at 20% for two quarters from your team, and a decision from you by the 15th."

2. Keep momentum after the first presentation. Convert interest into scheduled actions within two weeks: named owners, a first milestone, and a regular short review. Share small wins in the language of each audience, and keep a visible one-page status: three lines for progress ("2 of 4 pipelines migrated"), three for risks, and one for what I need from sponsors this month.

3. Check it landed. Do not ask "does this make sense?". Instead:

• Ask people to explain the strategy and what it means for their team in their own words (for example, "If a teammate asked why we are doing this, what would you say?").
• Look at behaviour: do teams' planning documents mention it? Did a team make a trade-off because of it, such as delaying a feature to migrate?
• Track whether sponsors actually allocated what they promised.

If it did not land: find out whether the gap is understanding, agreement or incentives (what people are rewarded for), and adjust the message, the ask or the sponsor. If understanding: rewrite the one-pager in their words. If agreement: take the objection on, perhaps with a small trial. If incentives: ask the sponsor to change a goal or a deadline so the work is rewarded.

The same method in other situations. for a cloud or security architect, the engineering audience also includes teams who must adopt the change, so include what they get for the extra work.

Principle: skeptics do not need a bigger vision; they need a cheap way to be proven wrong early. Frame the bet as staged funding with explicit stop conditions.

1. State the direction and the bet in business terms. For example: "In three years, AI assistance cuts the cost of resolving a support ticket from about $6 to about $4 without lowering customer satisfaction." That is a claim about cost, not technology. Write the assumptions that must be true: data quality, user trust, and unit cost (what it costs to serve one ticket, including model usage).

2. Split the multi-year direction into stages, each funded only if the previous one passes.

• Stage 1 (about a quarter): a narrow pilot on one workflow with a clear baseline (the measured starting value). Example: order-status tickets, 8,000 of 40,000 a month (20%), average handling time 12 minutes. Funds about 2 engineers.
• Stage 2: extend to adjacent workflows (returns, password resets) if the pilot holds. Funds a few more engineers and a quality review process.
• Stage 3: platform investment (shared retrieval, evaluation and monitoring that every team reuses) only after repeat wins.

3. Pick pilots that earn funding. Choose work that is (a) frequent enough to measure fast, (b) low risk if it fails, (c) tied to a metric executives already track, and (d) owned by a team that wants it. Avoid the showcase demo that cannot be measured.

4. Know the case is holding. Agree in advance on leading indicators (early signals such as adoption, quality, cost per task) and a lagging one (the slower business metric), plus a kill criterion (a pre-agreed condition that ends the effort) with a date. Pilot example: after 12 weeks, pass if handling time falls from 12 to 8 minutes or better and satisfaction drops by no more than 1 point; stop or reshape if handling time improves by less than 1 minute. Agree the middle band too: an improvement of 1 to 4 minutes (a result between stop and pass) earns one extension of six more weeks with a named change to try, and then it either passes or stops. Measure the pilot against a holdout (a comparable set of order-status tickets still handled the old way during the same weeks), so a seasonal dip or a staffing change is not credited to the AI. A pass is worth 4 minutes at about $30 an hour, $2 per ticket, so $16,000 a month on 8,000 tickets; at a model cost of about $0.50 per ticket ($4,000), the net is about $12,000 a month (illustrative). Be honest that this does not repay a two-engineer pilot by itself: two engineers at $200k a year each cost about $33,000 a month, so the pilot case rests on the saving scaling to more workflows in stages 2 and 3, and the stage 1 ask is justified as the cost of buying evidence, not as a payback. Review on a fixed cadence and report misses honestly.

5. Security or cloud programs: the same staging applies; the pilot might be requiring phishing-resistant multi-factor login for admin accounts in one cloud environment. Baseline: 6 admin credential incidents last year. Pass: no rise in locked-out admins and a measurable control result, such as 100% of admin sign-ins in the pilot environment using phishing-resistant factors. Do not use "zero incidents" as the pass test: at 6 a year, a 12-week window expects about 1.4 incidents, so zero would happen about 25% of the time even if the control did nothing. Then widen to other environments.

What would flip it: if the pilot cannot show movement against baseline by its checkpoint, stop or reshape rather than defend it.