"When you've written the code, designed the database, managed the testers, run the infrastructure, and sat in the board conversation about why delivery is slow — you stop seeing silos. You start seeing the whole system."
How I think
What follows are four things I have come to believe through working closely with hundreds of people navigating genuinely difficult organisational situations. The beliefs are structural. The experience that formed them was entirely human.
01
When delivery is slow, the instinct is to look at the people — their skills, their attitude, their effort. Almost always, the real constraint is structural: how the work is organised, how teams relate to the architecture, how decisions are made and by whom. Fix the structure and the people tend to perform the way everyone assumed they already should.
02
Every engagement starts with data, not a hypothesis. Flow metrics, cycle times, deployment frequency, where work actually spends its time. Opinion formed before measurement produces confident-sounding diagnoses that miss the real problem. The numbers tell you things that interviews and workshops don't — including things that are uncomfortable for the business to hear.
03
The system tells you what it needs. I don't arrive with a preferred framework and fit the organisation into it. Scrum, Kanban, Shape Up, something bespoke — what matters is whether the underlying principles of delivery are sound, not which methodology is on the wall. The right structure is the one that works for your architecture, your people, and your stage of growth.
04
The mark of a successful engagement isn't that things improve while I'm there. It's that they stay improved after I leave. That means working with your people rather than around them — building their understanding of what was wrong and why, so the structural fixes belong to them, not to me. What that transfer produces is an organisation capable of carrying its own diagnosis forward: not dependent on the practitioner to return, but able to see structural problems before they compound.
Embedded & Fractional
Embedded and fractional engagements vary in scope and duration. What doesn't vary is the shape of how the work gets done — from the first week to the last.
01
The first weeks are data, not recommendations. Flow metrics, cycle times, where work actually spends its time — all of it is read before any view of the problem is formed. Opinion formed before measurement produces confident-sounding diagnoses that miss the real problem. The numbers tell you things that interviews and workshops don't, including things the organisation hasn't wanted to hear. Often, what looks like a people problem turns out to be a condition problem. And conditions can be changed.
02
Embedded means in the room: standups, planning sessions, the conversations that happen between ceremonies. Engineers and leads notice quickly that the person asking questions has written production code, designed databases, and run teams of testers. That recognition changes the dynamic. What would read as external criticism from management lands instead as a diagnosis from someone who has done the job — and that shift is usually what opens the real conversation up.
03
Every change — to how work is organised, how decisions are made, how teams relate to the architecture — is co-designed rather than installed. The reason is practical: changes the team helped shape are changes that survive after the engagement ends. Changes installed from outside tend not to. What co-design produces, beyond the change itself, is a team that understands why it works — which is what makes it last.
04
The mark of a successful engagement isn't that things improve while I'm there. It's that they stay improved. That understanding transfers to the leads, the CTO, and the teams themselves — so the diagnosis belongs to them, not to me. What that produces is an organisation that can see its own problems before they compound, and knows what to do about them.
In practice, that means different things depending on the engagement. In the first weeks it might be cognitive load interviews across the engineering team, DORA baseline measurement, and mapping where the org chart and the codebase have grown apart from each other. Later, it might be co-design workshops to rebuild how the team plans and commits, a topology redesign against the actual architecture, or a Way of Working playbook the team owns long after the engagement ends.
"What I value most about James is that in working with the teams he knows each person and how a team's dynamics are functioning. He doesn't use a single model and especially in the world of 'agile' he doesn't care what process is used - more that the underlying principles of delivery are sound."
Ben Brown
Chief Technology Officer · Underwrite.me
"Before James came aboard at Onto, I didn't fully understand what an Agile coach could bring to an organisation. His pragmatic, team-focused approaches helped every discipline across the technology org at Onto work smarter with better goal-oriented outcomes, in which open-communication and collaboration came first. James's facilitation skills also helped our Tech leadership team gel together and perform as a much higher performing unit."
Ayman Hafez
VP Product · Onto
"James wasn't just a leader, but a true guiding light in our company, always ensuring we delivered value with predictability and effectiveness. His understanding of agile, combined with his compassionate and patient approach, made him an extraordinary coach to us all, myself included."
Simone Casciaroli
Head of Engineering · Onto
"He takes the required time to understand the teams he works with and adapts his coaching style to whatever its individuals need in order to make the best of agile development. He also works closely with management to help them understand what support engineering teams need in their road to agile mastery. James is a kind and caring person that becomes a trusted member of the teams he is part of."
Razvan Telitoiu
Senior Product Manager · Onto
Founder
Orchiture is the consultancy I founded to give the structural diagnostics work a defined method and a proper home. Where this site is about the practitioner — the embedded, fractional, and coaching engagements — Orchiture is the firm: structured diagnostic engagements for CTOs and technology leaders who need to understand why delivery is slower than it should be, and what the structural conditions producing that look like.
The work spans three phases: diagnostic, co-design, and system restoration. It starts with measurement, not opinion. It ends with a structure that belongs to the organisation — not to the consultant who designed it.
orchiture.comThe diagnostic work is also available as an AI product. The Signal, built and run on orchiture.ai, is a free structural diagnostic that identifies the conditions most likely causing delivery problems in an engineering organisation. It runs as a 15 to 18 question adaptive conversation, produces a named diagnosis, and is built on Next.js with the Anthropic API.
orchiture.ai/signalWhat Orchiture does
Structural diagnostics
Flow metrics, team topology analysis, cognitive load mapping. Finding the conditions that produce slow delivery — not the symptoms.
Delivery architecture
Redesigning team boundaries, ownership models, and ways of working around the architecture, not against it.
System restoration
Embedded change that builds internal capability rather than consultant dependency. The fixes hold after the engagement ends.
Four phases. Each one adds a layer. Together, they produce the systemic view that specialists can't replicate.
2016 – present
A decade of structural engagements across scale-ups, enterprise, and public sector organisations: Intuit, Gousto, Onto, the Office for National Statistics, Flock, NEBOSH and others. The work throughout: finding what is actually causing slow delivery, and fixing the conditions that produce it.
One period stands apart: Head of Agile at Onto (Jul 2022–Apr 2023) was direct employment, not a contracted engagement.
Orchiture, established to give that practice a defined method and a proper home, formalised what the engagements had consistently been about: not installing frameworks, but repairing the underlying structure those frameworks assume is already right.
2009 – 2016
Seven years at the convergence of engineering management, operations, and technical leadership. As Development Manager at a loyalty and payments technology company, built and led a team that grew from five to thirty people: architects, developers, testers, and business analysts. Formal test management responsibility and agile leadership sat within the role from the outset, including introducing Scrum and Kanban to the development department.
Concurrently for the first eighteen months, managed a separate data centre operations team delivering loyalty and payments processing infrastructure for global oil brands and Tier 1 UK supermarkets across the UK and Europe. The clients on the other end of the SLA were organisations with no appetite for failure and the commercial weight to make that felt. PCI DSS Level 1 compliance throughout, passing audit four years in a row. That period produced over 40% year-on-year growth in development revenues.
A year as Head of Systems Engineering at Siemens Traffic Solutions followed, responsible for real-time traffic management systems including the engineering infrastructure behind the London Congestion Charge Zone. Returning to the loyalty and payments company as a member of the executive team reporting directly to the CEO, product ownership and agile leadership operated at organisational rather than team level.
1994 – 2008
Fourteen years progressing through the full technical stack of a software organisation. Starting as a programmer and software engineer, moving into UI design, database architecture and DBA work across SQL Server and Oracle, then into software architecture, culminating as a systems integrations architect responsible for technical direction across an enterprise integration programme — including a US-based period following acquisition by a global workforce management company.
By 2008, the view of a software system was end-to-end: from the interface a user touches to the data layer that persists it and the architecture that holds it together.
Before 1994
The career started not in technology but in finance and accounting: pensions administration and financial analysis, including a year of CIMA study. The work involved designing management information systems, automating accounting processes, and building the financial literacy that comes from working directly with the numbers a business runs on.
That grounding shapes how structural findings are framed today. When a diagnosis needs to hold up in front of a CFO or a board, the ability to build that argument was formed here.
Every phase of this career has added a clearer view of what an engineering organisation looks like when delivery finally works: not faster or more process-compliant, but genuinely capable of building the right things at the right pace. The teams that get there know it immediately. The structural conditions that produce it are within reach of most organisations that are not yet there.
Full profile on LinkedIn →Tell me briefly what you're dealing with and what you're looking for. If it sounds like something I can help with, we'll arrange a call.