Software development teams consists of people with diverse skills and personalities. While non-developers might joke that everyone on your team is a shy introvert, you probably know better. Of course, even if your entire team is composed of shy introverts, each one will have their own areas of expertise and interest. As a software development manager, the better you, or the people you manage, understand what makes each developer unique, the more effective you can make your team.
There are two main schools of thought to consider here. The first, which I’ll call the “generalists”, suggests that it is a good strategy to make sure everyone on your team is cross-trained with all your technologies and products so that you have maximum flexibility in assigning resources to any new project. Those who ascribe to this approach also point out that it helps reduce business risk because you don’t end up with critical knowledge in the mind of a single person.
The second group, who I’ll term the “specialists”, argue that allowing individual developers to focus on particular technologies or products allows for more efficient use of developer time and talents. This group accepts the potential risks of specialization in exchange for increasing the skill and effectiveness of each member on the team.
Like a true diplomat, I think both approaches have merit. However, when asked to make a choice, I quickly side with the specialists.
The generalists make a good case that the loss of a highly specialized developer, perhaps the only person who truly understands your entire data-model, is a big risk to any project. They are right. And the ability to move generalist developers between projects without worrying about them coming up to speed, can simplify planning. But I think I can make a good case that this approach is not best for your team or your business.
When you adopt a specialist approach, you immediately gain significant efficiency from each developer. The ability to become an expert at a particular language, framework, technology or product, can create huge time-savings. First, an expert that has focused deeply in a particular area can rapidly solve problems that would take a generalist hours, or days, to solve. Second, everyone gets to know who the experts are for each area. In this situation, when any person encounters a problem they don’t understand, they can immediately call in the appropriate expert for help. This, in effect, means that every developer can work as if they were personally an expert in every area. Instead of a team of self-sufficient generalists, you have a network of cooperating experts. The difference in productivity between these two groups is staggering.
Think of a bee-hive or an ant-hill. In both cases, nature has shown that a cooperating group of specialists is far more effective than a collection of generalists.
Unlike an ant-hill, which often has hundreds or thousands of each specialist, most development teams will have only one or two specialists in each area. So how does a specialist team deal with the risks identified by the generalists?
This is where the Software Development Manager has some work to do. It is easy to let a team naturally find its own specialists, and simply follow the natural flow and resource assignment that results. While this might be easy, it’s not really management. Or at least, it’s not very responsible management.
You need to take conscious control of your team’s expertise. While you can, and should, allow situations where team experts develop organically, sometimes you need to take a more hands-on approach to the problem. Sometimes you need to explicitly build an expert.
That’s the subject for another post.
Leading Software 
The problem for a manager then is how to react when a specialist doesn’t want to specialize in that area any more.
I’ve worked for 2 companies where I was the specialist in parts of the code. I felt locked in. I got bored. At one company I requested a change and was only given lip service about making that change happen. Then I felt trapped. Ultimately I looked for work elsewhere.
Another job I worked at everyone was a generalist. I found it to be a much more congenial working environment. The system I worked on was huge, so over a three year period I was constantly learning new things. I much preferred the generalist approach and actively sought that out for my next job.
You make an excellent point Greg. Probably worth a chapter all on its own. For now, I’ll just say that I agree completely that a manager needs to make sure their specialists never become bored. A good manager should be always working to train “backup” specialists (for risk avoidance reasons). Once you’ve got a backup specialist or two, you are in a great position to let one of the existing specialists take on a new role.
Pingback: Presentation at the VIATeC Software Manager Roundtable « Leading Software