It’s easy to optimise for the thing directly in front of us.
A feature needs to ship. A bug needs fixing. A deadline is approaching.
So we make the decision that gets us there fastest.
Sometimes that’s exactly the right decision.
But technical strategy is about asking one more question:
“What does this decision mean for us six months from now?”
A technical decision usually has at least two dimensions:
Immediate value — Can we solve the problem now?
Long-term impact — What will this make easier or harder later?
This doesn’t mean building everything for the future.
In fact, over-engineering can be just as harmful as technical debt.
The useful question is:
“What future are we actually likely to need?”
For example, if we’re repeatedly building similar AI applications from scratch, it might be worth investing in reusable infrastructure or common components.
But if something has only been built once, building a large framework for hypothetical future use may simply create unnecessary complexity.
So technical strategy isn’t about always choosing the “cleanest” architecture.
It’s about making deliberate trade-offs.
Things worth considering:
- What are we optimising for?
- What will this decision cost us later?
- Are we creating unnecessary coupling?
- Is this becoming a repeated pattern?
- What should be standardised?
- What should remain flexible?
- Where is technical debt actually worth taking?
The goal isn’t to predict the future perfectly.
It’s to make decisions today while being conscious of the future they create.
Good technical strategy isn’t building for every possible future. It’s avoiding decisions that unnecessarily limit the futures you may actually need.
Top comments (0)