Skip to content
Open to board advisory and board seats — 2H 2026, then CY 2027–2028.
See details →
Writing

The IT Strategy One-Pager the CEO Actually Quotes.

The sixty-slide IT strategy vanishes into a shared drive. The version that survives is short, opinionated, tradeoff-explicit, and quotable by the CEO.

By Michael YorkJuly 27, 2026 7 min read 1,672 words All postsTable of contents

A CEO, in a meeting you are not in, restates your strategy to a customer or a director, in their own words, correctly, without the document in front of them. That is the entire game. A strategy that gets quoted changed a decision. A strategy that gets filed changed nothing.

I have sat through the sixty-slide version. A vision statement, three pillars, a maturity model with the company helpfully placed one notch below "leading," a technology radar, and a roadmap swimlane that runs eight quarters into a future nobody in the room will still be employed to see. Everyone nods. The deck earns a round of "great work," it lands in a shared drive, and a week later not one person who sat through it can repeat a single sentence. The gap between quoted and filed is almost never the quality of the thinking. It is the artifact.

I should be clear about my vantage. I do not author the enterprise IT strategy. I run security and DevOps, and the platform we built on top of them, which is a real slice of the technology function and not the whole of it. But I write the strategy for that slice, I defend it to a board, and I have watched enough of the sixty-slide kind get built and quietly ignored to be confident the failure is structural. The deck is not a neutral container for good thinking. It is a machine for avoiding the one thing a strategy is supposed to do.

Strategy is a set of choices, not a catalog of intentions

Richard Rumelt, in Good Strategy Bad Strategy, gives the cleanest diagnosis I know for why these documents fail. Good strategy has a kernel: an honest diagnosis of the hardest problem you actually face, a guiding policy for dealing with it, and a coherent set of actions that follow from the policy. Bad strategy is the absence of that kernel dressed up to look like its presence: fluff, a refusal to name the real challenge, and the most common failure of all, mistaking goals for strategy. "Modernize the core," "become data-driven," "reach level four maturity" are ambitions with a deadline. They tell you where you would like to arrive and nothing about the road.

The deck is where that failure hides most comfortably, because a deck can list everything without choosing anything. Twelve initiatives, all funded, all important, all on the roadmap. That is a budget with a design template. A real strategy is subtractive. It names the one or two problems that matter this year, commits real resources to them, and by committing, starves everything else. If your strategy document does not leave someone in the room a little unhappy about what did not make it on, you have written a plan. A plan is a list of what you will do. A strategy is an argument about why this and not that.

Write it in prose, because the format is load-bearing

Slides let you hide the logic in the white space between bullets. "Consolidate tooling — reduce vendor risk — improve developer experience" reads like an argument, but it is three fragments in a trench coat, and the causal claims that connect them are exactly the part a bullet lets you skip. Prose will not let you skip them. To write "we are consolidating on one platform, which we expect to reduce vendor risk and improve developer experience, at the cost of the teams that preferred their own tools," you have to hold the claim and its price in the same sentence. That sentence is harder to write because the thinking behind it is harder to do, and the deck was letting you avoid the thinking.

Amazon is the well-worn example: the widely reported practice of banning slide decks in favor of a six-page written narrative that everyone reads in silence at the start of the meeting. Whatever you make of the ritual, the underlying claim holds. A narrative you read as connected paragraphs exposes gaps that a bulleted list conceals. When I write the strategy for my own slice, the useful version is never the deck. It is the memo, a page or two, that a colleague could read cold and come away able to state what we are betting on and what we are giving up to make the bet. The one-pager is not a compression of the deck. It is a more honest artifact, and most of the time the deck should have been the appendix all along.

Name the tradeoff, not just the ambition

Every real strategic choice costs something, and the section that most reliably separates a strategy from a wish list is the one that says out loud what you are giving up. Most strategy documents are all upside. Standardize the platform and gain operability, reliability, lower cost, happier engineers, world peace. But standardization has a price: teams lose the freedom to reach for the locally optimal tool on each job. A document that will not name that price is not asking the reader to trust a decision. It is asking them not to notice that a decision was made.

I will use my own slice as the example, because it is the one I can speak to without inventing anything. We built AgentOS, a governed internal agent platform, on a specific bet: that in regulated fintech the control plane around the model, not the model itself, is where governance actually lives, and that owning that layer is worth building rather than buying. That is a strategy sentence, and it carries a real sacrifice. Building the harness means we carry maintenance a vendor would otherwise carry, and we move slower on some capabilities than a team that bolts a thin wrapper onto a hosted model. I put the tradeoff in the strategy on purpose. If a director or a peer disagrees, I want them arguing with the actual choice, control-plane ownership versus speed-to-feature, not with a paragraph of benefits that pretends the choice was free. A tradeoff you named is a decision you can defend. A tradeoff you hid is a landmine the next reorg steps on.

The anti-roadmap is the part they will actually quote

Michael Porter's line that the essence of strategy is choosing what not to do has been quoted so often it has gone soft, and it is still the most operational sentence in the field. The most valuable page in a strategy document is frequently the list of things you are explicitly not going to do this year: the platform you are not adopting, the rewrite you are not starting, the shiny category you are going to sit out. I have come to think of it as the anti-roadmap. It is the page executives remember, because it took courage to write and it gives them cover to say no.

The mechanism is simple. A CEO cannot personally hold the two hundred decisions the organization makes each quarter, but they can hold three sentences about what the company has decided not to chase. When a vendor corners them at a conference, or a board member floats the initiative that is fashionable this month, the anti-roadmap is what they quote back: we looked at that and made a deliberate call to sit it out this year, and here is why. That is the strategy doing its real job, traveling into rooms you are not in and holding a line you are not there to hold. A roadmap tells people what to work on. An anti-roadmap tells them what to decline, and declining is where most strategies quietly succeed or fail.

Quotable is a distribution decision, not a writing style

The only distribution mechanism that scales is quotation. You will present the strategy a handful of times. After that it propagates, or fails to, by being restated by people who were never in the room, secondhand and thirdhand, in meetings you will never hear about. Every restatement is a lossy copy. If the original is a sixty-slide deck, the copy that survives three hops is noise. If the original is one sharp sentence about the bet and one about the sacrifice, the copy that survives three hops is still recognizably the strategy.

So I write for the restatement, not for the presentation. The test I use is embarrassingly simple: a week after I brief someone, can they tell me the strategy back, in their own words, and get the bet and the tradeoff right? If they can, the document worked, however thin it looks. If they cannot, no amount of production value will save it. The thinking was either not clear or not memorable, and both are my problem to fix, not the reader's. A strategy the CEO can quote is not a dumbed-down strategy. It is a strategy that finished the last mile of its own thinking, and kept going until it was small enough to carry out of the room.

Write it to be repeated

If you are about to author an IT strategy, or rescue one, resist the deck a little longer and do four things instead.

  • Name the hard problem, then choose. One or two real challenges, an honest diagnosis, and a bet, not a catalog of everything the function will touch next year.
  • Write the one-pager first. If the argument does not survive as prose a colleague can read cold, the deck is hiding a gap, not filling one.
  • State the sacrifice in the same breath as the ambition. A tradeoff you named is a decision you can defend; a tradeoff you hid is the next reorg's landmine.
  • Publish the anti-roadmap. The list of what you are deliberately not doing is the part that travels, and the part that holds the line when you are not in the room.

The deck was never the deliverable. The sentence the CEO repeats when you are not in the room is the deliverable, and everything else is production value stacked on top of it.

IT StrategyExecutive CommunicationLeadershipGovernance