Knowing a risk exists isn’t enough; action is required to prevent costly failures.
Introduction
I work on complex technology and data initiatives where engineering decisions, delivery constraints, and organisational reality intersect.
My contribution is not a methodology or a toolset, but judgement under constraint: understanding what matters, what can wait, and what trade-offs are actually being made — whether acknowledged or not.
This site is a record of how I think about those decisions.
The kind of problems I work on
I am most effective in situations where technical complexity and delivery risk are tightly coupled.
This typically includes:
- large or business-critical technology programmes
- data and platform initiatives where outcomes depend as much on operating model as on architecture
- environments where ambiguity is high and sequencing matters
- work that requires bridging engineering detail with delivery and stakeholder reality
These are not problems solved by tools alone. They require clarity, prioritisation, and an ability to navigate competing constraints without losing technical integrity.
How I approach the work
A few principles guide how I operate:
- Start from first principles rather than templates
- Make trade-offs explicit, even when they are uncomfortable
- Optimise for long-term capability, not short-term optics
- Treat delivery as an engineering problem, not a reporting exercise
- Stay hands-on where it improves judgement, and step back where it does not
I am comfortable moving between strategy, architecture, and execution when it serves the outcome.
What I deliberately avoid
I am not interested in work where outcomes are structurally unlikely.
That includes:
- programmes that prioritise presentation over capability
- tool-led change without clear ownership or decision rights
- delivery optimised for milestones, decks, or governance optics
- initiatives delivered in organisational or technical silos, with integration treated as a later concern rather than a first-order design constraint
- programmes that ignore how technology, people, and processes interact once in service
- delivery models that rely on subsequent “bridging” projects to compensate for avoidable design and integration gaps
- over-engineering justified by novelty rather than need
- environments where constructive disagreement is treated as resistance rather than input
These constraints are about effectiveness, not preference.
Background, briefly
My background is in electronic engineering, followed by a PhD, and a career spanning senior roles across technology delivery, data platforms, and large-scale change.
I am UK-based and typically work in complex organisational environments where engineering, delivery, and decision-making are inseparable.
For a factual record of roles, titles, and timelines, LinkedIn is the appropriate reference.
How to use this site
- Writing — reflections on delivery, engineering judgement, and common failure modes
- About — how I work and how I think
- LinkedIn — roles, dates, and formal experience
This site is intentionally not exhaustive. It is selective by design.
Closing
If you are interested in how technology decisions are made — not just what was delivered — you are likely in the right place.
If you are looking for a conventional personal brand or a consultancy pitch, this site will probably disappoint.