Slow delivery isn't usually about your people—it's about your system.
Organizations often approach us with a familiar concern:
“Our team isn’t delivering fast enough—can you come train them up?”
It’s a reasonable assumption. But more often, the problem isn’t in the code—it’s upstream, downstream, and all around it.
The symptom loop
When delivery slows, we naturally look at the team doing the delivery. That’s the visible part of the system, after all. We reach for familiar tools: introduce a new framework, shuffle the board, hold more standups, bring in a specialist to “upskill” the engineers.
But delivery problems are usually systemic in nature. They’re baked into the policies, priorities, incentives, and interactions that shape how work gets done. If you only coach the team, you’re treating symptoms. You may see a short-term bump, but the deeper issues will persist.
A real-world example
At one client, the assumption was that the problem lay with the development team’s technical abilities. Delivery was slow, quality inconsistent, and fingers pointed at code reviews and missed edge cases. We were asked to assess the team and offer technical coaching.
But as we observed the work, a deeper pattern emerged.
Teams were siloed by function—frontend, backend, QA, product. Each group was doing its best to optimize their part of the process.
Product had developed a rigid and extensive intake process in an effort to eliminate ambiguity. But they were constantly rushed to get the next feature spec into the queue.
As a result, their “final” specs often had gaps. Development, in turn, expected exact instructions. Developers were each assigned isolated tickets. If a requirement was unclear, it often took days to get clarification. To avoid blocking, devs were encouraged to juggle multiple features at once. Some would just make their best guess to keep their individual throughput metrics up.
Meanwhile, frontend and backend implementations frequently drifted out of sync—sometimes due to different interpretations of the same story, other times due to misaligned timelines. QA would then test based on the original spec, often catching issues that were technically correct but misaligned with the product’s intent. This triggered a long cycle of back-and-forth between QA, dev, and product—usually after the code was already written.
Everyone was working hard. Everyone was “busy.” But the work wasn’t flowing—it was backing up in queues, slowed by handoffs, waiting states, and clarification cycles. Optimizing for individual efficiency had created a system where collaboration was the bottleneck.
As Deming said,
“A bad system will beat a good person every time.”
So we shifted the focus.
We didn’t start with training sessions or coding workshops. Instead, we got the team working together across roles. We helped them slice work into smaller chunks. We shortened feedback loops. We made it easier to surface ambiguity before it reached the code. And as the system improved—delivery improved. And so did the technical practices.
Behavior, not bandaids
What changed wasn’t just process—it was behavior. And that’s where sustainable improvement lives. Here’s how the shift showed up in practice:
- Make the work visible to expose real bottlenecks—not the developers, but the wait states and work-in-progress.
- Work together to create the alignment that specs and documentation couldn’t.
- Create simple things in small steps to enable steady progress while still learning.
- Validate before, during, and after to reduce costly clarification loops and rework.
When you coach the system, the behaviors change. And when the behaviors change, outcomes follow.
We bring the system lens—every time
Not every engagement is a transformation effort. A lot of our work is straightforward delivery: our Double Agents join teams, write code, and ship valuable features. That’s important work. But even when we’re brought in for pure delivery, we’ve found that clients who are open to adjusting how the work gets done—not just what gets done—see greater benefit, faster progress, and more durable results.
We coach the system not because it sounds impressive, but because it works.