The cause is often unclear. The obvious fix has either failed, or it doesn't feel sufficient. It may present as a process issue, a software limitation, or a data inconsistency. More commonly it's a combination, and the visible symptom is not always where the underlying mechanism sits. The first job is to understand what is actually driving the outcome, not just what is visible on the surface.
How I work
Establish what's actually happening
I don't start by building. I start by understanding how the work actually happens: where decisions are made, what those decisions depend on, and where outcomes rely on manual reconciliation or informal knowledge.
That might involve observing the workflow as it's actually performed, reviewing artefacts and data, tracing handoffs, or pressure-testing assumptions. That sometimes includes testing whether a technical approach is viable before committing to it. A quick integration test or proof of concept can save weeks of building in the wrong direction.
The goal is a concise, shared description of cause and effect. If we can't explain the failure clearly, we're not ready to change anything.
Changes in the right order
Once the cause is clear, the question becomes what to change and what to leave alone.
I look for the smallest intervention that resolves the issue properly, without shifting effort somewhere else. That might be a process change, a data correction, a tool, an integration, or removing something rather than adding it. Occasionally the right answer is a new business application. When that's the case, we're explicit about the drivers, what existing tools can't reasonably do, and what success looks like.
Every change goes through the same cycle: design the intervention, build it, introduce it into the live environment, observe how it performs under real use, and adjust. The return point is always design. Even a small adjustment is a decision about what to change and why.
Systems that work when nobody's watching
A system that only works when people remember the rules, double-check the exceptions, and quietly fix inconsistencies isn't really working. It's being held together by effort. I design so the system doesn't depend on vigilance. When it stops being something people think about, that's usually a sign it's doing its job. Then a few months later you realise you haven't worked that extra Saturday in ages, and the stress you used to carry around is gone.
What the work tends to include
In practice, the work usually spans discovery, intervention, and handover.
Establish the facts
Mapping the workflow as it is actually performed
Assessing existing systems and constraints
Identifying where key information, responsibility, and decisions sit
Making hidden work visible, especially reconciliation, exceptions, and handoffs
Design and intervene
Exploring options and assessing them under a risk-benefit lens
Experiments to establish facts or test hypotheses
Building or adjusting tools where they remove measurable friction
Connecting systems where handoffs create error or delay
Designing interfaces that reduce error rates, not just report errors
Embed and hand over
Clarifying ownership and operating boundaries
Supporting handover so internal teams retain control
Leaving behind documentation that matches the reality of how things run
Occasionally this extends to physical or sensor-based systems (IoT) where software interacts with the real world.
On AI
AI can be useful. But I use it where it fits.
The starting point stays the same: what problem are we solving, and what does a correct outcome look like? If that's clear, the technology choice follows. If it isn't, additional technology usually adds complexity without resolving the issue.
This isn't for everyone
If you have a well-defined problem and need a solution, that's straightforward.
If you have a prescribed solution and want someone to implement it, you may be better comparing proposals from technical delivery teams or vendors.
That said, I can certainly sense-check the problem-to-solution fit for you.
I'm most useful earlier, when the problem is unclear, crosses boundaries, or has resisted straightforward fixes.
Or when you have a clear outcome in mind, but you can't yet see a credible path to achieve it with the way the business currently runs.
If there's a persistent friction you can't quite describe yet, that's usually the right time to talk.
Let's chat
Across different industries and tools, the method is consistent: establish an accurate description of what is happening, apply the smallest change that resolves it properly, and avoid solutions that look good briefly but degrade under normal use. If something in your organisation feels harder than it should, that's usually worth a conversation.