Why product development is the beautiful game

Building Teams

Firstly, I need to apologise to any football fans out there. I’m the first to admit I don’t follow the “Beautiful Game” but I keep turning back to it as a useful example. I could use many other team sports as a comparison instead but football seems to be the most universal.

One of the greatest challenges and in all honesty, frustrations, I’ve experienced over the past years is the treatment of highly skilled, talented, creative people as “resources”. I can’t begin to count the number of times a financial director or project manager has asked, suggested or requested “resources to be re-assigned, so a project goes faster”.

So much of this thinking dates back to the emergence of heavy-duty industrial and civil engineering projects where dockworkers would line up for selection in the morning and the one’s who could set the most rivets would be chosen that day. There is an increasing body of evidence and library of resources that demonstrate that building software products, especially those delivered in through a SaaS model, needs to be planed and managed very differently - I won’t go into the details of that here, but if you’re interested I can’t recommend Sooner, Safer, Happier enough.

It was during one of these many discussion that I was searching for a way to describe what they were requesting and a football team came to mind.

You’ll have to bear with me, because as I said, I don’t follow football but I know for a fact there have been many examples of where “super teams” have failed. It doesn’t matter if you put the worlds 11 best players in the same team; you’re not guaranteed success. More likely you’ll get 11 individuals, all of whom want to prove they’re the best.

The role of the manager is well understood in football, as is that of coach and captain. In fact all these roles are recognised as being vital to the success of a team and yet in software development, (from the outside, at least) these roles are often absent or seriously undervalued.

It’s also true to say that you can’t simply move a player from another team and expect instant success. Teams are carefully selected from squads and each player within that team is selected for the role they need to play and hw their skills and talents benefit the team. Managers will also pay attention to how any player’s deficits might affects others - people always have both good and bad traits.

I should all emphasise the value of cross-functional teams over silos squads of developers. Teams need to have all the skills in them, in order to be successful and you’re unlikely to find all of those skills in one person. For a football team to be successful, you need strikers, midfield, defenders and goal keepers - not to mention the coach, captain and manager roles. Product development teams are the same. 11 software developers is not going to solve the problem. You need product managers, designers, and often other subject matter experts in there too. Yes, you can get them on loan in the same way you can bring a substitute on to the pitch, but they still need to be part of the squad and know the team inside out.

I’m pretty happy with this analogy so far but how much can I push it…!? The rules of football dictate 11 people on the pitch from one team. So you can’t just keep adding more people to win. Product development teams don’;t have the same rules applied - at least officially, but there is significant evidence (start with Dunbar’s number and go from there) that there is a practical upper limit to the size of a high performing team and adding more people doesn’t improve performance but often makes things worse. If you tried putting 100 players on the pitch everyone would trip over each other!

There’s also a lot to be said about how a team actually work together. It’s still common practice to attend a standup and hear from each individual what they were working on and their progress, their blockers. It’s routine to see a team have each developer working on a different problem and then request support from their peers, who are in a different context. Some might see this is giving a football team a ball each - more opportunity to score a goal! But that’s far from the actual outcome. It also increases the likelihood of an own goal and who are you going to pass to when you get tackled. In fact, it’s not even like that! It’s more akin to expecting each individual player to be on a different pitch, playing a different game and we all know how that’s going to work out.

I’m pleased to say there is a growing body of evidence to shift thinking but it’s high time that we and our peers stop thinking of software engineers as being heavy engineering. That we stop using methods and languages that describe what we produce as projects like railway lines, with the idea that it’s finished when it reaches it’s destination and we can leave it for the next 100 years and most importantly, that we stop treating people with thoughts, ideas and passion as faceless resources, to be dragged and dropped at will where ever there’s a problem of a task to be completed.

Instead we need to think of our products and services as more akin to the service that runs on the railways and or teams as complex, ever evolving people who need support, coaching and management to work most effectively.

Sure, you can keep moving players from one team to the next or put a midfielder in goal or even send every player to have a different game but you’re not going to win the cup or the league that way and you’re probably going to get relegated pretty quickly if you try it.

Header image courtesy Chris Leipelt