Collective capabilities over individual expertise

Again I’m continuing my scrappy, in-public drafting of the follow-up article to Create your own dysfunctional single-page app in five easy steps…

Mistake 3 in that article was Under-invest in front end capability.

The key word for me in this is capability. I deliberately didn’t use words associated with individuals like developers. Skills might have been appropriate too, but a skill still feels like something you ascribe to an individual rather than to a group.

My key point is this: as an industry we focus far too heavily on existing individual expertise, and far too little on the collective potential of a team working together.

Product development is a long game. If you want your product to be valuable and competitive over a long period, you need to play that game. Yes, you need pre-existing skills to quickly enter the game before running out of money, but in the long term your success is going to be largely determined by the ability of the team to continue delivering for months and years to come.

Development activities that are biased towards the individual encourage narrow ownership, silo’d knowledge and bottlenecks. A team like this has a fragile capability that could be affected very negatively by one person leaving. In order to lessen the impact of these things, we might encourage some patchy mentoring and collaboration. But ultimately, if you’re engineering culture still implicitly rewards individuals for heroic contribution efforts, those are going to have marginal impact.

Instead, pursue collective ownership, accountability and responsibility, safety in making mistakes, and transparency as a default. Getting there can be hard, especially when you have a strong existing culture in place, but the payoffs are huge in the minority of cases where I’ve seen this happen.

Here’s a great Twitter thread about healthy agile teams to inspire you.

What one thing can you do this week to help your team’s collective capability?

All the best,

– Jim