Categorising development teams

Drawing by Nik SilverYou can describe developer cultures in myriad ways. Here’s a division I find useful as a quick orientation when looking at a development team.

In stereotypical MBA style it’s thinking about the world in two dimensions, with two categories in each dimension. The vertical asks: How often does the team deliver? Frequently or infrequently? The horizontal asks: How robust is the quality of their work? Are they rigorous or careless?

And then we get four categories of team culture:

  • Performant teams deliver frequently and are yet robust in their quality control.
  • Cowboy coders deliver frequently but are careless about their code.
  • Bureaucratic teams are very, very careful about the code they put out, but they deliver infrequently.
  • Money pits combine the worst of both worlds: they delivery rarely, and when they do the quality is awful.

Some notes on these:

  • Performant teams do not come about by accident. They require investment in various kinds of automation to ensure their high quality and frequent delivery happens by itself and reliably. Modern codebases are more likely to be maintained by performant teams, because it’s only recently the supporting technologies have become commonplace, but it’s very easy to start off on the wrong foot, or to slip back to one of the other categories.
  • Cowboy coders can be very successful individually, because they know their own code inside out, but they get dangerous when others start entering the picture: someone to be responsible for environments, other developers, and so on. Then the lack of robustness becomes more visible.
  • Bureaucratic teams usually miss the automation of performant teams, and use checklists and other manual processes which slow them down. I often find there is an underlying fear of delivery, because they don’t trust their code enough to let it out the door often.
  • Pure money pits are rare in my experience, and typically exist when the development team is a vanity function that the organisation can afford to keep without caring about its impact.

Most organisations find it difficult to move along one axis without also moving along the other. Specifically it’s hard to increase rigour with slowing down. The hidden variable is time or money: it requires organisational commitment to move purely rightwards or purely upwards.

Clearly all this is rough and ready, and the shortcomings of such a categorisation mechanism are numerous. But as rough and ready mechanisms go, I find it can be a useful shortcut, and then we can start a conversation to explore the details.

2 thoughts on “Categorising development teams

  1. I don’t like the use of Cowboy here, as I think it’s connotation are too negative. Sometimes instigators, as I’d probably call them can kickstart a situation that’s become ossified.

    I’m not sure it’s purely a you can have both situation either. Whilst I think it’s possible with tooling etc. to move both up and to the right, there’s always going to be a tension between pace and rigour and the balance is going to vary from product to product.

  2. Hi Phil. That’s a good positive view, thank you. A better word than “cowboy” would be welcome. I think “instigator” could apply an individual in any kind of team who’s trying to make some kind of change, and undoubtedly if you want to break out of (say) infrequent delivery then pushing for higher frequency while sacrificing some quality might be appropriate.

    This is also the general problem with this kind of categorisation—it really is rough and ready. When you get past the broad brushstrokes and down to specific situations and individuals then the issues become much more nuanced.

Comments are closed.