The three parts, and the two that get forgotten
The useful skeleton for a technology strategy is the one Richard Rumelt describes in Good Strategy Bad Strategy: a diagnosis, a guiding policy and a set of coherent actions. The diagnosis says what is actually in the way. The guiding policy is the approach you choose to deal with it, which rules things out. The actions are the specific moves that follow, chosen because they reinforce each other.
At executive level two more sections carry most of the weight. The first is what you will not do, because a technology strategy without losers has made no choices. The second is measures, because the CEO asked for two years and needs a way to tell at month nine whether it is working. A page on writing a technical strategy that changes behaviour covers adoption without authority. This question is different: you have the authority, a deadline and a CEO who will hold you to it.
How to tell a strategy from a roadmap
A roadmap is a list of things ordered in time. A strategy explains why those things and not others. Both are useful, and the CEO often asks for one while meaning the other. Four tests separate them, and you should apply them to your own draft before anyone else does.
| Test | Roadmap | Strategy |
|---|
| Delete every date | Nothing meaningful remains | The diagnosis and choices still stand |
| Hand it a funded proposal that conflicts | It absorbs it as another line | It gives a reason to decline or reshape it |
| Ask what you are giving up | Usually nothing | Named investments stop, with dates |
| Ask what would prove it wrong | Missed dates only | Measures that could fail even if every item ships |
The second test is the one that matters most to a CEO. If the document cannot be used to say no in the next budget round, it will not change where money and people go, and that is the only thing a strategy is for.
Using the six weeks
Six weeks is enough to produce a good technology strategy only if most of the time goes on evidence and testing rather than writing. A workable split looks like this.
| Weeks | Work | Output |
|---|
| 1-2 | Interview the CEO, CFO, product, sales and two or three large-customer-facing staff. Pull incident history, change lead time, spend by area and attrition. | A list of the business constraints engineering affects |
| 3 | Draft the diagnosis in one page and test it with the CEO and two peers | A diagnosis people recognise |
| 4 | Generate two or three genuine options and choose between them | Guiding policy and the explicit "not doing" list |
| 5 | Cost the actions with finance and sequence them | Actions with owners, rough cost and dependencies |
| 6 | Pre-wire with each executive, then present | Final document and a derived plan for the first two quarters |
Pre-wiring in week six matters more than the presentation. An executive who first sees their team's project on the stop list in a meeting will fight it in that meeting.
A worked outline
Here is the content of a real technology strategy, for an illustrative company. Assume a B2B software firm with about 120 engineers and one main product. Sales report that enterprise deals stall in security review and onboarding. Engineering records show each enterprise customer took months of bespoke deployment work, and most serious incidents in the last year touched one shared database.
Diagnosis. We lose and delay enterprise revenue not on features but on how long it takes to make a large customer live and safe. Our single shared deployment turns each enterprise customer into a bespoke project. The same coupling causes most of our serious incidents.
Guiding policy. We will make a standard, repeatable enterprise deployment the default, and we will treat any customer-specific infrastructure as an exception that sales must price. We choose operability over new product surface for the next four quarters.
Coherent actions.
- Separate tenant data behind one tenancy model, starting with the services that caused the most incidents.
- Build an automated provisioning path so a new enterprise environment is a pipeline run, not a project.
- Prepare the security evidence pack that sales currently assembles by hand for every review.
- Move one platform team of about eight engineers onto the first two actions for a year.
What we will not do. We will not rewrite the core application. We will not start a second product line's mobile app this year. We will not run a multi-cloud programme. We will not accept new single-customer forks.
Measures. Time from contract signature to an enterprise customer live, against the current baseline. The share of serious incidents that cross tenant boundaries. Enterprise deals lost or delayed with security or onboarding cited as the reason. Change lead time for the services being separated.
Every number in the final document comes from the organisation's own records. If a baseline does not exist yet, say so and make measuring it the first action rather than inventing a target.
The roadmap dressed as a strategy
The weak answer is a list of initiatives, a target architecture and a Gantt chart, each defensible, none of them chosen against anything. It looks thorough and it fails the delete-the-dates test immediately. A sharp interviewer will ask you to name one thing your last technology strategy stopped. A candidate who has done this work answers at once, with the project, the person who owned it and how that conversation went.
The second weak answer is technically right but written in engineering language. "Decouple the data layer" means nothing to a CEO. "Make a new enterprise customer live in weeks rather than months" is the same decision, stated as the business result it buys.
Executive interviews vary widely. Some ask for this as a take-home document, some as a live presentation and some as a conversation, so prepare to give the outline in five minutes as well as in five pages.
A strategy earns the name when it changes what gets funded; if your document cannot decline anything, you have written a roadmap with a preface.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).