Team Cohesion: What Rugby Data Tells CTOs About Building Engineering Teams That Win

This article was inspired by a podcast. Ben Darwin: The Science of Team Cohesion, from Ben Herring's Coaching Culture show, is mainly about rugby. Darwin is a former Wallabies prop who founded GAIN LINE Analytics to measure how well teams work together. But the more we listened, the more it sounded like a conversation about engineering teams.

His main argument is that teams whose members have worked together for a longer period usually outperform those possessing greater raw talent. He also draws a useful distinction between culture - the behavioural patterns established within a group - and cohesion, that is, the practical understanding that enables people to work together without the need to explain every action.

It is precisely this second concept that forms the focus of this article. It is a topic we think about daily, as it lies at the heart of how we build engineering teams.

What is team cohesion in an engineering team?

Team cohesion is the degree to which the group functions as a unified whole rather than merely as a collection of individuals. In an engineering team, it is built upon two elements:

• Shared experience: how much time people have spent working together on the same systems, problems and incidents.
• Continuity: how much of the team stays the same from one quarter to the next.

Cohesion shows in the little moments. In our context, it is seen in the backend Engineer who knows how the lead frontend developer will react before the conversation even begins. In the team that reviews each other’s pull requests in a matter of minutes, having already gone through hundreds of them together. In the calm handling of an incident, because everyone already knows their role.

None of that shows up on a CV. And none of it transfers when someone leaves.

Culture vs cohesion: what's the difference?

Culture is the way a team conducts itself - its standards, habits, and attitude toward people. Cohesion reflects how effectively the team actually works together. A team might have an excellent culture yet a low level of cohesion if half its members joined only last month.

Nevertheless, the two reinforce each other. A clear culture enables new members to fit in quickly, thereby safeguarding team cohesion amidst changes in personnel.

Is team cohesion linked to performance?

The best evidence comes from sports, where results are public, and lineups are documented for every single match. Researchers in the field of rugby, in particular, have been measuring this for years, and the results are consistent:

• A 2019 study of ten international rugby nations found a significant link between growing shared experience among players and win percentage.
• A 2017 study of France's national team found that between 1987 and 2014, winning sides had changed around 30% of their line-up from the previous match. Losing sides had changed around 41%.
• In a 2016 analysis, Darwin showed that the Premiership, Pro12 and Super Rugby champions that season all ranked first or second in their competitions for cohesion.

These studies indicate a link, not proof, that cohesion alone is sufficient to win matches. Furthermore, they do not examine software development teams. However, the mechanism is easily recognisable to anyone who has led such a team.

Why does team cohesion matter for engineering teams?

Engineering is a team sport in the most practical sense of the word. Few things of true value are created by a person working alone, and most difficult problems arise in the space between people, rather than in the mind of the individual.

A cohesive team has advantages that are hard to replicate quickly:

This is also why adding headcount rarely delivers the speed-up a plan expects. New people add capacity on paper. Cohesion takes longer to catch up.

What breaks cohesion in an engineering team?

Cohesion rarely collapses in one go. It leaks away through decisions that each look reasonable on their own.

1. High turnover

Every Engineer who leaves takes with them a body of context that has never been documented. Even if replaced by an equally qualified specialist, the team remains weaker for a time, as the new person has not yet worked with that specific team or those systems.

The cumulative effect of small changes in personnel takes its toll. In a study conducted in France, the difference between winning and losing teams amounted to just one or two additional changes per match. Engineering teams that lose one person per quarter experience a similar slowdown.

2. Rotating vendors and contractors

Traditional outsourcing is often designed in a way that hinders cohesion. Employees are rotated among different clients, replaced on short notice, or kept at a distance from the in-house team. On paper, staffing levels remain unchanged, yet cohesion is imperceptibly lost.

3. Building around individuals

Hiring an exceptional Engineer can benefit a team, but "stars" do not instantly gel into a cohesive unit. A 2016 analysis by Darwin offers a striking example of this: during the final five years of the McCaw and Carter era, the Crusaders, Super Rugby’s most dominant team, won only 35% of their first five matches of the season as their national-team players reintegrated into the squad. The talent was world-class, yet the team still needed time to find its rhythm.

4. Constant reorganisation

Team splits, staff mergers, and ownership changes reset the partnerships that make the execution process predictable every few months. Some changes are necessary, but change itself is costly.

How do you add new Engineers without breaking cohesion?

Teams need to evolve and change. The goal is not to avoid bringing in new people, but to integrate them without having to start everything from scratch.

Two examples from outside the software world illustrate how this works. In 2021, when COVID-19 restrictions caused 48 players and staff members from the Munster squad to miss a European tournament match, the club fielded 12 debutants and still won. A case study of that game credits the months the academy players had already spent training with the senior squad, using the same calls and game plan, plus a mentor for every newcomer. In the Clipper Round the World Race, some crew join for a single leg, stepping onto boats whose crews have already spent weeks at sea together. They manage to fit in because every crew member first undergoes the same training.

The lesson in both cases is the same: newcomers fit in quickly when the system they are joining is clear and shared.

In an engineering team, this looks like this:

1. Protect your core. Identify the partnerships your development relies on and keep them integrated wherever possible.
2. Make your way of working clear, covering coding standards, review norms, release processes, and decision-making. If this knowledge exists only in people's heads, newcomers cannot absorb it.
3. Bring people into the team, not just alongside it. New Engineers should be part of your stand-ups, Slack channels, and retrospectives from day one, rather than working from a separate backlog.
4. Pair every new member with someone who knows the system. Mentorship is the fastest way to transfer context that was never documented.
5. Hire for continuity. Choose people and partners who plan to stay. Every Engineer who leaves after six months takes a piece of the team's cohesion with them.

How do we build cohesion at TechPods?

Cohesion is built into how we work, from the way we hire to the way our Engineers join our partners' teams.

Our Engineers join your team, not ours

Through our co-sourcing model, our Engineers don't sit in a separate unit outside your business. They join daily stand-ups, use your tools and processes, and embrace your company culture. Your standards set the direction, and they align with them.

This is precisely what makes integration fast. When a new Engineer joins an existing team, they do not bring habits that conflict with yours. Instead, they adopt your methods by working side-by-side with the people who already put them into practice.

We build dedicated teams, not rotating benches

We do not rotate specialists between different clients. A partner working with us relies on the same Engineers for every sprint; this allows accumulated experience to build up over time rather than being lost through periodic rotations. There are no opaque management layers; you have full visibility into who is on your team and the tasks they are working on.

We keep our people

Our Engineers stay with us, and with the teams they join. For our partners, that means the Engineers who learn your systems this year are still there next year, carrying context forward instead of handing it over.

We focus on capability, not headcount

A smaller team that works well together will usually outdeliver a bigger one that doesn't. That's the thinking behind Elite Systems. Elite Teams. and our focus on smaller, highly capable teams over bigger headcounts.

How cohesive is your engineering team? 5 Questions to ask

If you are unsure about the state of your team, here are a few questions that serve as a good starting point:

1. How many of your Engineers have been working together for more than a year?
2. If your two most experienced employees were to leave tomorrow, how much accumulated experience and knowledge would leave with them?
3. Does it take weeks or months for new hires to reach full productivity?
4. Are external Engineers part of the team, or do they work alongside it?
5. How often has the team structure changed over the past 12 months?

If the answers make you uncomfortable, you are not alone. Most teams do not track cohesion levels, as this metric never appears in staffing plans. Its absence becomes apparent later, in the form of missed deadlines and the loss of knowledge that leaves the company along with departing employees.

The best teams aren't assembled in a quarter. They're built over time, by people who stay long enough to know each other's work. If you'd like to build an engineering team that works that way, let's talk.