What I do
I work with engineering and product organisations to help them get out of their own way.
Most teams don’t struggle because they lack ideas, effort, or capability. They struggle because the system is working against them — usually without anyone intending it.
Teams become trapped by accumulated decisions, organisational structure, unclear ownership, unnecessary coordination, or processes that made sense once but no longer fit the organisation they’ve become.
My job is to understand why the system behaves the way it does, identify what is actually getting in the way, and help remove the constraint with the smallest practical intervention.
My perspective
Most organisations that run into difficulties aren't broken.
They've usually evolved — through growth, acquisition, changing priorities, or accumulated decisions — into a state where the structure is working against the work.
Systems tend to produce the outcomes they are set up for — even if that wasn’t the intention.
The useful question is not "what’s wrong?", but "what in the system is causing this, and what needs to change to shift it?"
The goal isn't "transformation", it's targeted, practical change that removes constraint and lets the team breathe.
Where I typically get involved
- Delivery feels slower than it should be
- Teams are busy but progress is inconsistent
- Work requires too many people / teams to complete
- Decisions are slow, escalated, or unclear
- AI and tools are increasing output, but not outcomes
- Leadership senses something is off, but can’t clearly articulate why
How this is different
There’s no shortage of advice on how engineering teams should work.
The problem is that much of it breaks down under real-world conditions.
I'm not an analyst or consultant who studies these problems from the outside.
I haven’t spent my career advising engineering organisations - I’ve spent it being accountable for them.
Every recommendation I make is filtered through one question:
Would I have been willing to own this decision if I were still responsible for delivery six months from now?
I’m not a 25 year old with a nice polo shirt, smart chinos, and a business degree1. I've actually spent 25+ years inside software engineering organisations, accountable for making delivery work in practice — under pressure, with constraints, and with imperfect systems.
That hands-on experience fundamentally defines my approach:
- Focus on what actually happens, not what should happen
- Identify the real constraint, not a list of issues
- Make fewer, higher-impact changes
- Work with the system as it exists, not an idealised version
My principles
- Almost every "technical problem" is a people or process problem.
- Most organisations have one or two dominant constraints.
- Small, well-placed changes outperform wholesale reorganisation.
- Every recommendation must survive contact with reality.
How I work
Engagements are short, focused, and designed to get to clarity quickly.
The goal is speed to clarity and targeted change, not long-term dependency.
1. Diagnosis (1–2 weeks)
Once we've decided to work together, the first step is a diagnostic - a short, focused engagement to understand how the system actually works in practice.
Find the constraint
The diagnostic takes the form of targeted interviews across the business, focussed on identification of flow, friction, structure, and decision dynamics and providing a clear articulation of what is happening and why.
Output:
- Clear problem definition
- Identification of the primary constraint
- Practical, prioritised actions
Organisations rarely have twenty equally important problems - they usually have one or two key constraints that make everything else harder.
2. Synthesis (2–5 days)
Build a shared understanding
Once the diagnostic interviews are complete, I take some time to stand back, take in the bigger picture, and translate the findings into a clear, shared understanding of what’s actually going on.
- What’s happening
- Why it’s happening
- What's actually limiting progress
- What to change (and in what order)
Most organisations don’t lack information - they lack a shared understanding of what the information is telling them. Alignment starts with a shared understanding — and, most importantly, acceptance — of reality. From there, we can start to improve things.
3. Intervention (optional, 2–6 weeks)
First up, let me be clear that not every diagnostic leads to a wider engagement — if the initial work gives you everything you need then that's just fine by me.
If I can help you to move forwards by extending my involvement then that's also something that I am happy to do.
Change the system
Through targeted interventions, I will support the organisation in removing or reducing the identified constraint(s) through:
- Clarifying ownership and decision-making
- Reducing unnecessary complexity or coordination
- Improving flow and focus
- Introducing practical changes that stick
The best interventions often look surprisingly small in hindsight. That’s because they change the system, not just the symptoms.
4. Advisory (optional)
I'm also happy to provide light-touch, ongoing support — typically a few hours a month to sense-check decisions and maintain momentum after an engagement.
Get in touch
If that sounds good and you think that you've got a problem that needs solving, then let's make it easy:
Tell me what's going on. A few sentences is enough — I'll tell you honestly whether this sounds like something I can help with, and what that might look like.
You can email me or drop me a message on LinkedIn.
I take on a small number of engagements at a time, by design — the model only works if I can give each one proper attention.
My engagements are measured in weeks, not months, and this isn't a day-rate placement - I charge for clarity that changes how the organisation operates, not an hourly rate to sit and nod along sagely.
If your engineering organisation feels like it’s working harder than it should have to, there’s a good chance it isn’t the people holding it back. Sometimes organisations simply need help getting out of their own way.