Developers aren’t rockstars; they’re footballers (and that’s a good thing).

Why software should be seen as a team sport, with the fitness of each ‘player’ contributing to the win.

When a player joins a football team, they’re subjected to whatever fitness and nutrition programme the team’s coaches and doctors have designed. This is because each individual’s fitness is critical to the success of the team, and therefore not something the team’s management can leave to chance.

Similarly, in software development teams, each person’s ‘fitness’ (AKA their capabilities) contributes to — or risks — the overall success of the team, and therefore the company. But far from being strategically central, in most dev teams, developers are broadly left to their own devices when it comes to skilling up. Learning and growth is then driven by their passions and interests, rather than what the team needs. If this was allowed to happen in football, you might find yourself with 11 centre forwards, which would be an unqualified disaster (but perhaps not as disastrous as 11 goalkeepers…).

Leaving your dev team to skill up on their own is analogous to giving footballers a gym membership and expecting them to figure out their own physical fitness. If that happened, the team management would have to be convinced that:

1. Each player would know exactly what they needed to do, which equipment to use, and how often, to change their capabilities.
2. Each player would always self-motivate to push themselves, in the right way, to the limit.

I think we can all agree that no respectable coach would make either assumption.

It struck me recently that the concept of a ‘rockstar’ developer is actually a more appropriate moniker than we might realise - so often we treat their skills as their own individual domain, and try to pull a band together based on who they are right now.

I’ve laid out the football vs. rockstar dev in a handy comparison chart below:

People aren’t static, people!

CTOs need to keep up with a high pace of change, which often means new skill gaps emerge in the team on a regular basis. We pour our energy into hiring to cover those deficiencies. At the same time, most of us happily espouse the idea that people learn, grow, adapt and evolve, but the instinct to hire our way out of a skill gap shows little faith in that process.

And that growth potential applies at every level. Even top sportspeople have a coach (I doubt Federer’s coach is a better tennis player than him, but he’s probably a much better teacher), so why don’t we apply the same thinking to our teams? I think there’s a lot to be learned from the personal trainer model when it comes to running a dev team.

The analysis of strengths and weaknesses, contextualised by the needs and goals of the team, fixed by focused coaching feels like the silver bullet I’ve been looking for throughout my career as a CTO.

No one is ‘done’ with learning; every developer has unknown unknowns — skills they don’t have that they aren’t even aware they’re lacking. Look back at code you wrote a year ago, and I bet you’ll see all the ways you would do things differently, knowing what you do now. Let me swallow my pride for a second and demonstrate. Here’s a version of Pong I wrote when I was 15. I can’t look at this without thinking:

Arg! It’s written as a form! In Visual Basic! I referred to myself as HywC! I checked the .exe file into the code repository! So many ridiculous things!

I’m convinced that when dev teams are mission critical for a company, you can’t leave their capabilities to chance. Sports teams don’t rely on gym memberships. My teams don’t rely on books or video lecture subscriptions.

Instead, we bring in the personal trainers because we’re serious about winning.