10+ years building and running engineering teams across six sectors — and making AI adoption survive contact with reality.
Auto-cycling · tap any tile to explore
Track record
Built incident and problem management from nothing
Severity classification, escalation paths, RCA standards and a known error database, introduced at a site of 30+ engineers where none of it existed.
Took delivery ownership for cross-functional teams
Backend, frontend, QA and DevOps under one plan, with quarterly roadmap commitments owned jointly with Product.
Owned engineering OKRs and KPIs at monthly, quarterly and yearly cadence
Including budget, cost control, attrition and contract management — the numbers a business actually asks about.
Ran release management across team boundaries
Acting release manager for cross-team implementations, and deputy delivery manager across multiple concurrent customer programmes.
Delivered customer-facing RCA under contractual SLA
In a carrier-grade telecom environment, where the analysis was a deliverable with a deadline rather than an internal document.
Drove AI adoption across an engineering organisation
Governance first, then rollout into the workflows people already resented, measured on the work rather than on tool usage.
Where I add value
Four problems I’m brought in to solve.
01
Governance answered before the tool arrives — what data may leave, what needs human review, who is accountable when it’s wrong. Then rollout into the workflows people already resent, where output can be judged on sight.
→ Capacity you can defend to a regulator.
02
Scrum, Kanban and SAFe each solve a different problem. I diagnose which constraint actually binds — commitment, flow or cross-team dependency — and take only the parts that address it, then hold the team to outcomes rather than ceremony.
→ Process people follow because it helps them.
03
Roadmap and quarterly planning with Product, releases coordinated across team boundaries, and forecasts that survive contact with reality.
→ Dates the business can commit to.
04
Team structure and ownership boundaries, hiring that holds up under growth, and a second layer of leadership able to decide without me in the room.
→ Capacity that scales past the bottleneck.
AI in engineering
AI is the fastest way to add capacity to an engineering team, and the fastest way to add risk. The job is knowing which is which.
The pattern that works: start with a workflow people already resent, where the output can be judged on sight and being wrong is cheap. Answer the governance questions before the tool arrives. Then measure the work — cycle time, review load, time to first response — never how many people opened the tool.
Perspective
Two positions I hold strongly enough to argue for.
Most companies are good at incident management and almost nobody is good at problem management.
Incident management restores service. Problem management makes sure the same class of failure costs less every time it appears. A team that only does the first is very busy and never gets quiet.
The known error database is the organisation’s memory. When it is maintained, an engineer meets a failure a colleague already solved and closes it in ten minutes. When it isn’t, they rediscover it, and the company pays twice for the same lesson.
“Human error” is never a root cause. It describes a system that permitted the error and didn’t catch it.
An analysis that terminates at a person has failed, and I’ll send it back. The useful question is why the command was available, why nothing flagged it, and why recovery took as long as it did. That is the only version that produces a fix.
Fifteen engineers and thirty are not the same job scaled up. They are different jobs.
At fifteen you hold every thread yourself, and your instinct is right because it rests on direct observation. That is exactly what betrays you at thirty: your information becomes second-hand, and the instinct keeps firing with the same confidence on much worse data.
Across several teams, almost all delivery variance lives in the connections between them — the dependency raised too late, the shared service nobody owns, the release needing three teams to align on one afternoon. Working harder inside each team does very little for that.
You stop optimising decisions and start optimising who gets to make them.
You now lead through people whose judgment you must trust before you have evidence for it. Managers who can’t tolerate that never build a second layer — and an organisation without one is a large team with a bottleneck at the top.
Toolkit
Working versions of the thinking I bring to a team. Pick one.
01
Answer three questions about the team, not the framework.
What does the business need from this team?
How much of the work crosses team boundaries?
What constrains release?
RECOMMENDED OPERATING MODEL
Scrum
A team that owes the business dates, owns most of its own work and can release when ready. Sprint cadence gives the forecast something to be measured against.
Drop: story points as a performance measure, and any ceremony nobody can name an outcome for.
02
Drag to set headcount.
WHAT BREAKS HERE
Stretching
You start hearing about problems rather than seeing them. Name owners now.
03
Pick what you are actually trying to move.
Track
Stop tracking
OKR SHAPE
—
04
Tick what is already true.
READINESS · 0/6
Not ready
People will use these tools anyway, without the review. That is the worst outcome available: all of the risk, none of the visibility.
Credentials
Seventeen certifications across agile delivery, service management and AI.
Contact
Tell me what is going on and I will tell you what I think is underneath it. A first conversation costs nothing and usually clarifies whether the problem is the one you think it is.