Software is a Team Sport

Most software is built by teams, and not by individuals, not lone wolves with “their” code, but by teams. Any enterprise grade software necessarily represents more essential complexity than can be loaded into a single brain.

Every run-of the-mill company says they believe in teamwork, then turn around and measure, plan, and staff as if individual output is all that matters. The result is fragile delivery, pointless heroics, and a constant, low-grade chaos that everyone has quietly accepted as “just how things are.”

So, it just makes sense that the team is the most granular unit of delivery for most practical purposes. If you’re not optimising for the team’s output, you’re optimising for nothing. The team is the least count. Individual performance is important for delivery of course, but in an indirect way.

This is football and not tennis. You win together, or you don’t win at all. The scoreboard is for the team, not for the individual with the flashiest footwork or most points in isolation.

I'll fight you on this, this is a hill I will die on.

The Curse of the "Finished" Engineer

One common anti-pattern looks like this: “Oh, John’s finished his tasks, so he can help out on that other project.”

No. Just… no.

Work doesn’t get magically faster because you dropped in someone who doesn’t know the domain, hasn’t been part of the design conversations, and isn’t aligned to the shared goal. It actually gets much, much slower and much, much shabbier. Context-switching is expensive, onboarding mid-stream is expensive, and you’ve just fractured the focus of your team.

If a project is behind, that’s a team problem. You swarm on it as a team. You adjust scope, priorities, or staffing as a team. You don’t pull individuals like interchangeable parts off an assembly line.

The Fantasy of Parallelism

Another flavour of the same sickness is this: a team of five people running five parallel projects. This looks efficient on a roadmap slide. In reality, you’ve created five under-resourced efforts, each moving too slowly to matter, and each doing things in suboptimal ways that will come back to bite you later. You're raising a pack of biting, rabid angry wolves that will follow your team forever.

Little’s Law and the Theory of Constraints tell us what every good coach knows: reduce work in progress, focus your capacity, and you deliver faster. Running at “full capacity” on paper is the enemy of throughput in reality.

Teams Learn Together

Peter Senge argues in The Fifth Discipline that the only sustainable competitive advantage is an organisation’s ability to learn faster than its competition. That applies to engineering teams tenfold.

When you optimise for team-level delivery, you create the space for shared learning. More here. One person’s breakthrough becomes everyone’s win.

Debugging a nasty production issue? You swarm it.

Building a new service? You pair up.

Refactoring a core module? You bring others in to understand why and how.

Compare that to the “every person for themselves” model, where knowledge sticks to individuals like lint. Those people become bottlenecks, they burn out, and when they leave(literally or even just mentally), they take their knowledge with them.

Don't Ignore the Data

The data is clear. The Accelerate research (Forsgren, Humble, Kim) and the DORA metrics are not ambiguous:

• Fewer handoffs

• Shorter cycle times

• Lower work in progress

• Higher deployment frequency

…all correlate with higher performance.

The Curse of the Gifted Programmer was an email written in 2000. The Mythical Man Month was first published in 1975. Don't fool yourself into thinking you can intuit your way through this. Read the damn textbooks.

A single “brilliant” developer is never enough. Teams with deep collaboration habits outperform teams that rely on gifted individuals who hoard complexity.

The Culture Shift

If you want to play at an enterprise level (ship consistently, reduce defects, and keep people around for the long haul), you have to shift culture from “me” to “we.”

That means:

• Stop assigning people to unrelated projects just because their individual backlog looks empty.

• Stop pretending a team can run as many parallel projects as it has members.

• Swarm on priorities. Finish things. Deliver together.

This is radical, but it isn't new. It’s how high performing teams in any discipline operate. No one sends a rugby winger to go play for another team mid-match just because they’ve had fewer touches of the ball. You keep your shape. You play your game. You win together.

If you lose, you learn together and come back stronger.

If you want to measure something, measure the team’s delivery as a whole. If you want to improve something, improve the team’s flow of work.

But if you want to keep pretending it’s all about individual performance, fine — just don’t be surprised when your “team” starts to look a lot like five strangers stuck in the same room.