Developing Like a (Sports) Team

Cricket, basketball, squash. What do these have in common? They are all team sports that I have played quite a bit competitively.

Squash is a bit different to the other 2 because while you play in a team of 4, it is only you and your opponent on the court at the same time. You’re not on court with a bunch of teammates.

I wrote an article on cricket umpiring and testing a few years ago so I’m going to leave that line of exploration untouched in this writing.

Team sports involve teamwork. Software development involves teamwork. Team sport is about fun, participation, working together to achieve victory at the end of the game. Outplay, outwit, outlast and at the end of the day, shake hands and have a chat over a cold drink. A post-match cold beer and chat might have been my favourite part of cricket. Software development teams aim to solve customers problems. To create an elegant solution that is loved by clients, is robust and dependable. I could drill more deeply into this, but that’s enough for current purposes.

The reason I love team sport is because you can help people, you can lend ideas, thoughts and motivation. You can coach and mentor based on the current game context, but you can’t force those things into somebody else’s actions. You can suggest to the bowler to pitch the ball up on a good length and at off stump as it will trouble the batsman. It doesn’t mean that the next couple of deliveries won’t be right in the batsman’s preferred hitting zone and sailing over the boundary. I once played in a basketball team with a mate who was terrible at taking 3-point shots. Despite the number of times, we discussed him passing the ball off, he’d take the shot (and miss) and we’d be back to defending. In both instances, you support your teammate and continue to make suggestions.

I mention the above because I honestly believe that playing team sport has been a fundamental input into the way I work with people. A position that is founded on “I’m working with professionals that are doing their best”. I think it has also taught me to think about “the big picture”. Circumstances can change rapidly in sport, and you need to be thinking about the now, the next and what is after that, slightly later in the game. Where do we want to be at…? “What if” thinking is a mandatory skill. Sport is agility in action and to be “in the game” means you need to be awake, thinking and ready to pivot – or sometimes just hang tight for a little bit longer and then assess.

Companies want to “win”. They want high quality releases but I’m not sure the right type of thinking is called upon. I see countless “blame game” accounts in LinkedIn, and personally, I’ve been at a company that revelled in blaming. Yes, I’ve had the “cross hairs” on me. It’s not nice, it’s not productive. It’s fundamentally destructive.

It makes me wonder if software development modelled itself on sports team behaviours, would we be better off? I think the answer is “most likely”. Perhaps next time the game seems to be getting away from the team, seek feedback. Invite it, make it a team habit to actively contribute to the game plan now and in the future. This is how great sports teams, regardless of the competition level, grow and thrive while having fun.