The bottleneck isn't building anymore. It's adoption.

For most of software's history the scarce resource was engineering capacity. Could you build it fast enough? That's what agility was designed to protect — focused teams, short cycles, clear priorities, less waste. And it worked.

Then AI made building cheaper by an order of magnitude. Delivery organizations can move faster than ever, and the constraint stopped being engineering. It became adoption — whether your customers can absorb, integrate, and get value from what you deliver quickly enough to stay.

When delivery outpaces adoption you get a familiar pattern: projects that technically completed but didn't land, implementations that stalled inside the customer's organization, renewals lost not because the product was bad but because the value never became visible. That's where I work. I unpacked the deeper version of this argument in AI Didn't Kill Agile, It Moved the Bottleneck.

The pattern is consistent whether you call it professional services, customer success engineering, or forward deployed engineering. One forward deployed engineer dropped into a customer usually figures it out. Five to fifty of them is a different problem — that's where you need a consistent way of working, or the whole thing turns into reactive chaos. The instinct is to hire more people or work harder, but more people in a reactive system just creates more reactive chaos. The constraint isn't headcount. It's the operating model.

1. 01

   With the vendor’s delivery organization

   I work with delivery and professional services leadership to read the current operating model — what’s working, what’s driving churn or margin pain, where the structural gaps are — then co-design a better way to run it, including AI-native development and implementation practices. Implementation usually includes hands-on coaching for delivery leaders, project managers, and teams.

2. 02

   With the customer’s initiative team

   When an investment isn’t paying off, the problem is often on the buyer’s side as much as the vendor’s: underprepared internal teams, fuzzy success criteria, weak governance of the vendor. I help enterprise teams build the absorption capacity and operating discipline that turn an implementation into actual impact — which also creates the retention and LTV the vendor needs.

3. 03

   With both sides as one delivery team

   The interventions that move fastest put vendor and customer on a shared operating rhythm with aligned metrics and a feedback loop that actually works. Instead of a relationship defined by contracts and escalations, you get a partnership pointed at one outcome. It’s harder to set up and dramatically faster at producing results.

IDEMIA — Identity Technology (DMV systems, TSA PreCheck, law enforcement)

IDEMIA's Civil ID division ran 11 teams across multiple sites, all in reactive mode. Engineers were constantly pulled off implementation work to fight support fires, projects took twice as long and cost twice as much, and because the division was paid per license rather than per implementation, delays hit revenue directly.

We restructured delivery around stable, focused teams — separating Product Development, Program Delivery, and Sustainment so implementation capacity stopped bleeding into support — and introduced an incremental SAFe adoption with a flow-based operating rhythm that made workload visible. Budgeted hours dropped 25%, delivery ran on schedule, and concurrent program capacity tripled from one program at a time to nine in parallel. Product innovation resumed after years of stagnation, and Civil ID became the model for delivery transformation inside IDEMIA.

NEC — Law Enforcement Biometrics (AFIS, fingerprint identification)

NEC's law enforcement division hit a crisis during COVID: a major product release colliding with multiple high-profile customer implementations, cost and schedule overruns, and a "fire of the day" culture that left nothing finished and nobody profitable. The underlying problem was that delivery and product were sharing the same people with no boundary between them — delivery pulled product people into support, product pulled delivery people into features, and neither could build momentum.

We separated the functions, established clear ownership for each track, and introduced a flow-based operating rhythm with Scrum, Kanban, and a PI Planning cadence that let teams coordinate without constant interrupt. NEC launched their new ID7 platform while simultaneously upgrading a set of tier-1 customers — something that would have been unimaginable a year earlier — and predictability, quality, and business performance all rebounded.

"Predictability and quality have improved significantly since we started this journey, and business outcomes have improved tremendously." — Steve Lizotte, former VP of Engineering, NEC

Amdocs — Enterprise Software Professional Services (billing, CRM, network OSS)

Amdocs' professional services group was delivering large-scale customer experience implementations across 10,000+ people in the US, UK, India, Cyprus, Canada, Ireland, and Brazil — some of the most complex enterprise delivery at scale anywhere. I led their SBG delivery transformation over several years, building the internal agile capability, developing the guild infrastructure that sustained it, and working hands-on across business groups to turn chaotic delivery into consistent, measurable flow. The story of how the Kanban Method reshaped their delivery operations was later presented at the Lean Kanban conference.

I've spent more than 15 years in the trenches of delivery — not advising from a slide deck, but working alongside teams and leaders to make delivery more predictable, more valuable, and more responsive under real-world pressure. The constant through all of it is pragmatic agility: Scrum, Kanban, flow, and SAFe used as means to an end, never as the point. When a framework doesn't fit the work in front of us, the framework gives.

I've done this across a deliberately diverse set of contexts — biometric identity systems, telecom and network OSS, law-enforcement platforms, hardware-plus-software products, regulated environments, and AI-native software. That range matters here, because forward deployed and professional-services delivery looks different in every solution context, and the leaders who struggle most are usually the ones handed a generic playbook that ignores their reality. I don't install a framework. I help you find the operating model that fits your work, then make it stick.

For the curious: I'm a Professional Scrum Trainer, a SAFe Fellow and SPCT, and co-creator of Scrum.org's Professional Scrum with Kanban, which has reached thousands of practitioners worldwide. But the reason this work fits me isn't the credentials — it's that I've spent my career on one specific problem: making delivery systems produce predictable value under real constraints, and now doing it where AI has moved the constraint to adoption.

Bring what's actually happening: where engagements are stalling, where margin is leaking, where customers aren't adopting, or where delivery and product keep colliding over the same people. No pitch, no preset framework. I'll share what I see, and you'll leave with a clearer read on the highest-leverage move.