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 I was working inside technology organisations, I could not see it either. It was only when I had held accountability for all of the moving parts and done enough of the roles to understand how they connected that I could read the system and predict where the friction would form. From inside any one part, the problem always looks like a local one.
It rarely is. When a technology team stops performing the way it should, the problem is almost never the people. It is the system they are working in. I find where it is breaking down, and I fix it.
When the structure is right, delivery flows. Engineers do the work they were hired to do. The board stops asking where the product is; it starts asking what is next.
50+
product teams worked with
10+
years independent practice
6
structural conditions diagnosed
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. The difficulty is that the metrics often look fine right through it. Velocity stable, sprints completing, no single thing visibly broken - while the underlying condition quietly compounds.
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 is rarely on one line in the accounts. It is the senior engineer who leaves and costs six months of contractor spend to partially replace. It is the delayed release that moved the revenue line by a quarter. It is the sprint capacity absorbed by coordination that should have been absorbed by product. A structural diagnostic costs a fraction of one month of that. It names what is causing it and what to do about it.
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.
What is harder to see from inside is that the conditions producing it accumulated through decisions that made sense at the time. The diagnostic does not relitigate those decisions. It maps what the system needs now, and gives you something credible to present to the board.
I work alongside CTOs as a thought partner and structural diagnostic: someone who can see the system clearly, say what is actually true, and build the case with you rather than for you.
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.
Not ready to talk yet? Run The Signal — a free ten-minute structural diagnostic. No account required.