Specialisation and Generalising Specialists

Our current default model for organising teams seems to be to have programming generalists (mainly Java and JavaScript), team leads and full-time specialists (UX, Data Science, SRE). It’s a model that’s handled our needs to date very well, but this week I encountered something that made me think about a different model. I’d like to share what I ran across, and the slightly different model that came to mind.

You might have heard me, in passing, talk about root cause analysis and mention the Five Whys as one technique for digging deeper into causes (there are others, and historically I’ve said to use whatever works for you). I believe addressing underlying causes, rather than just symptoms, is really important, but this week I read a fairly detailed argument against the Five Whys, with suggestions of alternatives.

The alternatives come from a field of study called Human Error — there’s apparently a lot of theory in this field that I’m now aware of, in part because I am a generalist. While I’m interested in human error, there are many other things I’m interested in as well, and my knowledge of human error is, and will remain, shallow. Still, we would clearly benefit from having someone on our team who is really interested, or indeed an expert, in human error — someone we could call on when we needed to look at underlying causes and process improvement.

While it would be good to have an expert on human error, we probably couldn’t keep that person focussed on human error-related issues all the time (or at least I hope not!). We’d expect them to be able to contribute in other ways most of the time, so they need to have skills beyond their interest in human error, and they would need to be willing to work outside their speciality a lot of the time.

A person who fits this description is sometimes referred to as a “T-shaped person” — they have depth in some area (the vertical bar of the T) as well as breadth across several areas (the horizontal bar of the T). The horizontal skills need to include empathy and communication, so that they are able to work in a collaborative team. Kent Beck generalised this to Paint Drip People. They’re also called generalising specialists, or specialising generalists (take your pick).

In Unruly ProDev, a specialising generalist would be assigned to a team, just as any other generalist would be, and would default to working as a generalist most of the time. When there was a need for their specialist skill, in any team, they would go to the work. The length and terms of the engagement would need to be negotiated case-by-case, and would vary by speciality. Sometimes the speciality might be needed just for one meeting, sometimes it might be needed for a few months.

Notice that this is different to the cases where we can justify a speciality full-time and they never need to work as a generalist (though, of course, we’d still like them to have the empathy and communication skills we need for collaboration).

To be effective, the generalising specialist model also needs us to display some sensitivity around task allocation. Maintaining deep skills needs time, effort and the regular exercise of the skill, so we should use any generalising specialists within their domain as much as possible. This might run counter to the goals of widely sharing knowledge or growing other people, and the balance needs to be continually considered and revised. In return, we get the ability to implement some solutions that are outside the reach of generalists, and implement other solutions more effectively.

One thing we don’t have is a lack of things to specialise in — Java, Javascript, React, automated testing, distributed applications, monitoring, meeting facilitation, performance tuning, big data, internet security, and, of course, human error, all easily spring to mind.

Right now, we have a model that builds teams from generalists and specialists, but we have few generalising specialists. Consciously considering a generalising specialist model, encouraging people to specialise, and accommodating them in the way we organise the work, could offer new opportunities. Something to think about, not a mandate for wholesale change!

Like what you read? Give Steve_Hayes a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.