What decision must become easier?
A system is useful when it improves a meaningful decision. If the decision is unclear, features only make the uncertainty more expensive.
Clarity before complexity.
Twenty-one years between business questions and technical implementation. The work begins by finding the decision that matters.
Read how I thinkI help organisations make difficult decisions about products, systems, automation and AI — before those decisions become expensive.
01 · Thinking
The hard part is deciding what deserves to exist.
Technology makes possibilities abundant. Judgement decides which possibilities are useful, which are premature and which should be declined.
People often arrive with a solution already in mind. A platform. An integration. An automation. An AI feature.
I begin one step earlier. What is uncertain? Which decision has been postponed? What must the organisation understand before it commits time, money and trust?
The visible request is rarely the whole problem. A slow process may be hiding unclear ownership. A failed integration may be exposing conflicting definitions. A new product may be an attempt to avoid a harder operational decision.
Sometimes the answer is a new system. Sometimes it is a smaller one, a clearer process or a deliberate decision not to build.
Where does the uncertainty actually sit?
It may sit in the data, the process, the ownership, the incentives or the definition of success. Technology can expose uncertainty, but it cannot decide it away.
What is the cost of being wrong?
Move quickly where reversal is cheap. Slow down where trust, money, operational continuity or customer data is involved.
Good judgement is visible in what is built, and in what is quietly declined.
02 · Selected work
Selected situations, told through the decisions that shaped them.
The output matters. The judgement behind it matters longer. These stories focus on the request, the underlying problem and the decision that changed the direction.
Scroll to move through01
A booking journey that could not be trusted end to end
A simple patient form concealed a chain of disconnected decisions involving identity, appointment availability, payment and clinical records.
- The request
- Connect a website form to a clinical platform and create appointments automatically.
- The real problem
- Several systems could each succeed while the booking as a whole still failed. Manual reconciliation had become the safety net.
- The decision
- Treat the journey as one controlled transaction. Validate patient, provider, slot and payment before committing downstream.
The design goal changed from “send data faster” to “make every confirmed booking dependable.”
02
Several systems, no shared definition of the truth
Property information moved through feeds, a website and operational teams. Each source appeared authoritative until values disagreed.
- The request
- Import listings, images, agents, categories and status changes reliably.
- The real problem
- Ownership of individual fields was unclear. Failures were difficult to trace, and corrections could be overwritten by the next import.
- The decision
- Assign a source of truth to every field, make state changes explicit, and design recovery before adding speed.
The importer became less important than the operating rules around it.
03
Automation without automating the confusion
A team wanted approvals, evidence and database updates to move faster. The process first needed clearer accountability.
- The request
- Replace a sequence of manual changes, emails and updates with an automated workflow.
- The real problem
- Exceptions, access control and audit evidence had never been designed as part of the process.
- The decision
- Keep judgement with people. Automate movement, evidence and consistency around those decisions.
The result was not fewer people in the process. It was fewer reasons for those people to doubt it.
03 · Notes
What twenty-one years have made difficult to ignore.
The fastest route to clarity is often a better question, not a better tool.
Most fragile systems are held together by people performing invisible judgement.
Complexity grows quietly. Its cost appears later, in every change that becomes harder to make.
Automation should remove repetition without removing accountability.
A system people cannot explain is difficult to trust, even when it technically works.
04 · Principles
Three beliefs that survive changes in technology.
Tools change quickly. The conditions for making a sound decision do not.
Start with the decision.
A useful system should make an important decision easier, safer or better informed. If it does not, the work is probably addressing the wrong problem.
Complexity must earn its place.
Every added capability brings maintenance, dependence and future choices. The return should be clear before the cost becomes permanent.
Clarity is part of the product.
Naming, ownership, documentation and visible trade-offs matter as much as the interface. A system people cannot explain is difficult to trust.
05 · Engagement
Most useful before a difficult commitment becomes expensive.
I am usually invited in when the direction is unclear, the system has become hard to trust, or the proposed solution feels larger than the problem.
Bring the uncertainty before the requirements.
- Clarifying what should be built before a team commits.
- Reviewing an existing product or system that has become fragile.
- Translating business intent into a practical technical direction.
- Evaluating options, trade-offs and risk with leadership.
- Staying involved through delivery when continuity matters.
A considered conversation
Bring the decision you’ve been postponing.
A useful first conversation does not need polished requirements. It needs an honest account of what is uncertain, what is at risk and what decision cannot remain vague.