The better plans are written backwards. They start at the end - the outcome the work is meant to produce - and everything else earns its place only by moving toward it. The difference sounds small. It is the difference between a document that can be steered and one that can only be finished.

I learned this backwards, by doing it forwards for years. Early in my career I mistook thoroughness for rigour and volume for progress, and I confused being busy with being clear. I wrote the heavy plans, led with the solution, and reverse-engineered the case for it. It took me longer than I would like to admit to see the pattern: that the quality of a plan is set almost entirely by where it starts, and that the best place to start is the end.

The trap of speed and volume

Modern organisations reward two things that feel like progress and are frequently its enemy: speed and volume. Move fast. Ship more. Fill the pack. Produce the deck by Thursday. The pressure is real and rarely questioned, because both are easy to measure and both photograph well in a status report.

But speed and volume are proxies, and poor ones. They measure activity, not direction. A team can move at extraordinary pace toward the wrong outcome, and produce an enormous body of work in service of a question no one ever settled. The faster you move before you have defined success, the more expensive the eventual correction - and the correction always comes.

The discipline that separates senior operators from busy ones is the willingness to slow down at exactly the moment everyone else is speeding up. Not to slow the work. To slow the start. To spend the first hour on the question that governs the other hundred: what outcome are we actually chasing, and how will we know we reached it?

There is an old piece of wisdom that captures it. Give someone six hours to fell a tree and the wise ones spend the first four sharpening the axe. It sounds like procrastination and it is the opposite. The one who sharpens has assessed the tool, judged its condition, and invested deliberately so the cutting, when it starts, goes fast and clean. The one who skips it and swings immediately looks productive from the first minute - chips are flying, effort is visible, progress appears to be delivered. But a blunt axe does not fell a tree slowly. Often it does not fell it at all. It just exhausts the person swinging, while everyone watching mistakes the motion for headway. Most failed plans are blunt-axe plans: enormous energy spent, real activity on display, and a tree still standing at dusk.

Begin with the outcome

Starting at the end means writing the destination before the route. Before the recommendation, before the cost, before the plan - name the outcome the work is meant to produce, in one plain line.

What are we actually trying to achieve? What needle are we trying to move, and in which direction? What would make this a success six months from now, in terms a sceptical stakeholder would accept? These are the same question from different angles, and until they are answered, nothing downstream can be judged, because there is no standard to judge it against.

And it must be the real outcome, not a stand-in. “Roll out the new platform” is an activity, not a result. “Reduce the time it takes a customer to get paid” is a result. The distinction is not pedantry; an activity can only be completed, while an outcome can be aimed at, measured, and course-corrected toward. Leaders reach for the solution far too early - it feels decisive, it feels like progress - and a plan that opens with a solution has quietly answered a question the room never agreed to ask.

State the outcome first, plainly, and everything after it acquires a purpose. Every cost, every risk, every option can now be weighed against a single question: does this move us toward the end we named? Skip it, and the whole enterprise becomes motion without a compass - fast, voluminous, and lost.

The plan on a page

This discipline needs a physical form, or it stays an intention. That form is a single page.

Not a page to summarise the work after the fact. A page to begin the work - the first artefact you create, before the deck exists, before the document has a title. A plan on a page. One side, plain prose, built in order from the outcome down.

It answers a short and unforgiving list. The outcome, first and above all. Then: what are we being asked to decide? What do we recommend? What will it cost, in money and in attention? What are the risks, honestly, including the one we are most reluctant to name? What alternatives did we weigh, and why did they lose? And what happens if we do nothing - because doing nothing is always an option, and a plan that cannot beat it has not earned the meeting.

That is the whole plan. Everything else an organisation later produces - the board deck, the executive summary, the project brief, the stakeholder note - is an extract from it, cut to fit its audience. The exec summary is not written fresh; it is lifted from the page. The agenda slide is the page’s outcome line, restated. The document is the page with its evidence reattached. Get the page right and every downstream artefact writes itself, consistent with all the others because they share a single source. Get it wrong, and no amount of formatting downstream will hide that the plan was never really made.

Which reframes what the deck and the document are. They are not the thinking. They are the packaging of thinking that was already finished on the page. The analysis - the models, the appendices, the working - sits behind the page, available to anyone who wants to test it, and read by almost no one. That is as it should be. The page is the plan. The rest is evidence.

The difficulty is the point

Here is what makes the page worth the discomfort: it is hard to write. Far harder than the long version.

Anyone can include everything; inclusion requires no decisions. The page requires hundreds of them. Every line that survives is a judgement that something else mattered less, and every omission is a position the author must be prepared to defend. Writing the page is not tidying up after the thinking. It is the last and most demanding stage of the thinking - which is exactly why a finished page is such a reliable signal. It cannot be faked, and it cannot be delegated to formatting.

So what the exercise really measures is not writing. It is clarity of intent. When a plan will not compress to a page, the honest reason is rarely that the subject is too complex. It is that the outcome was never fixed - that the work set off before anyone decided where it was going. The page refuses to resolve until the thinking does, and it is far cheaper to discover that at your own desk than in front of the board.

Put it to the test

Take the plan you are building right now - the proposal you owe someone, the strategy stuck in draft, the initiative that has grown to thirty slides and no verdict. Set the deck aside. Write the page instead, and start at the end: the outcome you are chasing, the needle you intend to move, stated in one line you would be willing to be measured against.

Then work back. The parts you can write in one clean line are the parts you have decided. The parts you get stuck on are the parts you haven't - the outcome you keep softening into an activity, the option you cannot quite rule out, the cost you would rather not put on paper. Each one marks a decision you have not actually made yet. Written forwards in a deck, the volume hides those gaps. Written backwards on a page, there is nowhere to put them but in front of you. So write the page. Find the gaps. Then go and make the decisions the plan has been avoiding.

Subscribe now

Legible Is Not the Same as Simple

The common mistake is to treat legibility as simplification. The two pull in opposite directions.

Simplifying strips detail until the thing is small enough to hold. Do enough of it and you strip the detail that mattered, and end up with something clean, confident and quite possibly wrong. Legibility removes only the detail that carries no weight, keeps every piece that does, and arranges what’s left so someone who wasn’t there can reason about it correctly. Done well, the same clarity serves everyone who touches the work - strategy and delivery alike - and it compounds: each person reasons from the same sound picture, and the wrong version stops multiplying.

That takes knowing which detail carries weight, which is comprehension, not communication. Someone who can only flatten a problem into something reassuring usually doesn’t understand it well enough to know what they’re throwing away. Done honestly, legibility is a test of your own grasp before it’s a service to anyone else. If you can’t make a thing legible without making it wrong, you don’t understand it yet.

The Dangerous Kind of Clear

There’s a failure worse than a confusing explanation, and it rarely gets flagged because it doesn’t look like failure: a version clean enough that everyone feels they understand, and a confident decision made on a picture that was missing the one thing that mattered. Call it false legibility.

Confusion, at least, is self-correcting - if a point doesn’t land, someone asks. A tidy slide that quietly buries the risk invites no questions, because there’s nothing on it to question. The neater the summary, the more completely the risk disappears, and the more assured the decision built on top of it. Beautiful information can carry a worse decision than messy information ever would, and it’s harder to catch, because everyone felt well served at the time.

The way through isn’t to make the picture uglier but to give the risk the same treatment as everything else - stated clearly, concisely, legibly. The method is the only part of this I’d call simple. The instinct behind false legibility is rarely dishonesty; it’s the wish to look composed, to have it all appear handled. The honest version keeps the one uncomfortable caveat in view exactly where it bears on the decision, even if that makes things look less tidy. That’s the trade, and it’s a good one: surfacing the risk early and plainly is what earns trust, not the polish that hides it.

Translating Into the Right Currency

Done well, legibility isn’t shorter. It’s reframed.

A technical fact has to be expressed in the currency its audience actually holds, which is rarely technical. A board reasons in cost, risk, time and optionality; a CFO wants to know what a decision buys and what it forecloses. A fact stated in the terms it was true in can’t be weighed until it becomes a consequence someone can act on. “The platform is three major versions behind” lands as nothing. “We’re one vendor decision away from a forced migration we haven’t budgeted for” is the same fact, made legible.

That translation is where the real thinking sits, and it has to survive into the finished piece - the deck, the memo, the summary - whoever assembles it. It means holding the technical truth and its business consequence in view at once and building an honest bridge between them, which only works if you understand both ends. It’s also why the task resists delegation: the person furthest from the detail is the least able to judge which detail can safely go.

A Leadership Duty, Not a Nicety

None of this is a communication nicety. The quality of any decision is bounded by the legibility of what it rests on - people act on the version in front of them, not the reality underneath. When a decision goes wrong, the easy story is that whoever made it didn’t understand. More often the reality was never made legible enough to understand, and that responsibility sits with the person who did understand it. Owning that is part of the job, not an accusation against anyone who had to decide.

It gets harder with scope, not easier. The more ground you cover, the more people are acting on your account of something rather than the detail itself. Translation stacks up - each honest pass drops a little more of the load-bearing detail, until what’s left is a summary of a summary that no longer resembles the thing. Staying able to produce the honest, full-resolution version yourself, rather than relying on the flattened one you’re left with, is one of the few defences against that drift.

The Test That Actually Matters

The pull is to measure legibility by whether the room understood you. That’s the wrong test - understanding is easy to feel and easy to manufacture; a capable presenter can produce the sensation of clarity in an audience that has grasped nothing usable.

The real test comes later. Did they decide well? Could the person you handed it to reason their way to a sound call, including the parts that were inconvenient to leave in? Making the complex legible was never about being understood, or admired. It’s about leaving other people genuinely able to act. Everything else is presentation - and on a hard decision, presentation is just a nicer way to get it wrong.

Subscribe now

That’s still mostly what the job is, whatever the title says. Solving problems. Making the complex legible. Removing the friction that stops a business doing what it’s actually capable of.

Where the Distance Comes From

Somewhere along the way, the industry decided seniority means distance - the more senior you get, the further you move from the actual work, until you’re reading summaries of summaries and signing off on decisions you couldn’t execute yourself if you had to. I’ve watched capable people get promoted into that distance and stay there. There’s a case for it - distance buys scale, and nobody can stay hands-on with everything forever. What I do believe is that the best leaders stay capable of going deep when it matters - not as a habit, but as a choice.

Whatever the title said in any given year, I chose to stay close to the configuration screen, the migration plan, the budget line - not because the role demanded it, but because the decisions I was making at the top required it. That habit started early, doing the unglamorous work nobody puts on a slide, and it never left.

What changed over the years was scale: being handed problems complicated enough that the existing playbooks didn’t apply, and having to build new ones under pressure, in real time, with real consequences. That’s the part of a career that never shows up as a single line on a CV - but it’s usually the part that decides whether you’re ready for what comes next.

What the Work Has Actually Looked Like

The work has ranged widely - leading enterprise IT functions through major transformation, untangling technology stacks during corporate separations, running large-scale cost and efficiency programmes across organisations with hundreds of services and dozens of business units, working in pre-IPO environments as well as smaller organisations where speed and agility matter more than process.

If there’s a common thread in what I’ve gravitated toward, it’s organisations in motion - mid-transformation, mid-separation, mid-scale. Stable-state IT was never what interested me. The problem I find genuinely engaging is the one where the playbook doesn’t exist yet and the org chart is still being redrawn under you.

The thread through all of it is the same: technology decisions made at the top only hold up if the person making them still understands what’s happening at the bottom.

The Part That Isn’t on the Org Chart

None of that work gets done by one person, and it’s never really been the systems that interested me most - it’s the people who run them.

Every transformation, separation, or turnaround I’ve led has depended on a team I built, rebuilt, or inherited and had to reshape fast. Hiring for capability the org doesn’t have yet. Developing people into problems they haven’t faced before. Staying close enough to mentor, not just manage. That work is slower than any migration plan and it doesn’t show up on a Gantt chart, but it’s the actual mechanism by which anything at scale gets delivered - you don’t out-architect a hard problem, you out-team it.

That’s also, not coincidentally, the part of the job I’ve found most enjoyable. Systems can be redesigned. Watching someone grow into a role they weren’t ready for six months earlier is the part that’s stayed with me.

A Lesson That Didn’t Look Like One at the Time

One that’s stayed with me: leading a separation programme, sitting through a planning session where the technology split looked clean on paper - a few systems to duplicate, a few contracts to novate, a manageable timeline. What nobody had mapped was the complexity underneath it all: identity, data, UX - the quiet plumbing both sides assumed the other would keep running. Untangling that took longer than every system migration in the plan combined, and it never once made it onto the executive summary slide.

The lesson wasn’t about separations specifically. It was that the riskiest part of almost any technology programme is the part that’s invisible precisely because it’s still working. Nobody schedules a workstream for the thing that hasn’t broken yet.

Why “Insights and Battle Scars”

That’s the belief this publication is built on, and the reason for the name. A notebook isn’t a polished record - it’s where the working notes live, the half-formed conclusions, the things you noticed on the way to actually understanding something. That’s closer to what I want this to be than a highlight reel of a career that’s nowhere near finished. This is written for people leading technology through scale, separation, or change of any kind. Not a victory lap - the insights worth keeping, and the battle scars that produced them.

What’s Next

From next week, I’ll be writing about the things that don’t usually make it into the polished version of technology leadership: the discipline of not adopting the newest version of anything the moment it ships, what actually breaks when you separate a technology stack from a parent company, the gap between what a CFO wants to hear about an IT budget and what a CIO usually says, how you build and mentor a team capable of executing under pressure - not just staffing a chart, and the parts of the job that don’t get easier just because the title in front of your name has changed.

If any of that sounds useful, subscribe for new deep dive articles weekly.

Subscribe now