Make the choices visible.
A technology decision is a business choice about what to pursue, what to defer and which risks to accept. The team needs to see those choices before it can commit to the work.
Prototype content: this page expands the proposed approach. Activities and outputs are illustrative, to be agreed for each engagement.
Start with the decision.
Then examine the technology.
“We need a new platform” already assumes an answer. A more useful question is: what is preventing the business from serving customers reliably, and what is the smallest credible change that addresses it?
Building on the discovery work, this stage makes the constraint, available capacity and consequences explicit. A recommendation should explain why one option fits the business now, and what evidence would change that judgement.
Doing nothing belongs in the comparison too. It has a cost and a risk, even when it needs no new budget approval.
Compare credible paths, on the same terms.
Consider a platform that is slowing delivery. These are possible choices, not a recommendation for an actual business. Each needs evidence about customer impact, team capacity, dependencies and the cost of transition.
| Decision lens | Stabilise what exists | Replace incrementally | Replace in full |
|---|---|---|---|
| Potential value | Address the immediate reliability or delivery constraint. | Improve a bounded part while keeping the service running. | Remove constraints that cannot reasonably be separated. |
| Trade-off | Retain underlying limitations and a future change burden. | Carry old and new systems together during transition. | Commit substantial capacity before the full benefit is visible. |
| Risk to examine | Local fixes may hide a deeper structural problem. | Integration and migration can consume the expected gains. | Cutover, scope growth and delayed feedback can compound. |
| Evidence needed | Can targeted work remove the actual bottleneck? | Is there a useful boundary and a viable migration path? | Why would smaller interventions fail to meet the need? |
| Useful early test | Change the constrained area and observe service and flow. | Move one bounded capability and test its operation. | Test the hardest migration assumption before committing. |
The baseline is the current system, including the cost of waiting. Compare ongoing operation, transition, review and displaced work, not just implementation effort.
Leave a decision people can act on.
A short decision record keeps the reasoning visible after the meeting. It gives the team a shared reference when priorities change or assumptions meet reality.
Suggested record, not a mandated template or promised deliverable.
- The choice
- The problem to solve, the chosen option and the alternatives set aside. Include what is explicitly outside scope.
- The rationale
- The evidence behind the recommendation, the assumptions still untested and the opportunity cost of committing.
- The authority
- Who can approve the commitment, who owns delivery and which people must be consulted. These responsibilities may sit with different people.
- The exposure
- Which risks are accepted, who owns each response and what would trigger escalation, a pause or a different path.
- The review
- The first useful checkpoint, the evidence to collect and the conditions that would justify continuing, changing or stopping.
Measure the consequence,
not just the activity.
Choose a small set of measures that can influence the next decision. Agree a starting point, a source and an owner before interpreting a change as progress.
If the aim is reliable delivery
Look at how work reaches users and where it waits. Pair release cadence or lead time with service failures and rework, so more frequent releases do not conceal worse outcomes.
If the aim is sustainable cost
Look at operating cost in relation to useful service delivered. Include support effort and transition costs, and keep resilience in view. A smaller infrastructure bill alone cannot establish value.
If the aim is useful AI adoption
Look at accepted work and total effort, including human review and correction. Check quality and failure consequences alongside speed. An impressive demonstration is only a starting hypothesis.
What if the answer is still uncertain?
The evidence is incomplete
Name the assumption that could overturn the choice. Design a bounded test with a clear question, an owner and a stop condition. Further discovery is useful when it can change the decision; otherwise it can become a way of deferring it.
The leadership team disagrees
Separate disagreement about facts from disagreement about priorities or risk appetite. Put the competing consequences in writing, identify who holds the decision right and record the choice. The team needs a clear direction even when there is no unanimous preference.
The preferred option exceeds capacity
Make the displaced work visible. Reduce scope, change the sequence or reconsider the commitment. A plan that assumes unavailable people is not ready for execution, however attractive its intended outcome.
A choice is the start of the work.
Move into delivery with a named owner, a bounded first step and a review point. Keep the reasoning close enough to the work that new evidence can change the plan.
Next: stay with the work