Specialization is Good

I think specialization is good, and cross-functional teams are not. Here’s why…

Suppose you are the publisher of a magazine about cooking. It’s a glossy magazine, with recipes, restaurant reviews, and lots of pictures of expensive cutlery and celebrities tasting trendy oysters. The magazine is released every month and you have a huge list of recipes, restaurants and celebrities waiting to make their appearance in one of the upcoming editions. Getting a new edition out the door is always a stressful experience. The celebrities never commit to any culinairy photo shoot. The chefs always complain about the way their food is described. And some of the recipes are so bad, you wouldn’t even want to cook them for your neighbor’s dog. But still, despite the bruised egos, and the meat clevers flying around your head, a new edition is published on the same day of each month.

Now the editor walks up to you and tells you he has the solution to all problems. It is called the cross-functional team. It’s really simple and very effective: The different roles of all people working on the magazine will be turned into one generic role called team member. There are no real specialists anymore, as everyone on the team is allowed to do any of the jobs needed to get a new edition of the magazine out of the door. The writers are allowed do the photo shoots, whenever they happen to be in the vicinity of a celebrity. Any chef, with at least one working finger left, is allowed to type restaurant reviews. And if the photographers are finished with their work, they can help out writing recipes that won’t kill any neighbors’ dog. With such a cross-functional team, explains the editor, making a new edition of the magazine will be much less stressful. So… what do you say?

This is what I would say:

Are you completely insane? If I’m on an operation table, having my eyelids corrected, would I want the nurse to take over when the surgeon is having trouble keeping up with his schedule? Would I say, "Yes, thank you nurse, and why don’t you have my tonsils removed, while you’re at it?"

Specialization is good.

Specialization is not the same as introducing a waterfall pipeline in your organization. Smart organizations can specialize without doing waterfalls. Avoiding waterfalls does not imply doing things cross-functional. Cross-functional teams (in the way they are promoted by some agilists) completely ignore everything society has learned since philosopher and economist Adam Smith pointed out in 1776 (in his landmark book The Wealth of Nations) that specialization leads to higher productivity and prosperity. Specialization is the reason why software developers do not bake their own bread, fix their own clothes or hunt for their own food, a few exceptions notwithstanding. The larger an economy or organization is, the more people will want to (and be able to) specialize in what they are good at. It is a mechanism that has proven to work well, not only for individuals but for the whole as well.

In our company I disapprove of people attempting to be cross-functional. When the design of a web site is being implemented by a developer, it can bring tears to my eyes. Some of them seem not to be able to see the difference between a pixel and a centimeter. I have seen functional designs for web sites, created by software engineers, that would probably have caused physical injuries among our web sites’ visitors, if we had followed the designs. That’s why we have software developers, content developers, business analysts, interaction designers and graphic designers.

I am all in favor of agile software development. We put people over processes, we favor face-to-face communication over written documents, we embrace change, and we welcome customers collaborating with us on their projects. And we demand that people stick to doing the work they’re good at (or want to become good at).

Are you happy doing what you’re good at? Or do you allow people to give you work you don’t even know how to do?

(This post has previously appeared on AgileSoftwareDevelopment.com)

  • Why Developers Are Never Really Happy
  • Project Success is NOT Stakeholder Satisfaction
Related Posts
free book
“How to Change the World”