Technical decisions are often judged by their immediate result.
Does the system work? Is the performance acceptable? Did the project stay within budget? Does the customer like it?
Those are important questions.
They are not enough.
A technical decision also changes the set of choices available to the organisation in the future.
That is one of the things that makes technical decisions different from many other decisions. The consequences can last much longer than the circumstances in which the decision was made.
Every decision creates a constraint
Choosing a database creates a dependency.
Choosing a cloud platform creates a dependency.
Choosing an API format, identity system, programming language or operating model creates dependencies.
There is nothing inherently wrong with that. Technology would be impossible without making choices.
The important thing is to understand which constraints are being introduced.
Some are cheap to change.
Others are expensive.
And a few can become extremely difficult to reverse.
A good technical decision is therefore not necessarily the one that provides the most capability. It may be the one that provides enough capability while preserving useful options for later.
The cheapest option is not always the lowest-cost option
This sounds obvious, but technology procurement still tends to encourage a narrow definition of cost.
A service might be inexpensive to purchase but expensive to integrate.
A platform might have attractive licence costs but require specialist skills.
A cloud service might reduce infrastructure overhead while creating substantial dependence on proprietary APIs.
A bespoke solution might cost more initially but provide control over an important architectural boundary.
None of these observations leads to a universal answer.
The point is that price is only one part of the decision.
The cost of being wrong matters too.
Reversibility is valuable
When I am considering a technical decision, one question I find particularly useful is:
How difficult will this be to undo?
If the answer is “a few hours”, there is little reason to spend weeks debating it.
If the answer is “it will affect every application we have for the next ten years”, the decision deserves considerably more attention.
This gives us a useful way of separating decisions.
Some are reversible and can be made quickly.
Some are difficult to reverse and should be examined carefully.
The mistake is treating both types as though they deserve the same process.
Decisions should be made at the right level
Another common problem is making a decision at too low a level.
A team may spend weeks comparing database products when the real question is whether the organisation should own this data platform at all.
A development team may debate programming languages when the more important question is whether the proposed system should exist as a separate service.
An infrastructure team may optimise a deployment architecture when the underlying business process itself is unnecessarily complicated.
Good architecture often involves stepping back from the immediate technical question.
Before asking “Which one?”, ask “Why do we need one?”
A good decision leaves evidence behind
Technical decisions should not live entirely in somebody’s memory.
This does not mean producing a fifty-page document for every choice.
A useful record can be remarkably small:
- What problem were we solving?
- What alternatives did we consider?
- What constraints mattered?
- What did we choose?
- Why?
- What assumptions are we making?
- What would cause us to revisit the decision?
The last question is particularly useful.
Technology changes. Organisations change. Assumptions become invalid.
A decision record makes it possible to revisit a decision without having the same argument all over again.
There is rarely a perfect answer
Technical teams sometimes spend too long searching for certainty.
There may not be one.
Architecture is usually about making a decision with incomplete information while understanding the consequences well enough to manage the resulting risk.
A good decision can therefore turn out badly because circumstances changed.
That does not necessarily mean it was a bad decision.
Conversely, a poor decision can produce a successful short-term result.
Judging decisions purely by their outcomes encourages hindsight rather than better engineering.
What matters is the quality of the reasoning available at the time.
Technical judgement is about trade-offs
Almost every worthwhile technical decision involves competing objectives.
Performance against cost.
Flexibility against simplicity.
Security against convenience.
Control against speed.
Resilience against operational complexity.
There is no architecture in which all of these are maximised simultaneously.
The job is to understand which trade-offs are acceptable and which are not.
That is where experience becomes valuable. Not because experience produces a catalogue of answers, but because it helps identify the questions that need to be asked.
When a decision has significant cost or long-term consequences, a technical decision review can help make the options and trade-offs clearer.
Leave the organisation with options
The best technical decisions I have seen tend to have one characteristic in common.
They leave the organisation in a better position to make the next decision.
The system is understandable. Dependencies are known. Important assumptions are explicit. Components can be changed where necessary. The organisation has not accidentally surrendered control of something that matters.
That does not mean avoiding commitment.
It means committing deliberately.
Technology will continue to change. Some decisions will inevitably need to be revisited. The objective is not to predict every future requirement.
It is to avoid making tomorrow’s decisions unnecessarily difficult.
That, to me, is one of the clearest measures of good technical judgement.