The organisational lens
Most operational problems aren't caused by a single broken tool or an underperforming person. They emerge from misalignment — between how the organisation is structured, what information flows where, who holds accountability, and what the tooling actually supports.
The problems I see most often:
- Disconnected tools that don't share data cleanly
- Manual workarounds that compensate for gaps in the system
- Data people don't trust — so they don't use it
- AI initiatives without the governance to support them
- Processes that outgrow their documentation
These aren't technology failures. They're systems failures — and they need systems thinking to address them properly.
Before any solution
The questions that matter most, asked before anything else:
- What outcomes are we actually optimising for?
- Where does information originate, and where does it need to go?
- Who holds accountability — and is that clear to everyone?
- What should be automated, and what requires human judgement?
People first, architecture second
Systems are built for the people who use them. Architecture that ignores behaviour, incentives, and context produces adoption problems, not solutions.
This means starting with the human side: who uses this, what decisions do they need to make, what would make their work clearer — and only then designing the technical architecture to support that.
Two things follow from this. First: don't automate a broken process. Automation magnifies whatever is already there. Fix the process first, then decide what to automate. Second: optimise for understanding. If the people using a system can't see what it's doing or why, they'll work around it rather than with it.
Responsible AI and structure
Effective AI adoption isn't primarily a technology problem — it's a systems design problem. The foundations that make it work:
- Defined data flows — clear understanding of where data comes from and where it ends up, before any AI layer touches it
- Clear ownership — someone is accountable for each AI-generated output
- Traceability — knowing which model, which prompt, which data produced which result
- Governance — especially in regulated contexts: documented decision logic, change control, audit trails
- Measurable outcomes — defined before deployment, so you can tell whether it's working
Without these, automation creates risk rather than reducing it.
From thinking to delivery
This approach doesn't stay theoretical. Implementation is part of the work — not something handed off after the thinking is done.
- Understand the system — map current state: what's working, what's not, where the friction actually lives
- Define the outcomes — agree what good looks like before designing anything
- Design for the constraints — people, technology, time, compliance, and the organisation's capacity to change
- Build and iterate — implement incrementally, surface feedback early, adjust based on what the system reveals
Why this matters
Organisations that invest in well-designed systems — human and technical — operate with less friction, make faster decisions, and scale without the instability that comes from patching problems one at a time.
The cost of getting this wrong — in time, in trust, in technical debt — is almost always much higher than the investment needed to design it properly from the start.