Frameworks / The Technology-First Trap
The Technology-First Trap
Starting from the capability rather than the constraint. It looks like rigour — and it produces a solution in search of the problem that justifies it.
The technology-first trap is seductive precisely because it does not feel like a mistake. It feels like diligence. The team evaluates models, runs benchmarks, draws architecture diagrams, compares vendors. Every activity is real work, competently done. And at the end of it, the organisation has a sophisticated answer to a question no one in the business actually asked.
Capability-out versus constraint-in
There are two directions you can reason from. You can start from what the technology can do and look for places to apply it — capability-out. Or you can start from where the business is actually bottlenecked and reason backward to what would relieve it — constraint-in. The two feel similar from inside a planning meeting. They produce completely different portfolios.
Capability-out reasoning is comfortable because the capability is knowable, exciting, and vendor-supported. The constraint is none of those things — it is messy, political, and specific to your organisation, which means no vendor deck will hand it to you. So teams quietly substitute the question they can answer for the one that matters.
How to see it in the field
The tell is an organisation that can describe its technology stack in confident detail and its actual bottleneck only vaguely. Ask the team what they are building and you get a fluent answer. Ask them what would change for the business if it worked, and the room goes quiet, or the answer arrives in generalities — “efficiency,” “insight,” “competitiveness” — that could justify anything and therefore justify nothing.
A second tell: the initiative was named after a technology, not an outcome. “Our LLM programme,” “our agent initiative,” “our data lake strategy.” The noun at the centre is the tool. When the tool is the subject of the sentence, the constraint has usually gone missing.
Getting out of it
Force the constraint to come first. Before any capability is evaluated, require a clear statement of the bottleneck it is meant to relieve — specific enough that you could measure whether it moved. If the team cannot articulate the constraint without reference to the technology, that is the finding: there is no problem here yet, only a solution looking for one.
Then rename the work after the outcome, not the tool. “Cut month-end close from ten days to three” is a constraint. “Deploy an LLM in finance” is a capability. The first tells you when you have succeeded. The second can run forever.
Part of the Frameworks series. Related: the Pilot Trap and the Solo Trap.