Collective Speed Is Not the Summation of Individual Speed: Lessons from Relay Races for Software Teams

The Baton in Our Code

When Chris Coyier recently suggested that AI might be "10✕ing the speed with which we code, but it's not making our software 10✕ better," he touched on a fundamental truth about how teams work. Jim Nielsen expanded on this idea in his blog post, drawing an insightful parallel to the 4×100 relay race at the Olympics. The analogy reveals something crucial about team dynamics that we often overlook in software development: collective speed is not simply the summation of individual speed.

In a relay race, the fastest sprinters don't necessarily make the fastest team. The baton—the handoff between runners—is arguably more critical than raw speed. A dropped baton can cost a team several meters, or even disqualify them entirely, regardless of how fast each individual runner is. The same principle applies to software teams: no matter how talented individual developers are, if the handoffs between them are inefficient, the entire team's velocity suffers.

The Critical Importance of Handoffs

In software development, "handoffs" happen constantly. They occur when:

• A developer hands off code to a tester
• A designer hands off specifications to a developer
• One team hands off a feature to another team
• Operations takes over from development for deployment

Each of these handoffs represents a potential point of friction. If the baton drops—if information is incomplete, unclear, or delayed—the entire process slows down. A developer might wait days for clarification on requirements. A tester might spend extra time setting up environments that weren't properly documented. Operations might struggle to deploy code that wasn't built with production considerations in mind.

These handoffs are where the rubber meets the road in team performance. They're where individual velocity gets translated into team velocity—or where it gets lost.

Beyond Raw Talent

In the relay race analogy, there are other considerations beyond simply selecting the four fastest runners. Which leg each runner takes matters. The sequence of runners matters based on their individual strengths and how they pair with others. Sometimes, a slower but more experienced runner might perform better under pressure than a faster but less experienced one.

Similarly, in software teams, we need to consider:

• How individual skills complement each other
• Which team members work well together
• Who has the most experience with specific technologies or domains
• How team members communicate and collaborate

A team of all senior developers might not outperform a balanced team with a mix of experience levels if the senior developers struggle to communicate effectively or if they lack diversity in technical approaches.

The Flow of Information

What's really at stake in both relay races and software teams is the flow of information. In a relay race, information flows through the baton handoff and through non-verbal communication between runners. In software teams, information flows through code, documentation, conversations, and tools.

When information flows smoothly, teams can move quickly. When it gets stuck or distorted, teams slow down, regardless of individual talent. This is why:

• Code reviews are critical for maintaining code quality and knowledge sharing
• Documentation helps ensure continuity when team members change
• Regular stand-ups and meetings keep everyone aligned
• Good communication tools reduce friction between team members

Implications for Team Organization

The relay race analogy suggests several implications for how we organize software teams:

1. Handoff specialization: Just as relay teams have specialists for specific legs, software teams might benefit from defining clear roles for different types of work (e.g., frontend specialists, backend specialists, QA specialists).

2. Sequence matters: The order in which work passes through team members should be optimized based on dependencies and handoff efficiency.

3. Communication training: Teams should invest in training for effective communication and collaboration, not just technical skills.

4. Process optimization: Regularly review and refine team processes to minimize friction in handoffs.

5. Tooling for flow: Use tools that facilitate smooth information flow between team members.

The AI Paradox

Chris Coyier's observation about AI creating a paradox—making developers faster but not necessarily software better—fits perfectly with this discussion. If AI enables individual developers to produce code faster, but the handoffs between developers remain inefficient, the overall team velocity might not improve proportionally.

Similarly, if AI helps developers write code faster but doesn't improve how that code is tested, documented, or deployed, the end result might not be better software. The bottlenecks simply shift from coding to other parts of the process.

Creating Fast Teams

So how do we create fast software teams? Not by simply hiring the fastest individual developers. Instead, we need to:

1. Design processes that minimize friction in handoffs
2. Invest in communication and collaboration skills
3. Create clear interfaces between different roles and responsibilities
4. Regularly review and optimize how work flows through the team
5. Balance individual talent with team cohesion

In the end, a relay team wins not because it has the four fastest runners, but because it has the best baton handoffs and the most effective sequence of runners. Similarly, a software team succeeds not because it has the fastest individual developers, but because it has the most effective processes for collaboration and handoffs.

The next time you're tempted to measure team velocity by adding up individual velocities, remember the relay race. The baton—how information and work flow between team members—is what really determines collective speed.