What Actually Moves a Software Team
Some teams execute the same rituals and deliver reliably. Others go through the motions and ship little of value. The difference is not the process. It is what happens between the meetings — and the conditions that make real work possible.
The situation
A large technology organization had implemented a standard iterative delivery approach across multiple product lines. Teams ranged from early-stage efforts building new capabilities to mature products supporting millions of users. All followed the same formal structure. Yet team velocity varied wildly.
Some teams doubled their output in a year. Others plateaued. When leadership asked why, the answers were vague: culture, chemistry, maybe the product wasn’t strategic enough. Nobody had a model for what actually drove the difference — or how to change it.
Teams with high-frequency informal communication — quick exchanges during work, asynchronous channels, pairing — delivered significantly more than teams that relied on formal meetings as their primary coordination mechanism. Daily standups are necessary. They are not sufficient.
The approach
Over 18 months, researchers observed eight software teams across different product domains — attending formal meetings, watching informal interactions during actual work, and conducting in-depth interviews with team members, leads, product owners, and senior technical managers.
The patterns observed were then tested through a structured survey of 320 software engineers from organizations using iterative delivery worldwide. Statistical analysis confirmed the relationships held across different industries, organizational types, and team sizes.
What the research found
- Team composition matters more than team size. Small, stable teams with strong technical capability and good interpersonal dynamics consistently outperform larger, more volatile ones. The ability to bring in new members without losing momentum predicts success more reliably than the presence of senior technical leaders.
- Communication patterns predict velocity. Teams with frequent informal communication — quick questions during coding, async discussions, working side by side — delivered significantly more than ceremony-dependent teams. The informal interactions between and within delivery cycles are where shared understanding forms and problems surface early.
- Decisiveness in product ownership matters more than authority. Product owners who could make decisions quickly — or commit to finding answers by tomorrow — consistently enabled faster-moving teams. Those who controlled information, required sign-off chains, or were slow to engage created bottlenecks regardless of their organizational seniority.
- Team leads accelerate through enablement, not process enforcement. The most effective team leads removed obstacles before they became critical and created conditions for people to do their best work — the right tools, the right knowledge, the space to focus. Leads who focused primarily on process compliance had minimal impact on what teams actually delivered.
- Organizational permission structures determine team confidence. When senior leadership made clear that teams had authority to make technical decisions, challenge unrealistic commitments, and flag problems early, teams moved with confidence. When delivery commitments were treated as immutable, teams invested in protective buffering — padding estimates, avoiding ambitious work, slowing down over time.
If your teams are delivering but not accelerating, the problem is not the process. It is the conditions around the process.
Look at how your teams actually communicate between the formal touchpoints. Are informal channels active and trusted, or are all exchanges funneled through scheduled meetings? Assess your product owners for decisiveness and domain depth — not authority. Examine whether your team leads are enabling capability or enforcing format.
And ask honestly whether your organization treats delivery commitments as honest forecasts or as contracts that cannot be revised. The permission to say no, to push back on unrealistic scope, to surface problems early: this unlocks team velocity more reliably than almost any process improvement.
Are your teams delivering but not accelerating?
The blockers are almost always organizational — communication patterns, decision ownership, the implicit permission structure around commitments. These are diagnosable and addressable.