Executive and engineering leadership fundamentals

A roadmap is a list of things you intend to build, ordered by time. A strategy is an argument: a diagnosis of the situation, a guiding policy that says how you will deal with it, and a set of actions that reinforce each other because they follow from that policy. The practical test is whether the document says what you will not do. A roadmap with forty items and no exclusions has not chosen anything; it has deferred every trade-off to the quarter in which it becomes unavoidable. The cost of a real strategy is that it disappoints someone on day one, because a choice to invest in one thing is a choice to starve another. Interviewers listen for that disappointment. A candidate whose strategy offends nobody has usually produced a roadmap with a strategic-sounding title, and the follow-up question is which team loses.

The CEO asks for a two-year technology strategy in six weeks; the one-page skeleton below is what the six weeks should converge on.

TWO-YEAR TECHNOLOGY STRATEGY - one page, illustrative skeleton

1. Diagnosis (what is true now, with evidence)
   - The constraint on growth: e.g. "new markets take two quarters to
     launch because pricing and tax logic is hard-coded per country"
   - What it costs: lead time, incidents, people tied up, revenue delayed

2. Guiding policy (the one approach that addresses the diagnosis)
   - e.g. "Make country launch a configuration change, not a project"

3. Coherent actions (each one follows from the policy)
   - Year 1: extract pricing and tax into a configurable service
   - Year 1: one launch run end to end on the new path
   - Year 2: migrate remaining countries; retire per-country branches

4. What we will NOT do
   - No full platform rewrite; no new markets on the old path after Q3
   - No second cloud provider in this period

5. Measures (leading and lagging)
   - Leading: share of country rules held as configuration
   - Lagging: weeks from launch decision to first transaction

6. Risks, assumptions and the review date

The order is the substance. Diagnosis comes first because every later section is judged against it; an action that does not address the stated constraint does not belong, however attractive it is. Most weak strategies skip the diagnosis and open with actions, which is why they read as wish lists.

The guiding policy is a single sentence on purpose. If it needs a paragraph, it is usually two policies pulling in different directions, and the actions will split the same way.

Section four is the one assessors read most closely. Writing down what you will not do is what turns the page from a plan into a set of choices, and it is the section that tells the CEO which conversations are coming. The measures pair a leading indicator you can move this quarter with a lagging one the business already cares about, so progress is visible long before the outcome is.

The six weeks matter as well: most of them go on interviews, data and testing a draft with the people who will have to execute it, not on writing.

A weighted decision matrix is the usual tool, and the point of showing one is to show where the decision really lives. Weights and scores below are illustrative.

criterion (weight)                A    B    C
--------------------------------  ---  ---  ---
business outcome enabled (35)      4    3    5
risk and reversibility   (25)      2    4    1
cost and duration        (20)      2    4    1
team capability today    (20)      4    3    2

weighted score = sum(weight x score / 5), out of 100
A = 28 + 10 + 8 + 16 = 62
B = 21 + 20 + 16 + 12 = 69
C = 35 +  5 +  4 +  8 = 52

same scores, weights 50 / 10 / 20 / 20:
A = 68   B = 66   C = 64     (the winner changes)

The second calculation is the finding. With risk weighted at 25, the incremental proposal B wins; drop risk to 10 and the more ambitious A overtakes it. The matrix did not make the decision, the weights did, and the weights are a statement about how much the business can afford to be wrong. That is a conversation to have with the CEO and finance before the scoring, not after, or each team will reverse- engineer the weights that favour its proposal.

Reversibility deserves its own treatment rather than a row. A decision that can be undone in a quarter can be made quickly on partial evidence; one that commits two years of a team cannot. Many rewrite debates dissolve once someone asks which parts of each proposal are reversible and starts with those.

Telling the other two teams no is part of the answer. Do it in person before the announcement, give the actual reasons with the criteria they were judged on, say what in their proposal survives, and give the people a role in the chosen path. The failure mode is a decision announced in an all-hands that two teams learn about at the same time as everyone else.

Delivery measures at team and organisation level, read together with stability: the DORA-style set of deployment frequency, lead time for changes, change failure rate and time to restore, plus a flow view of how much work is waiting rather than being worked on. Then the outcome the board actually means, which is usually that features they expected arrived late, so bring the planned-versus-delivered record and the reasons. What you refuse to measure matters as much: lines of code, story points compared across teams and any individual productivity ranking, because each is gamed within a quarter and destroys the trust that honest reporting needs. The strongest answer often finds that engineering has not slowed but that the work has shifted, towards compliance, reliability or migration, and says so with the allocation figures rather than as an excuse.

By converting one goal into a small number of bets, each with a hypothesis, a leading indicator, a staged budget and a kill criterion agreed in advance. The bets for a new market are typically localisation and payments, regulatory and data residency requirements, and whatever product change the market needs to buy at all. Sequence them by what can sink the whole goal: if data residency is unknown, that investigation happens in month one, because finding it in month nine ends the programme. Staged investment means a small team proves the riskiest assumption before the large team is assigned. Kill criteria are written as observable conditions, such as no signed pilot customer by a given month, and the cost of skipping them is a programme that continues because stopping feels like failure. Name the capacity trade-off too: what existing work slows down to fund it.

Translate the debt into the three things a CFO already manages: cost, risk and speed. Cost is the people and infrastructure the old system consumes, expressed as capacity that cannot go to new work. Risk is what happens if it fails, such as an unsupported component, a key-person dependency or an audit finding, priced where possible as exposure rather than adjectives. Speed is the lead time the business already complains about, connected explicitly to the system that causes it. Then offer options rather than one demand: do nothing with its stated cost, a phased programme, and a larger version with faster payback. Phase it so each stage delivers something measurable and can be stopped. The weak version asks for trust because engineers know best; the strong version accepts being measured against the outcomes it promised and names the review dates.

In the room, separate the disagreement from the person and engage with the substance. Restate their objection accurately, concede what is right in it, answer with evidence where you have it and say plainly where you do not. If it cannot be resolved in the meeting, propose how it will be: a shared look at the data with a date, which gives the CEO a path rather than a contest. Afterwards, go to the peer directly, ask what prompted the challenge and whether something in your plan hurts their function, because public challenges are often private concerns that were not heard earlier. Follow up in writing with what changed or why it did not. The failure is point-scoring, which wins the meeting and loses the relationship, and executive teams notice who can disagree without making it personal.