Making technology teams work better
Making technology teams work better
I work with technology leaders to find a better way of working - so their teams deliver more, without burning out the people in the process.
When a technology team stops performing the way it should, the problem is rarely the people. It's almost always the way the work is structured. I fix that.
When the structure is right, delivery flows. Engineers do the work they were hired to do. The board stops asking where the product is - and starts asking what's next.
Missed delivery windows. Engineers leaving because they can't ship. Sprints that complete but products that don't move. Every week of structural friction is runway burning while the board asks questions you can't answer with confidence.
And behind the commercial numbers, there's a human cost. The CTO fielding board questions they can't answer with certainty. Senior engineers whose skills are wasted on coordination. Teams that are trying hard and still falling short - not because of who they are, but because of how the system is built around them.
The fix isn't a new process. It's a structural one.
30 years of experience across organisations including
"What I value most about James is that in working with the team he knows each person and how a team's dynamics are functioning. He doesn't use a single model and he doesn't care what process is used - more that the underlying principles of delivery are sound."
If your board is asking why delivery is slower than the size of your engineering team suggests it should be - and "we need to hire more engineers" is the only answer coming back - there's a structural problem worth examining.
The cost isn't just the delayed product. It's the engineers who leave, the contractors brought in to patch, and the runway lost to problems that a different team structure would prevent.
Start a conversation →If you're managing the symptoms of structural friction rather than its source - the team that's always nearly done, the sprint that completes but the release that doesn't - you already know this isn't a people problem.
I work alongside CTOs as a thought partner and structural diagnostic: someone who can see the system clearly, say what's actually true, and help you present a credible path to the board.
About James →How it works
Three steps. It starts with a conversation. Commitment only if you choose to proceed.
We talk through what's happening - commercially and structurally. No brief required. Plain description is enough to start.
A bounded 3–4 week engagement that identifies the structural root cause. Measurement before opinion. The right next step becomes clear from the findings.
We co-design the structural changes together. Bespoke to your people and your architecture - not a template dropped in from outside.
You've doubled the team in 18 months. Velocity hasn't kept pace. Each missed sprint costs more than the last and the board wants answers.
Senior engineers are exiting. The exit interviews say "the work isn't interesting" but the real issue is structural - they can't ship because of how the system is organised, not because of skill.
You've tried agile coaches, new frameworks, reorganisations. It improves for a quarter, then reverts. That's because the root cause is structural, not behavioural.
The org chart reflects how the company grew, not the system it needs to build. Your teams and your technical architecture are fighting each other.
Individual developers are more productive. But collective delivery hasn't improved. Teams in the storming phase with AI need structural help, not more tools.
Previous consultants delivered something, but it didn't last. What was installed was a dependency, not a capability. The system needs to sustain flow on its own.
Most teams are currently in the storming phase with AI - individuals using it differently, no shared norms, competing approaches. Moving from that to consistent, collective output isn't a tooling problem. It's a structural one, and it responds to exactly the same kind of diagnostic work as any other delivery bottleneck.
"The ask from investors and founders has changed. It's no longer 'scale the team.' It's 'get more output from the team you have - including with AI as part of the system.'"
Thirty years working inside virtually every role a technology organisation contains. From software engineer, database architect and test manager through to engineering director, including five years as an engineering manager across regulated PCI DSS infrastructure for Tier 1 global enterprise clients. That isn't background colour. It's what makes it possible to read the structural patterns accurately and name what's actually causing the problem, not just what it looks like.
See how I workWhen the structure is right, the work is different. Senior engineers spend their time building, not coordinating. Product and engineering stop fighting and start finishing. The sprint that was always nearly done starts shipping reliably.
The CTO stops arriving at board conversations holding a problem. They arrive holding an analysis - and a plan. The question shifts from "why is delivery slow?" to "what are we going to build next?"
That's the destination. Structural work is how you reach it.
Engineers doing the work they were hired to do.
Delivery predictable enough to present to the board with confidence.
A system that sustains its own flow - not a dependency on the consultant.
A conversation costs nothing. Most people leave it knowing they're looking at a structural problem - and what to do about it.