Technical Strategy and Roadmaps

"What is your plan for the platform this year?" "Should we build it or buy it?" "Why are we not doing X?" These questions come from product, from your manager and from interviewers. A list of features is not an answer. This lesson gives a simple frame for strategy, a way to write a one-page technical strategy, and short guides for roadmaps, saying no, build versus buy and migrations.

Read Lesson 0 first for the answer shape. Strategy sits on top of smaller decisions: Lesson 1 (packages), Lesson 2 (languages and frameworks) and Lesson 5 (design docs and RFCs). For debt and the rewrite trap see Lesson 6, and for stakeholders and change see Lesson 10.

Everything here is common practice and opinion. Companies differ a lot. Use the ideas, not the exact words, and always use your own true examples.

Words used in this lesson

• Strategy is a plan for overcoming a specific hard problem, built on an honest look at the situation.
• A diagnosis is a plain statement of what is going on and why it is hard. It is the first part of the frame below.
• A guiding policy is a rule that narrows the choices, for example "we will not add a new database engine this year".
• Coherent actions are the steps that follow the policy and support each other.
• A technical vision is a short picture of where the system and the team should be in a few years.
• A roadmap is a plan of what you intend to work on and roughly when. It is a set of bets, not a contract.
• Now / next / later is a way to show a roadmap in three buckets instead of exact dates.
• Build versus buy is the choice between writing something yourself and paying for (or adopting) a ready-made one.
• A migration is moving from an old system, library or API to a new one.
• An innovation token (from "Choose Boring Technology") is the idea that a team can afford only a few new, risky technologies. I know it from the way charlax's list describes it.

A strategy is not a wish list

Many "strategies" are really lists: improve performance, adopt microservices, raise quality, use AI. Nothing in them tells you what to do on Monday morning, or what to refuse. A simple test: can this document make someone say no? If every idea fits, it is a wish list.

A well-known frame (from Rumelt's Good Strategy Bad Strategy; I did not re-read it, see the note above) has three parts:

Two things make this useful for a lead:

1. The diagnosis is the hard part. A weak diagnosis ("our code is old") leads to weak actions ("rewrite it"). A sharp one ("changes to this module are slow and break other teams") leads to focused actions.
2. The policy removes options on purpose. "We will not add a new datastore this year" is a policy. It helps because people stop proposing five databases and start solving the real problem.

The Strategy section of charlax's list has related ideas. I have only the list's description of each, but the descriptions are useful:

• The waterline principle (attributed to Bill Gore). Imagine a decision gone wrong blows a hole in the side of a ship. A hole above the waterline you can patch and learn from. A hole below it can sink you. Great teams make big bets, but they avoid big bets that can blow a hole below the waterline. For a lead: make most decisions fast and reversible, and slow down for the few that you cannot undo.
• Start from the customer and go backward. The list links a talk where stopping a project was the right call "because it was a technology without any customer".
• Write five, then synthesize. The title of one of Will Larson's posts. I did not read it, so I will only say that the title suggests writing several small pieces first and finding the common thread afterwards.

Technical vision: a picture, not a spec

A technical vision is a few sentences about where you want the system to be in about two to three years, written so that a new engineer can understand it. It is not a design. It is a direction.

A good vision is:

• Short. One page at most.
• Concrete enough to say no. "A small number of services that each one team can deploy alone" is better than "a modern architecture".
• Linked to the business. If the company needs to enter a new market, the vision should say how the system helps.
• Honest about trade-offs. "We accept a larger bill to keep the team small" is a real choice.

A vision that nobody remembers is not a vision. A quick test: ask three engineers separately where the system is going. If you get three different answers, the vision is not working.

The plan is a bet, and dates are ranges

The Planning section of charlax's list has several short ideas about roadmaps. Again, I only have the list's summary lines:

• Expect confidence to fall over time. One article ("The Fundamentals of Roadmapping") says the best a leader can do is a 12 to 18 month plan pointing in the right direction, broken down by quarter, with the assumption that confidence in each later quarter is lower. Team roadmaps then come from those focus areas.
• Plan with milestones, not only stories. A listed article argues for managing through milestones.
• Planning has rules. A listed post ("How to plan?") has bullets such as "do fewer things", "don't wait to kill bad ideas" and "minimize dependencies". I have only the bullets, not the reasoning.
• A checklist for judging a roadmap. Another listed post gives questions such as: does it connect to the mission? Is it outcome-oriented? Is it flexible? Does it name major dependencies and risks? Does it feel aggressive but achievable?
• Outcomes over output. A listed OKR article says objectives and key results should ideally measure outcomes, not output. Another warns about the "build trap": shipping features and forgetting the value they were for.
• A clear theory of success. A listed post asks: "Does our resource allocation actually support our theory of success?" and "What signals will tell us whether our theory is plausible or not, and how long will it be before we get those signals?"

From these I take a few working rules (my own):

1. Treat each item as a bet. Write what you expect to gain, what it costs, and what would make you stop.
2. Give dates as ranges. "Late Q2 to early Q3" is honest. A single date for something far away is a promise you cannot keep. See estimates in Lesson 3.
3. Be firm near, loose far. The next six weeks can be specific. Next year should be a direction.
4. Say how you will know. Pick one measure that would show the bet worked.

Now / next / later

A common way to show a roadmap without false precision:

Example for a platform team (invented for this lesson):

Notice that every item is something a person can start or stop. "Improve quality" would not fit in a bucket.

Saying no (and what to say instead)

A strategy that never refuses anything is not a strategy. A lead has to say no to good ideas. A few ways to do it without losing trust:

• Say no to the idea, not the person. "This is a good idea. It does not fit what we chose for this quarter."
• Show the trade. "We can do this if we drop that. Which do you prefer?" This turns a refusal into a shared choice.
• Link to the strategy. "Our policy this year is to reduce the number of services. A new service would go against it." People accept a rule more easily than a mood.
• Give a later date or a smaller version. "Not this quarter. We can do a one-week spike to check the risk."
• Write it down. A "not doing" list in the strategy page saves repeating the same talk.

The Planning section also lists a post about what to do when "everything is important but nothing is getting done". From the list's bullets: get agreement that there is a problem, make one view of all work, agree criteria for comparing projects, then sequence them and commit to the sequence. I have only the bullets, but the order is sensible: you cannot say no fairly until all the work is on one list.

Build versus buy

charlax's Strategy section links a "Build vs Buy" article (title only for me). Here is a plain way to think about it (my own):

Points to remember:

• The real cost of building is maintenance. The first version is the cheap part. Someone must run it, patch it and explain it to new hires for years. This is the same idea as in Lesson 1: adopting is a promise to keep up.
• The real cost of buying is the contract and the exit. Check data export, pricing at ten times your size, support, and what happens if the service shuts down.
• A thin wrapper helps both ways. Put your own small interface in front of a bought service so you can switch later.
• Choose boring technology where you can. The "innovation tokens" idea (from the way charlax's list describes the talk) says you can afford only a few risky choices. Spend them on things that matter to the product.
• Be careful with the cold-shower list. Charlax's list links hwayne/awesome-cold-showers, "for when people get too hyped up about things". I did not read its entries. The idea of keeping a list of reasons for caution is still useful when a new technology is exciting.

For architecture hype in particular, the Architecture section of awesome-cto includes titles such as "Microservices – Please, don't" and "10 Modern Software Over-Engineering Mistakes". I only know them by title. I mention them because they show that a strong opinion exists on both sides, and a lead should know the arguments for the choice they make.

Migrations: the plan matters more than the target

A migration is where strategy meets daily work. The Technical strategy section of charlax's list has the "Tech Migrations, the Spotify Way" article, summarised there as: ruthlessly prioritize; treat migrations like a product (accountability, test first, train, lead with value, know your customers, make it a bit of a game); and automate, and move up the stack. I did not read the article itself.

The same section has "5 Red Flags Signaling Your Rebuild Will Fail" (title only) and Joel Spolsky's rule against rewrites, covered in Lesson 6.

A migration plan I would write (my own):

1. Why now? One sentence on the cost of staying. If you cannot write it, do not migrate.
2. Scope. What moves and what stays. List the users of the old thing.
3. Tests first. Capture current behaviour so you can compare old and new.
4. Run both. Keep old and new side by side, and move traffic or users in small steps.
5. Automate the boring part. A script (a codemod) that changes many files is safer than hand edits.
6. Make it easy for other teams. Docs, a helper, an owner who answers questions.
7. Set an end date and delete the old path. A migration that never ends leaves you with two systems, which is worse than one.
8. Track progress. A simple count: "31 of 48 services moved".

Changing how people work is also a migration. The Change management section of charlax's list includes "Nemawashi" (quietly laying the foundation for a proposed change, as the list quotes it) and a post on why the status quo is hard to change in engineering teams, with ideas such as "declare process bankruptcy". I have only those summary lines. They agree with Lesson 10: talk to people before the meeting, not in it.

How to write a one-page technical strategy

A one-page format (my own, built on the three-part frame):

# Technical strategy: <area>, <period>## Where we are (diagnosis)Three to five sentences. Facts and numbers. What is hard and why.## What we will do (guiding policy)Two or three rules. Each one should rule something out.## Actions (next 2 quarters)- Action 1 -- owner -- expected effect -- how we will know- Action 2 -- ...- Action 3 -- ...## What we will not do- Item -- reason## Risks and what would change our mind- Risk -- early signal -- what we do## Roadmap (now / next / later)Table, with date ranges, not dates.

Tips for writing it:

• Use real facts. Deploy time, incident count, cost per month, time to onboard. Numbers help argue the diagnosis.
• Write it with the team. Show a draft to the senior engineers first. A strategy that surprises people will be ignored.
• Keep it to one page. If it needs ten, the thinking is not finished.
• Review it on a schedule. Every quarter, ask what changed, and edit the page. Keep old versions so you can see how your thinking moved.
• Keep decision records beside it. The strategy sets the direction. Each large choice inside it can have its own record, as in Lesson 5.

Try it

1. Wish or strategy? Read this: "In 2026 we will improve reliability, adopt Kubernetes, and speed up delivery." Is it a strategy? What is missing? Answer: It is a wish list. There is no diagnosis (what is unreliable, and why), no guiding policy (a rule that rules something out), and the actions are not connected. Rewrite it with a cause ("70% of incidents come from manual deploys"), a rule ("all production changes go through the pipeline"), and steps that fit that rule.

2. Write a policy. Your diagnosis: "three teams use four different queue systems and nobody can fix them all." Write one guiding policy. Answer: For example: "New work uses the queue we already run most. We will not add another queue technology this year, and we will move the two smallest uses over the next two quarters." It rules things out and it gives a direction.

3. Turn a date into a range. A stakeholder asks, "When will the new checkout be done?" You have no estimate yet. What do you say? Answer: "I expect between X and Y weeks after the spike. I will give you a tighter range by the end of next week, and I will tell you early if it moves." Say what the range depends on.

4. Build or buy? You need a way to send email and SMS notifications. Which way do you lean, and what would change your mind? Answer: I lean to buy, because it is common plumbing and not our product's core. I would put a small interface in front so we can switch. I would change my mind if our volume made the bill very large, if privacy rules limited vendors, or if no vendor met a hard requirement.

Interview questions

Key takeaways

• A strategy is a diagnosis, a guiding policy that rules things out, and actions that fit together. If it cannot make someone say no, it is a wish list.
• The diagnosis is the hardest and most valuable part. Use facts.
• A roadmap is a set of bets. Give date ranges, be firm near and loose far, and use now, next and later.
• Say no to the timing, link it to the strategy, show the trade, and keep a "not doing" list.
• Build or buy: ask whether it is core, what it costs to maintain, and how hard it is to leave. Put your own interface in front of anything bought.
• Plan migrations with tests, side-by-side running, automation, an end date and a progress count. Do not leave them half done.
• One page, written with the team, reviewed every quarter.
• The Rumelt frame here is a well-known frame that I did not re-read. The article summaries come only from the reading lists' one-line descriptions. Adapt all of this to your team.

What's next

Next: Career growth, promotion and the staff-engineer path, Lesson 13. Practise: write the diagnosis paragraph of a one-page technical strategy for your own team, using at least two real numbers, and show it to one senior colleague.