Technical Strategy: A No List, Not a Slide Deck

From the field: 40 slides and “Which strategy?”

The February presentation took real effort. I spent three weeks on it: market trends, what our competitors were using, team structure, and one slide called “2025 technology vision”. At the end there were 14 initiatives: observability, test automation, API standards, a mobile rewrite, a data platform and nine more.

After that pull request comment in July, I stopped and counted. Of the 14 initiatives, 3 were finished, 5 were half done and 6 had never started. In the same five months the team had started two large pieces of work that were not in the deck at all: a trial of a new message queue and a move to a new frontend framework. Nobody had broken a rule. There was no rule to break.

The sharing statistics finished the story: 31 views, 24 of them in the first week. 7 in the next four months. The strategy lived for one week and stayed there.

The mistake was mine, and it had two layers. The first was length: nobody opens 40 slides in the middle of a decision. The second was deeper: there was not a single choice in those 40 slides. All 14 initiatives were good ideas. None of them required giving anything up. A document that says yes to everything guides nobody.

What a strategy is for

An engineering manager is part of maybe ten decisions a week. The team makes hundreds: which library, which service the code goes into, now or later, whether this refactor is worth it. You are not in the room for almost any of them.

That is the only job of a strategy: to make the decisions taken without you point in the same direction. This gives you a simple test. Ask a random person on the team: “What are we not doing this year, and why?” If they cannot answer, you may have a strategy, but it is not working. My February deck would have failed this test on day one, because it had no such list.

One page: diagnosis, policy, steps

At the start of August I deleted everything and started again. I took the structure from the three parts Richard Rumelt calls the “kernel”, and added a fourth one myself. The rule: if it does not fit on one page, you have not chosen yet.

1. Diagnosis: what is the real problem today?

A problem, not a goal. “A world-class platform” is not a diagnosis. It is a wish. A diagnosis has numbers, and it is clear enough that someone could disagree with it. Ours was: in the last six months we had 9 outages in the withdrawal and payment flows. 7 of them came from three services that share one database and lock each other. 40% of the new work requested this quarter also touches these three services.

A good diagnosis has a side effect: it removes many good ideas on its own. A mobile rewrite is a good idea, but it has nothing to do with this diagnosis.

2. Guiding policy: how will we deal with it?

One sentence. It must be sharp enough to tell you which way a decision should go: “In code that moves money, separation comes before speed this year. New features go to the separated service first.” You can use this sentence in a pull request discussion. You cannot use “we will build high-quality, scalable systems”, because everyone already believes they are doing that.

3. Concrete steps: three or four pieces of work with owners and dates

Not 14. Three or four. Each one has an owner, an end date and a sentence that says “how we will know it is done”. We ended up with three steps: move the withdrawal service to its own database (end of November), turn the synchronous calls between payments and withdrawals into events (January), and give these three services clear on-call and runbook owners (end of October).

TECHNICAL STRATEGY - 2025 H2               owner: one name
------------------------------------------------------------------
DIAGNOSIS  : what is the real problem today? with numbers,
             clear enough to disagree with.
             "9 outages in 6 months, 7 from 3 services sharing a DB"

POLICY     : how will we deal with it? one sentence.
             "in code that moves money: separation before speed"

STEPS      : max 4 items. each one: owner + date + done criteria
             1) withdrawal service gets its own DB  - end of Nov
             2) sync calls -> events               - January
             3) on-call + runbook owner for 3 svcs - end of Oct

NOT THIS YEAR:
             each item: what + why + when we talk about it again
             (below)

REVIEW     : start of every quarter, 30 minutes. is the diagnosis
             still true?

The no list: the real core of the strategy

The shortest section of the page turned out to be the most useful one. I wrote four items and added two things next to each: why and when we will discuss it again. The second part matters. Without it, a “no” reads like a permanent ban, and people work around it instead of arguing with it.

The power of the list is that it moves the discussion from a person to a page. In September, the sales team asked for a custom reporting integration for one corporate customer. In the past this would have been a negotiation: I say “not now”, they go to my manager. This time I sent the link to the page. The discussion changed from “why no” to “is this item wrong”. That is a much better discussion, because the answer depends on the diagnosis, not on a person.

Two of my earlier posts connect here. In the backlog refinement post I wrote about killing bad ideas early; the no list does that for the whole year at once. And in the build or buy post I described how to weigh a single “build it or buy it” decision. The second item on the list is the same decision at the strategy level.

How the strategy is used in daily decisions

Writing one page was not enough. The February deck also lived somewhere. The problem was not that the document did not exist. The problem was that nobody looked at it when a decision was being made. So I tied the page to three decision points:

The PR checkbox looks small, but it is what changed behaviour. In the ten weeks since August it was ticked 6 times. In 4 cases the pull request was made smaller or dropped. In 2 cases it went through as a deliberate exception, and the reason was written in the pull request. The February strategy had not changed a single pull request in five months.

Get the no list approved upwards first

Before I shared the page with the team, I took it to my manager. The reason is simple: the first challenge to a no list comes from above. Sales brings a request, it gets rejected, and the request goes one floor up. If nobody on that floor knows the list, it dies at the first escalation, and the team never trusts it again.

It was a twenty-minute meeting. He crossed out one item (“we do not touch the data platform at all” was too strict; reporting needed a small piece of work) and added one line to the diagnosis. He approved the rest as it was. That is why the customer request in September was not a crisis, just a short email thread: the request went up, and the same page was waiting there.

A no also has a cost, and you should not hide it. One engineer on the team wanted to try a new language. The first item stopped that trial. We talked about it openly in our one-on-one: why not now, and under which condition it opens again. The disappointment did not go away. But the feeling of “they closed it without asking me” never appeared. A no with a written reason does not read like a personal rejection.

How it breaks

One page can break too. The ways it breaks are not very different from the ways 40 slides break:

The most dangerous way it breaks is a no list that slowly leaks. The first exception has a reason. The second goes through as “just once more”. Nobody asks about the third. So at the start of each quarter we count the exception reasons written in pull requests. If one item got three exceptions, the item is either wrong or not being followed. Both need to be fixed on the page, not in the corridor.

What did not work for me

• Turning the strategy into OKRs. My first reflex was to rewrite the steps as goal sentences. The goals stayed and the diagnosis disappeared. The team still did not know why these were the goals.
• Writing the page from scratch with the whole team. Seven of us sat in front of an empty page. Two hours later we had a to-do list with 22 items. What works is this order: I write the draft, and the team challenges the diagnosis. You cannot hand over the job of choosing. You can hand over the right to disagree.
• Keeping the no list private. I first kept it between the team and my manager, because I thought the product side would be upset. In August I rejected a small request from product, and the meeting turned defensive, because they saw the list for the first time that day. The next day I opened the page to everyone.

Checklist

Conclusion

The “Which strategy?” reply to that comment was not rude. It was honest. In five months, not one of the hundreds of decisions the team made was based on those 40 slides. The document did not fail. It was never read.

The new page is one sheet of A4. Three lines of diagnosis, one sentence of policy, three steps and four “no”s. No presentation, no applause. But in September a corporate customer request was discussed with a link to that page, and in ten weeks six pull requests referred to it.

The test: can your strategy end an argument in a meeting you are not in? If it cannot, you have a presentation. You do not have a strategy.