Skip to main content
Test Double company logo
Services
Services Overview
Holistic software investment consulting
Software Delivery
Accelerate quality software development
Product Management
Launch modern product orgs
Legacy Modernization
Renovate legacy software systems
DevOps
Scale infrastructure smoothly
Upgrade Rails
Update Rails versions seamlessly
Technical Recruitment
Build tech & product teams
Technical Assessments
Uncover root causes & improvements
Case Studies
Solutions
Accelerate Quality Software
Software Delivery, DevOps, & Product Delivery
Maximize Software Investments
Product Performance, Product Scaling, & Technical Assessments
Future-Proof Innovative Software
Legacy Modernization, Product Transformation, Upgrade Rails, Technical Recruitment
About
About
What's a test double?
Approach
Meeting you where you are
Founder's Story
The origin of our mission
Culture
Culture & Careers
Double Agents decoded
Great Causes
Great code for great causes
EDI
Equity, diversity & inclusion
Insights
All Insights
Hot takes and tips for all things software
Leadership
Bold opinions and insights for tech leaders
Developer
Essential coding tutorials and tools
Product Manager
Practical advice for real-world challenges
Say Hello
Test Double logo
Menu
Services
BackGrid of dots icon
Services Overview
Holistic software investment consulting
Software Delivery
Accelerate quality software development
Product Management
Launch modern product orgs
Legacy Modernization
Renovate legacy software systems
Cycle icon
DevOps
Scale infrastructure smoothly
Upgrade Rails
Update Rails versions seamlessly
Technical Recruitment
Build tech & product teams
Technical Assessments
Uncover root causes & improvements
Case Studies
Solutions
Solutions
Accelerate Quality Software
Software Delivery, DevOps, & Product Delivery
Maximize Software Investments
Product Performance, Product Scaling, & Technical Assessments
Future-Proof Innovative Software
Legacy Modernization, Product Transformation, Upgrade Rails, Technical Recruitment
About
About
About
What's a test double?
Approach
Meeting you where you are
Founder's Story
The origin of our mission
Culture
Culture
Culture & Careers
Double Agents decoded
Great Causes
Great code for great causes
EDI
Equity, diversity & inclusion
Insights
Insights
All Insights
Hot takes and tips for all things software
Leadership
Bold opinions and insights for tech leaders
Developer
Essential coding tutorials and tools
Product Manager
Practical advice for real-world challenges
Say hello
Leadership
Leadership
Leadership
Future-proof innovative software

Why we coach the system, not just the team

Slow delivery isn’t usually about your people—it’s about your system. Shifting focus to incremental improvements in the system helps change not just processes but behaviors for lasting change.
Doc Norton
|
May 9, 2025
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
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.

‍

Related Insights

🔗
Social tech debt doesn’t mean what you think it means
🔗
A plea for lean software

Explore our insights

See all insights
Developers
Developers
Developers
Developer QA checklist for feature releases

Quality Assurance is a mindset integrated throughout development to catch issues early, build user trust, and reduce maintenance costs. These recommended procedures for dev teams without dedicated QA roles establish collective responsibility for ensuring feature stability, functionality, and usability before release.

by
Lee Quarella
Developers
Developers
Developers
From engineer to consultant: The powerful shift from inward to outward focus

What transforms a skilled software engineer into an exceptional consultant? Approach new codebases with respect rather than judgment, embrace constraints as creative boundaries, and prioritize client needs over personal preferences.

by
Dave Mosher
Leadership
Leadership
Leadership
Better alternatives to story points for software product teams

Story points weren't devised to measure productivity, but rather complexity. But teams keep using story points as individual or team productivity "score cards". Here's why that's a problem, and what to use instead.

by
Tammy Lawlor
by
Dave Mosher
Letter art spelling out NEAT

Join the conversation

Technology is a means to an end: answers to very human questions. That’s why we created a community for developers and product managers.

Explore the community
Test Double Executive Leadership Team

Learn about our team

Like what we have to say about building great software and great teams?

Get to know us
No items found.
Test Double company logo
Improving the way the world builds software.
What we do
Services OverviewSoftware DeliveryProduct ManagementLegacy ModernizationDevOpsUpgrade RailsTechnical RecruitmentTechnical Assessments
Who WE ARE
About UsCulture & CareersGreat CausesEDIOur TeamContact UsNews & AwardsN.E.A.T.
Resources
Case StudiesAll InsightsLeadership InsightsDeveloper InsightsProduct InsightsPairing & Office Hours
NEWSLETTER
Sign up hear about our latest innovations.
Your email has been added!
Oops! Something went wrong while submitting the form.
Standard Ruby badge
614.349.4279hello@testdouble.com
Privacy Policy
© 2020 Test Double. All Rights Reserved.