From business goals to the kernel

Richard Rumelt's book Good Strategy Bad Strategy (2011) gives you the most useful test for any strategy. A good strategy has a kernel of three parts:

• Diagnosis: what is going on, and which part of it is the real challenge. It explains the situation and points at the hard part.
• Guiding policy: the overall approach you choose for dealing with that challenge. It rules some options in and many options out.
• Coherent actions: the steps that carry out the policy, chosen so they support each other instead of pulling in different directions.

Rumelt also describes bad strategy, and you will see it in many technology departments. Its signs are fluff (big words such as "digital excellence" with no content), not facing the challenge, mistaking goals for strategy ("grow 30%" is a goal, not a plan), and objectives that are either a long list of everything or impossible to reach. A department's yearly "strategy" that lists 14 projects, one for each team, is bad strategy too: it is a budget with a title.

A CTO's strategy starts from the company's goals, never from technology. At Mangrove the managing director and the board have set two: open in two new cities within two years (about 80 new stores, from about 320 to about 400) and double the partner business (from about 1,800 to about 3,600 partner shops). Your job is to ask what must be true of technology for those goals to happen, and what stands in the way. Here is a method that works:

1. Write each business goal as a number with a date. 80 stores in 24 months is about 3 to 4 store openings a month. 1,800 more partner shops in 24 months is about 75 a month.
2. Trace each goal through today's systems and teams. What happens, step by step, when one more store opens or one more partner shop joins? Who does the work, how long does it take, and what breaks under twice the load?
3. Find the crux. In a later book, The Crux (2022), Rumelt calls the leader's job finding the most important part of the challenge that you can actually act on. Ask: if we fix only one thing, which one makes the others easier?
4. Write the diagnosis in four or five sentences with numbers. If it fits any company, it is too vague.

At Mangrove, tracing the goals shows the same pattern twice. Bringing a new store's tills, scanners and network live takes Victor's store IT team about nine weeks and about 30 person-days, much of it by hand. About 1,500 of the roughly 4,000 partner orders a week still come in by phone to about 40 sales reps, so doubling the partner shops at today's 62% app share would mean about 3,000 phone orders a week and twice the reps. Meanwhile the department grows by about a third, from about 90 to about 120 engineers. The crux: every new store and every new partner shop is a small project, so cost and risk would grow faster than the business. That points to a guiding policy: make adding the next store and the next partner shop a setup, not a project.

From the guiding policy to five themes

The guiding policy is one sentence. People need something more concrete to plan their quarter, so you group the coherent actions into 3 to 5 strategic themes. Fewer than three usually means you left out something the business needs. More than five means you have not chosen.

For each theme, write five things, and keep each one short:

1. The business reason, in one line that the finance director would recognise.
2. An outcome measure, with today's number and a target. Measure what changes for the business, never "project delivered".
3. One owner from your leadership team. Other teams contribute, and one person answers for it.
4. Two or three first actions for the next year. Each one supports the guiding policy.
5. What the theme will not do, so nobody hides an unrelated project under its name.

Mangrove's five themes, which the rest of this course refers to:

• 1. A partner platform ready for 3,600 shops (owner: Ken). Measure: the Partner app's share of partner orders from about 62% to about 80% by the end of year two. At 80% of about 8,000 orders a week, about 1,600 still come by phone, close to today's 1,500, so the sales team does not need to double. First actions: self-service sign-up for new shops, and bringing the ordering core in-house over about 18 months while Lagoon Digital builds to a published API contract (the money side is in Money: budgets, headcount and vendors).
• 2. Stores that open fast and run offline-first in the new cities (owner: Victor, with Ken for the POS). Measure: store IT setup from about nine weeks and 30 person-days to two weeks and about 6 person-days. First actions: a standard "store kit" (one till model, one network design, tills and scanners set up from a template), and offline tests in every POS release (Offline-first apps and data sync).
• 3. Trustworthy data and forecasting (owner: Ruth). Measure: stock accuracy from about 82% to about 92%, and app orders with an item cut for being out of stock from about 9% to about 5%. First actions: one agreed definition for each core number, and forecasts for new stores built from similar existing stores, since they have no sales history.
• 4. Reliability and security fit for a bigger company (owner: Oskar, with the security lead). Measure: checkout meets its SLO through festival peaks, and the card-payment (PCI DSS) assessment passes with no major findings. First actions: SLOs for the five most important customer and store journeys (Measuring speed and reliability), and hiring a head of security (Risk, security and compliance).
• 5. AI where it moves a business number (owner: you, with Ruth). Measure: every AI bet names the business number it should move and its baseline. First actions: a short list of bets with owners and an AI use policy (Leading AI adoption).

Now test coherence. Do the actions support each other? The store kit makes stores cheaper to open and also reduces the number of till and network types that Oskar's on-call engineers must understand, which helps theme 4. Self-service sign-up for partners only works if partner and stock data are trustworthy, which is theme 3. When two actions fight (for example, a big new feature for one large partner while you try to standardise the platform), the guiding policy decides: platforms and setup first.

Architecture principles that settle arguments

Themes say where to go. Architecture principles say how teams decide along the way, without asking you. With 12 teams making hundreds of technical choices a year, you cannot be in every design review. Good principles let Ken's and Clara's teams reach the decision you would have reached.

The Open Group's TOGAF standard uses a simple format for each principle, and it works well: a name, a statement, the rationale (why, linked to the business) and the implications (what teams must do or give up). The implications are the part people skip, and they are the part that matters, because they show the cost.

Three tests make a principle useful:

• Could a sensible team choose the opposite? "We value quality" fails, because nobody argues for poor quality. "Tills keep selling for a full day with no network" passes, because a team could reasonably choose an always-online till to save effort.
• Does it settle a real argument you have had? Write principles from the last year's disputes in design reviews (Running a design review), not from a textbook.
• Can someone see whether a design follows it? If two reviewers can read the same design and disagree on whether it follows the principle, rewrite it.

Five to seven principles is enough. Mangrove's draft:

1. Stores and riders work offline. Tills, scanners and the Rider app keep doing their core job for a full day without the network, and sync later.
2. One owner per system, APIs between teams. No team writes to another team's database. Every system has exactly one owning team.
3. Boring by default. New work uses the standard stack (NestJS, PostgreSQL, Redis, the job queue, GitHub Actions). Anything new needs a radar trial first.
4. Buy what is common, build what makes us different. Payroll, email and the service desk are bought. Partner ordering, stock and the store kit are built (Build, buy or partner).
5. Card data never touches our servers. Card payments use the payment provider's tokens, which keeps most of our systems out of PCI DSS scope.
6. A new store or partner is configuration. Adding one must never need a code change or a deploy.

Principle 3 borrows from Dan McKinley's essay "Choose Boring Technology" (2015). He suggests each company has only a few innovation tokens to spend on new, unproven technology, because every new tool adds things to learn, run and debug at 3 am. Mangrove should spend its few tokens where it is different, such as offline sync for stores and forecasting, not on a new database for the back office.

Principles need an exception path, or teams will quietly ignore them. Keep it simple: a team that wants to break a principle writes half a page (what, why, the cost, an expiry date) and the architecture review approves or refuses it. Count the exceptions each quarter. Many exceptions to one principle mean the principle is wrong, or the platform that would make it easy is missing.

A technology radar and a stop list

Principles change rarely. Choices about specific tools change every few months. Thoughtworks publishes its Technology Radar about twice a year, and many companies build their own version for their internal choices. It has four rings:

• Adopt: the default. Teams use it without asking.
• Trial: worth using on a real project, by one team, with someone watching how it goes.
• Assess: worth a time-boxed look, such as a two-week spike, to see whether it matters to us.
• Hold: do not start new work with it. Existing uses stay until there is a good reason to move them.

Thoughtworks also groups entries (it calls them blips) into four quadrants: techniques, tools, platforms, and languages and frameworks. For your own radar, the rings matter more than the quadrants. The mechanism is movement with evidence. A blip moves from assess to trial after a spike answers a clear question, and from trial to adopt after one team has used it in production for a few months and written down what it learned. A blip moves to hold when it costs more than it gives. Without that movement, a radar is just a list of tools somebody likes.

Who runs it matters. At about 90 engineers, a small group works: Oskar, three or four staff engineers from different teams and one person from Ruth's data team, meeting monthly for an hour and publishing a new version every six months. Teams propose changes with a short note. You approve only the moves that touch a principle or cost real money.

What you will stop

Michael Porter wrote in "What Is Strategy?" (Harvard Business Review, 1996) that the essence of strategy is choosing what not to do. For a CTO this is concrete. Your engineers are already fully booked. Every theme needs people, and with 30 new engineers arriving over 18 to 24 months, and each taking months to become fully productive, new hires alone will not pay for it. So the strategy must name work you will stop, and it must be specific enough that someone notices.

A method for the stop list:

1. List where engineering time goes today, by team, in rough engineer-equivalents. Your first-100-days assessment from The department head's job gives you most of this.
2. Mark everything that serves no theme and no legal or safety need.
3. For each item, write who will notice and what they lose. If nobody would notice, stop it this month. If a peer executive would notice, agree it with them before the strategy is published.
4. Add up the freed capacity and assign it to themes in the same document, so the stop list visibly pays for the themes.

Stopping is a decision with a cost, so treat it like one. Some items are a pause with a date ("no custom partner features until the self-service sign-up ships"). Some are a hold on the radar. Some are a migration that only happens when the old thing needs changing anyway, which is cheaper than a big rewrite.

The strategy on two pages, and how it is reviewed

A strategy nobody reads changes nothing. Two pages is a good limit: short enough that the managing director reads all of it, that every engineer can, and that you can present it to the board in ten minutes (The board and the executive team). Put supporting analysis in an appendix. The structure:

• Page 1: the business goals in two lines, the diagnosis in one paragraph with numbers, the guiding policy in one sentence, and a table of the themes with measure, owner and first actions.
• Page 2: the architecture principles as one line each, radar highlights, the stop list with freed capacity, what you need from the executive team (budget, hires, decisions) and how the strategy will be reviewed.

Write it with your leadership team, not for them. A good sequence over about four weeks: you write the diagnosis and test it with Ken, Clara, Oskar, Ruth and Victor; the leadership team drafts themes together in one long session; each owner writes their theme's measures and actions; you test the draft with the finance director and the head of store operations before the executive team sees it. People carry out a strategy they helped write. Writing clearly for decision-makers is covered in Writing for decisions.

Then decide how it lives. A strategy should be stable enough that teams can plan against it and honest enough to change when the world does. Three rhythms work well:

• Quarterly: the leadership team reviews each theme's measure and actions. Actions change; the guiding policy usually does not.
• Yearly: a full review a few weeks before the annual plan and budget, starting again from the diagnosis. What did we learn? Which assumptions held? This review feeds the budget in cto-04 and the planning cycle in Organisation and operating model.
• On a trigger: a change in business goals (a third city, an acquisition), a broken assumption (Lagoon cannot meet the API contract), a major incident, or a big shift in technology. Write the triggers in the document, so a review is expected and not a sign of failure.

Keep a short decision log beside the strategy: each important choice, the date, the options considered and why. A year later, when someone asks why the Partner app ordering core came in-house, the answer is there, and the new head of security can read how the company got where it is.