Vision and Strategic Leadership Questions

Direct answer

I structure the three years as stages, convert a small number of teams in year one rather than the whole organization, and tie each stage to outcomes the business can see. Product-oriented teams are long-lived teams that own a product or service and its outcomes, in contrast to project teams that form to deliver a piece of work and then disband.

Three-year structure (illustrative: 60 engineers on 8 project teams)

What I commit to in year 1

• Choose 2 pilot teams with a clear customer or internal user, a willing leader and work that is ongoing.
• Each gets a named product owner, a stable team, and 2 or 3 outcome measures (for example lead time from idea to production, meaning the weeks from an agreed idea to it running for customers, and customer adoption), in place of a list of deliverables. Example for one pilot team: lead time 11 weeks at baseline, target 6 weeks by the end of year 1; checkout completion 62% at baseline, target 65% (illustrative).
• Change funding for the pilots from per-project to per-team, with a quarterly review. Per-project funding means money is approved for a piece of work (say, "checkout redesign: 6 engineers for 4 months") and the team disbands when it ends. Per-team funding means a stable team of about 7 is funded for the year against a mission (say, "raise checkout completion"), and the quarterly review asks whether the outcome measures moved, not whether milestones were hit.
• Do not promise the reorganization of everyone. Commit to the learning and the measures.

Leading it to outcomes

• Baseline the measures before the change; compare pilot to non-pilot teams quarterly.
• Hold a regular forum where pilot leads share what works and what breaks.
• Make decision rights explicit (who is allowed to make which call): the product owner, the person accountable for what the team works on and why, prioritizes inside the team; a small leadership group decides cross-team matters such as shared funding.

Year 2 and year 3 measures. Year 2: all 6 converted teams report lead time and one customer metric each, and the median lead time across them is under 8 weeks. Year 3: all 8 teams are funded per team, and the intake process (the queue where stakeholders submit project requests for approval) is closed in favor of each product team's own priorities.

Centralized versus federated structure (for an analytics function inside the same 60-engineer organization, with, say, 6 analysts)

Centralized: one team does all the analytics work (all 6 analysts report to one group), which gives consistent standards but becomes a bottleneck. Federated (also called embedded): analysts sit inside product teams, which is faster and closer to the business but risks inconsistent metrics. A hybrid commonly works: a small central group owns shared platform, definitions and standards, while analysts embedded in product teams own the questions. I would start central in year 1 to set standards, in year 2 embed 4 analysts in converted teams and keep 2 central for shared definitions, and in year 3 embed more as the remaining teams convert. This follows the same pilot, scale, convert path as the table.

Pitfalls: relabeling project teams as "product teams" without changing funding or ownership, and converting teams before leaders are ready.

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.

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.

Direct answer

A good multi-year vision for an engineering, data, product or cloud organization says who it serves, what will be true for them in about three years, and what the organization will deliberately not do. You can tell a real one from a slogan because it forces a choice, a team can use it to settle a disagreement, and a year later you could tell whether you moved toward it. A slogan could be pasted onto any competitor's slides.

Vocabulary

• A vision is a description of the future you intend to create, and why it matters.
• A slogan is a phrase that sounds right but does not tell anyone what to do.
• A platform team builds shared tools that other teams use to ship their own work.
• SRE (site reliability engineering) is the discipline of keeping live services up and fast; reliability targets are agreed numbers for that, such as "99.9% of requests succeed".
• On-call means being the engineer who is paged first when a live service breaks; an escalation path is the agreed route to the next person when the first responder cannot fix it.
• Governed self-serve data means data that is documented and access-controlled, so teams can use it themselves without asking a data team for each request.
• A bespoke pipeline is a custom-built data feed made for one team only. A compliant workload is an application that already meets the company's security and regulatory rules.

The four tests

1. Choice test. Does it rule something out? If every project can claim to serve it, it guides nothing.
2. Competitor test. Could a rival org say the same sentence? If yes, it is generic.
3. Decision test. Hand it to two teams with a conflict between two projects. Does it help them pick?
4. Evidence test. In a year, could you point to something observable that shows progress (or not)?

Slogan versus vision (illustrative)

Each real vision names who benefits, what changes, and one thing it gives up.

What else a real one contains

• A first-year picture so the three-year horizon is not abstract.
• Two or three principles that guide trade-offs.
• A few ways to see progress, without turning into a metric list.

Trade-offs and pitfalls

• A vision can be too specific (naming a tool that may be obsolete in two years). Aim for a customer outcome, not a technology.
• A vision can be right on paper and unused. Test by asking engineers to restate it and to name a decision it changed.
• Avoid inspirational filler. If a sentence would survive deletion without anyone noticing, delete it.

Direction: move from reactive (heroics after an outage) to proactive (reliability designed in, measured and funded like a product feature) over roughly 24 months.

Policy (the rules). Give every service an SLO (service level objective: a target such as 99.9% of requests succeed). The error budget is the allowed shortfall: 99.9% over 30 days is 43.2 minutes of downtime (0.1% of 43,200 minutes). A service burns its budget as outage minutes accumulate. Example: a 30-minute outage uses 30 / 43.2, about 70% of the month's budget. A second 20-minute outage brings the total to 50 minutes, which is over budget by 6.8 minutes. Policy: once a service is over budget, feature releases pause until reliability work restores it, with an exception path for P0 incidents and security fixes (this is the shape of the example error budget policy in Google's SRE Workbook: halt all changes and releases other than P0 issues or security fixes until the service is back within its SLO). Add blameless post-incident reviews (a written review of what happened that looks at the system and process, not at who to blame) and a production-readiness checklist (a short list a new service must pass before launch, such as alerts, a rollback plan and an owner).

Tooling. A shared paved road: the default, supported way to build and run a service, so teams get reliability by default instead of building their own. It includes standard dashboards, alerting on SLO burn (an alert when a service is using up its budget faster than planned), tracing (following one request across services to find where it slows or fails) and a deploy pipeline with automatic rollback (the pipeline reverts a bad release on its own when health checks fail).

Training. On-call onboarding (on-call means being the engineer who responds first when an alert fires), game days (practice failure drills), and a reliability champion (one named person per team who pushes reliability practices) in each team.

Quarterly staging (illustrative). Tier-1 services are the ones whose outage directly stops customers from using or paying for the product, for example checkout, login and payments.

• Q1-Q2: SLOs for the 10 most critical services; incident review habit.
• Q3-Q4: error-budget policy live; paved road v1; on-call training.
• Year 2: expand to all tier-1 services; shift effort from fixing to preventing.

Showing progress:

• MTTD (mean time to detect): from the moment a failure starts to the moment someone knows about it.
• MTTR (mean time to restore): from the start of customer impact until the service works normally again, not until the root cause is fixed. Teams measure this differently, so I write the definition down.
• Also repeat-incident rate, share of services with an SLO, and budget burn. Report quarterly.

Budget ask (illustrative, assumes $200k loaded cost per engineer-year): a platform team of 3 engineers ($600k a year) plus a protected 10% of each product team's capacity (one engineer in a team of ten). Justify it by outage cost avoided, on the same basis as the cost: if an hour of checkout downtime costs about $150k and we lose 16 hours a year, that is $2.4M; halving it avoids about $1.2M. The $600k is only the platform team. The protected 10% costs about $200k per team of ten (10% of 10 engineers at $200k), so total cost is $600k + $200k x the number of product teams. At 2 teams the total is $1.0M and the case still clears $1.2M; at 3 teams it is $1.2M, break-even; at 5 teams it is $1.6M and the outage saving alone does not pay for it. Note the basis: the $1.2M is the checkout saving only and stays fixed in this table, while the cost grows with every team added, so the comparison is fair only for the teams that own checkout. Teams 3 to 5 own other services whose outage costs are not in the $1.2M, so the fair test for each added team is its own avoided outage cost against its roughly $200k. So either start with the 2 teams that own the most outage cost, or add the other benefits (fewer pages, faster launches) to the case rather than claiming the $1.2M covers everything.