05 / Discipline
Technology Consulting
Decisions made before complexity compounds.
The expensive decisions are made early, quietly, and usually by whoever happened to be in the room.
The work is subtraction.
By the time a system is difficult to change, the decisions that made it difficult are two years old and nobody remembers making them. They were rarely wrong at the time; they were made without the constraint that turned out to matter.
Our job is to surface those constraints while they are still cheap, put the real options side by side, and write down why one was chosen - so the next team inherits a decision rather than a mystery.
What that means in practice
Six things this discipline actually does.
- 01
Architecture review
An honest read of what you have, what it costs to run, and which parts are actually holding delivery back.
- 02
Build versus buy
The comparison done properly, including the cost of integration, the cost of leaving, and the cost of the thing nobody priced.
- 03
Platform strategy
What to standardise, what to let teams choose, and where a shared platform genuinely pays for its own maintenance.
- 04
Delivery planning
Sequencing that lets value land before the whole programme does, with the risky work brought forward rather than deferred.
- 05
Team and capability
What to hire, what to partner for, and what your team should own because it is your actual differentiator.
- 06
Technical due diligence
For investment or acquisition: what is real, what is debt, and what the first twelve months will cost.
How it runs
Four stages, in this order.
The order is the method. Every stage produces something the next one needs, and skipping one means the stage after it is guessing.
- 01Audit
Look at the actual system
Code, infrastructure, delivery history and the people running it. Documentation describes intent; the repository describes reality.
- 02Constraints
Name what cannot move
Budget, regulation, existing contracts, team size, the two systems that will never be replaced. Options that ignore these are not options.
- 03Options
Put three on the table
Each costed, each with its failure mode stated. Including the one where you change nothing, because sometimes that wins.
- 04Commit
Write the decision down
What was chosen, what was rejected, and what would have to be true to revisit it. This document is the deliverable that keeps paying.
Outcomes
What came out of it.
Sample figures from representative engagements. Not a guarantee, and not an average.
- 3
- Costed options per decisionIncluding the do-nothing case
- −41%
- Platform run costRepresentative twelve-month review
- 6wk
- Typical engagementAudit through to committed roadmap
Asked often enough to answer here.
Will you recommend your own delivery team?
Sometimes, and we will say so plainly when we do. The roadmap has to stand on its own - if it only works when we build it, it is not a roadmap.
What if the answer is that nothing needs to change?
Then we say that. It has happened, and it is a considerably better outcome than a programme nobody needed.
Do you work with in-house engineering teams?
Almost always. The best result is your team holding a decision they helped make, not a document they were handed.
Rarely on its own