Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How We Wrote the Technical Strategy Doc That Actually Got Read
Transcript
- Lucas: There's this moment every CTO knows. You spend three weeks writing a technical strategy document. Forty-seven pages. Diagrams. Trade-off analysis. Projections. You send it out to the leadership team and the principal engineers. And then... crickets. Luna: Right. Nobody reads it. Or if they do, they skim it and the decisions you thought were locked in get reopened in a one-hour meeting where nobody has the document in front of them. Lucas: Exactly. So today I want to talk about a team — let's call them a mid-stage SaaS company, about 80 engineers, growing fast — that realized their strategy docs were basically a form of busywork. The CTO there, a woman named Sarah, told me her team had written fourteen major strategy documents over the previous two years. She estimated that maybe three of them had actually influenced a decision. Luna: Was the problem the content or the format? Because I've seen a lot of strategy docs that are technically sound but impossible to navigate. Lucas: Both, honestly. But Sarah zeroed in on format first because it was the easier lever. She asked her team to run what they called the 'one-pager test.' Take your strategy doc, remove every section title, every diagram, every appendix. Can the core argument fit on one page of plain text? And if it can't, you don't have a clear enough thesis. Luna: I love that. It forces you to separate the signal from the noise. But isn't there a risk of oversimplifying? Some technical trade-offs are genuinely complex. Lucas: Sure. But Sarah's argument was that the complexity should live in the appendix, not the main body. The main body is for the decision. The appendix is for the deep dive. And she took it further — she said the one-pager test applies to every section, too. Each section should be readable as a standalone one-pager with its own clear recommendation. Luna: That sounds like the pyramid principle from Barbara Minto. Top down, with the conclusion first. Lucas: Exactly the reference she used. She'd been a management consultant before she became a CTO, so she brought that structure in. And it worked. The team rewrote their next strategy document — it was about migrating from a monolith to a service-oriented architecture — from 47 pages down to 6. And the six pages had four sections, each with a one-sentence recommendation at the top. Luna: What were the four sections? Lucas: The first was 'Why now' — the business driver. Not technical debt, but actual revenue at risk. For them, it was that a single feature change in the monolith was taking 12 weeks from idea to deployment, and competitors were shipping similar features in three weeks. That's the kind of number that makes a CEO sit up. Luna: So the second section would be the proposed approach. Lucas: Right. But they didn't write 'we will adopt microservices.' They wrote a specific, phased migration: first extract the payments service, then the user service, then the notification service. Each phase had a time estimate and a risk rating. And here's the key — they included a table of trade-offs. Not pros and cons, but explicit trade-offs. Like, 'If we extract payments first, we reduce deployment risk for the highest-revenue feature, but we increase complexity in the database layer for three months.' Luna: A trade-off table is so much more useful than a pro-con list. Pro-con lists are often just the writer's bias dressed up as analysis. Lucas: Exactly. And Sarah insisted that every trade-off include a number. Not 'improves performance' but 'reduces p95 latency from 200 milliseconds to 50 milliseconds.' Not 'increases team autonomy' but 'reduces cross-team coordination meetings from 8 per month to 2 per month.' Numbers make the trade-off real. Luna: What about the third and fourth sections? Lucas: Third was 'What we stop doing.' Sarah told me that was the most controversial section. Because every strategy involves opportunity cost, and most documents gloss over it. They listed three initiatives they would pause or deprioritize: a data lake project, a mobile app rewrite, and a performance optimization for a rarely-used feature. That forced a real conversation with the product team about priorities. Luna: I bet that section generated more discussion than all the architecture diagrams combined. Lucas: Absolutely. And the fourth section was 'How we know it's working' — measurable outcomes with a timeline. After six months, the goal was to reduce feature deployment time from 12 weeks to 6 weeks. After twelve months, to 3 weeks. Those were the metrics that would determine whether the migration was a success or a failure. Luna: So the document went from 47 pages of architectural analysis to 6 pages of decision-making framework. What happened when they presented it? Lucas: The CEO read it the night before the meeting — and came in with questions on the trade-off table. That had never happened before. In the meeting, the discussion was about the trade-offs and the opportunity costs, not about whether a particular diagram was correct. They made a decision in 45 minutes. The previous strategy doc had taken three meetings and four weeks to get a decision. Luna: That's a huge win. But I wonder — does this approach scale? For a 10-person startup, maybe a one-pager is fine. But for a 500-engineer org with multiple divisions, you might need a hierarchy of documents. Lucas: Sarah actually addressed that. She said for larger orgs, you have a one-pager at the executive level, and then each team that's affected writes their own one-pager for their piece. But the executive-level doc still has to pass the one-pager test. If the CTO can't explain the strategy on one page, the strategy is probably too vague. Luna: It reminds me of Jeff Bezos's six-page memo rule at Amazon. No bullet points, full sentences. But that's more about forcing clarity in writing. This is about forcing clarity in the argument itself. Lucas: Right. And the six-page memo at Amazon is still a narrative. Sarah's approach is closer to a business case. She said she borrowed the structure from how her firm used to write investment memos. The audience — whether it's a CEO or a board — doesn't want to read a novel. They want a thesis, evidence, trade-offs, and a decision. Luna: One thing I'm curious about: how did the engineers react? Some engineers love writing long, thorough documents. They might feel like a one-pager is dumbing down their work. Lucas: That was the biggest pushback. Sarah told me a couple of principal engineers were offended. They said the nuance was lost. But Sarah's response was: 'The nuance goes in the appendix. If someone wants to read the 40 pages of analysis, they can. But the decision-makers need the 6 pages.' And she also said that writing the one-pager actually required more intellectual rigor than the long document. Because you can't hide behind verbose descriptions. You have to make a choice and defend it. Luna: Did the engineers come around? Lucas: Mostly, yes. Especially when they saw that decisions were getting made faster and that their recommendations were actually being adopted. The first doc that used the new format led to a fully funded migration within two weeks. The previous approach had taken three months of back and forth. Luna: That's a strong incentive to change habits. So what's the takeaway for a CTO or engineering leader listening? Should they go rewrite their strategy docs tomorrow? Lucas: I'd say start with the one-pager test. Take your current strategy doc, or the one you're about to write. Remove all formatting, all diagrams, all appendices. Write the core argument on one page. If you can't, you haven't found the core argument yet. And if you can, use that one-pager as the spine of your document. Then add the supporting sections — but each one should also pass a mini one-pager test. Luna: I'd add: include a trade-off table and a 'what we stop doing' section. Those are the parts that generate real conversation. Lucas: Absolutely. And measure the outcome. Did the document lead to a decision? How fast? Did the decision hold? Sarah's team tracked those metrics. After six months, strategy docs were getting decisions in an average of 1.2 meetings, down from 4. And the decisions stuck — only one out of eight was revisited within a quarter. Luna: That's a data point worth sharing. I think a lot of leaders know their documents aren't effective, but they don't quantify that. Lucas: Right. And once you quantify it, you can improve it. So, to anyone writing a technical strategy doc this quarter: try the one-pager test. Your readers will thank you. And your decisions will get made faster.