Stop Making Technology Decisions. Start Making Trade-offs.

A principal engineer once sent me a 22-page document recommending a technology. It was rigorous, well argued and clearly the product of a fortnight's work. It was also close to useless, because in 22 pages it never once said what we would be giving up by choosing it.

I signed it anyway. That was my mistake, not his, and we paid for it about seven months later.

The shape is familiar because most of us were trained into it. You evaluate the options, you build a comparison table, you weight the criteria, the preferred option wins, you write it up. The document reads as objective. The table has numbers in it.

But a decision where one option is better on every axis is not a decision. It is a purchase, and it did not need a fortnight. Real choices in this industry all have the same structure: this option buys you something, and it costs you something else, and you are choosing which problem you would rather have in two years.

When the cost is missing from the write-up, one of two things is true. Either nobody looked for it, in which case you are about to meet it by surprise. Or somebody found it and left it out because they had already decided and the document was advocacy dressed as analysis. I have done both. The second one is more common among strong engineers, and it is more dangerous, because strong engineers are persuasive.

Whatever else you write, the decision has to survive in four sentences.

We are choosing X. This buys us A. It costs us B. We will know we got it wrong if C.

The last line is the one that people resist, and it is the one that matters most. A trigger condition, written in advance, in public. Something observable that would tell you to revisit. "If the operations team is spending more than a day a week on this by the end of the second quarter." "If we have not migrated the third application by November." "If we need a second specialist to keep it running."

Writing that line does something to the conversation. It converts an argument about who is right into an agreement about what evidence would settle it, and it gives the person who disagreed with you a way to raise it later that is not "I told you so". That is worth a lot when the person who disagreed is the one who has to support the thing.

It also protects you. A decision that turns out badly but had its trip-wire written down is a leader managing uncertainty. The same decision with no trip-wire is a leader who got it wrong and didn't notice for a year.

A 6-person security team at a county council, looking at whether to build an internal vulnerability management platform or buy one.

The build case was genuinely good. The team knew exactly what they wanted, the off-the-shelf options all had awkward gaps around the council's statutory reporting, and the engineers were keen. Three months of work for two people to reach a first useful version.

The cost, when we made ourselves write it down, was the part nobody had said out loud. Two engineers out of six for a quarter, which we could just about absorb. Then roughly one engineer's ongoing attention forever, which we could not. Six people is a very small team, and losing a permanent sixth of your capacity to maintaining tooling that does not differentiate the service is a real price. The other half of it was that the two engineers who knew the platform became single points of failure the moment they built it.

We bought. It was the less interesting answer and I was not popular for a fortnight. The four lines went into the decision record, including the trip-wire: if we end up writing more than three significant workarounds for the statutory reporting gaps in the first year, we revisit.

We wrote two. Close enough to the line that the conversation was worth having, and we had it with evidence instead of with feelings.

The reason the same technology argument keeps reappearing in your planning meetings is almost never that the participants are stubborn. It is that nobody has said, out loud and in writing, what this piece of work is optimising for.

Speed to a regulatory date is a different strategy from lowest total cost of ownership, which is a different strategy again from keeping options open because the business might be sold next year. Each one makes a different option correct. Two smart engineers arguing about a database while holding different unstated goals will argue forever, and both will be right.

So put it on the page, in one sentence, before the options. "For this programme we are optimising for hitting the March deadline with the team we already have. We are accepting higher run cost for two years to do that." Now the argument becomes solvable. Now somebody can tell you that the goal itself is wrong, which is a much more useful disagreement to be having.

And check the choice against more than the technology. Does it serve the outcome you promised, can the people you actually have run it, does the business get value it can see, and does it still look sensible in three years. A decision that wins on elegance and loses on the other three is not a clever decision. It is one you will be explaining to somebody's boss.

Take the biggest live technical decision on your desk. The one that has been circling for a few weeks.

Write the four lines. Choosing X, buys us A, costs us B, wrong if C. Keep it to one short paragraph, and make C specific enough that somebody other than you could check it.

Then send it to the person who will still be supporting this thing in two years when you have moved on, and ask them one question: what did I miss in line three?