In the last few posts we covered data, applications, AI and the hardware that sits on players. Today we step away from the technology itself and look at something softer but just as important, culture.
Rugby has a strong, distinctive culture - one that values collective effort, respect, resilience and looking after your teammates. Many of the same principles that make a good rugby side also make a healthy engineering team or open-source community. This post explores those parallels and what developers can usefully borrow.
At its best, rugby culture rests on a few clear ideas:
These values show up in small rituals: the huddle before kick-off, the way players police their own standards, the post-match social even after a heavy defeat. They also show up in how clubs and unions think about development pathways and community clubs.
| Rugby Idea | Engineering Parallel | Practical Takeaway |
|---|---|---|
| The pack works as one | Shared ownership of systems and outcomes | Avoid “not my service” thinking |
| Look after your teammates | Psychological safety and mutual support | People raise problems early instead of hiding them |
| Play the whistle | Clear process and respect for agreed standards | Code review and CI rules are followed consistently |
| Bring younger players through | Mentorship and knowledge sharing | Juniors are actively included in design decisions |
| Leave it on the pitch | Hard focus during incidents, then clean handoff | Blameless post-mortems and recovery time |
| Respect the opposition | Healthy competition with other teams or vendors | Compete on merit, not politics |
These mappings are not perfect, but they give teams a shared language that feels more human than another set of abstract “culture values” on a slide.
Local rugby clubs often run on volunteer effort, shared equipment and a sense of belonging. Open-source projects can feel similar:
Healthy open-source projects, like healthy clubs, invest in documentation, welcoming contribution guides and recognizing different kinds of contribution (not just code).
A simple contribution mindset might look like this in practice:
Before opening a PR or issue:
1. Read the existing patterns (the “club playbook”)
2. Ask if the change helps the whole team / project
3. Leave the codebase or discussion in a better state than you found it
4. Assume good intent from reviewers and other contributors
This is basic, but it scales surprisingly well.
In both rugby and engineering we see the same failure modes:
Strong culture does not eliminate these risks, but it makes them visible earlier and gives the group tools to correct course.
Some of the best teams I have been part of felt a bit like a good rugby side. People trusted each other under pressure, newer members were coached rather than judged, and success was shared. The technology mattered, but the way we treated each other determined how long we could sustain high performance.
Rugby taught me that culture is not a poster on the wall. It is the sum of hundreds of small decisions about how we show up for the people next to us.