Specialization vs generalization on development teams

During the time since my last post about this topic my company has grown a lot. That growth has put the generalist idea to the test. A little while back Ralf Westphal posted about the topic too with his usual powerful voice. I have been meaning to follow up for some time because his arguments are so compelling. As a result of our growth, we have had to define more precisely what we mean by generalists because no matter what we do or say about being strong generalists, everybody is different. Everybody has different strengths and weaknesses. Does that mean everybody should specialize on their strengths?

I think the answer was and is no. Our own experience continues to point us away from specialization. I think that Ralf and others who feel as he does have left out some important assumptions. The most important is that specialization as Ralf describes it only works on large teams. The down side of both specialization and of large teams is the communication burden. Specialists often think only in their own domain. Project communication is always easier with smaller teams. Then there is the planning problem where you have to make sure you have enough of each type of specialist available so you don’t have bottlenecks in the schedule waiting on limited numbers of specialists. Parallelization issues aren’t just for concurrent programming!

Our approach has been to try and define more clearly the shared concepts, skills, experiences, and tools that make up a generalist in our unique style. We must embrace differences too and allow people to develop along paths that won’t be identical. We can accept that on any given day, one person will be more specialized in one topic or another shaped by recent experiences, interests and years on the job. No problem. Nobody should to work in a vacuum though, specializing in things that nobody else understands or cares to understand. Most of us have had the misfortune to work on teams that were structured in specialist silos. The dreaded DBA pops up in my mind right away. Having to deliver projects where you need to coordinate DBA, install team, web designer, systems analyst, security experts is painful and inefficient. We recognize that the skills of each of those people is important. We can recognize that not everyone would have the same level of expertise in all these areas. We do feel that everyone can have a solid background in all of them. They can ask somebody on the team who has more background in one area or another, it’s the real value of a diverse team after all. Managers can ensure that the team possesses those skills across a combination of people. In this way the team contains the specialized skills needed but is not dependent on individuals for the most part. Each developer knows that they can tackle any problem themselves with the nearby help of the rest of the team. Shared code ownership reinforces this point of view and remains a practice I think has solved many more problems than it has created.

So there it is. I still like smart programmers who can talk intelligently about things from soup to nuts and still think people like these make up the type of team I want to be around.


Comments are closed.