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
GET MY FREE BOOK!
“How to Change the World”
  • http://blog.basgeertsema.net/ Bas Geertsema

    I believe it is not as clear-cut as you propose here. For instance, you compare the economics of a whole society to the economics of a relatively small development team. Clearly, there are huge differences in scale here and a straightforward comparison is not justified. The concept of division of labour has been widely discussed ever since the days of Plato, so we ought to know something about it by know. The outcome of a (non-)division of labour, results or revenue, depends on the context in which it is being used. For exmple, in a large economy it is beneficial to be very specialized, whereas for five drifters on a deserted island a more broad skillset can be better.
    The same holds true for the development of software. For a large software project specialization might be more beneficial compared to a small software project. Since agile development theories often assume small development teams it is not strange to see the agile people promoting flexible and cross-functional teams. The trade-off between both extremes is on one hand the higher coordination and transaction costs associated with specialization and on the other hand the benefits of higher individual productivity and quality. These costs and benefits are ofcourse very difficult to measure, but it is the fundamental question that every (software project) manager has to answer.
    btw. I enjoy reading your blog, keep it up!

  • http://www.leadingagile.com Mike Cottmeyer

    While some specialization is necessary, I do believe it introduces some problems. If you are only looking at one project at time, or you are in an environment where there is one team and one product, the impact of specialization is not as readily apparent. When you start building organizations around specialized skillsets and have a portfolio of 20-30 projects (or more), the complexity that comes from specialization is mind-numbing.
    I have been a part of several large IT shops organized around groups of specialists matrixed into project teams. The amount of effort required to manage who is supposed to be on what project, when they are supposed to be on, and at what level of effort, is well… again… mind-numbing. I don’t believe anything that leads to that kind of complexity is sustainable in the long run.
    So… at the end of the day, it is not really one or the other.
    In general, I would rather optimize for team rather than specialization. That means that the team must have all the skills required to deliver the project. Within the team I would expect some specialization. I would also expect the team members to diversify their skills so that they can contribute continuously as the project’s skill requirements evolve.
    The term ‘specializing generalist’ comes to mind.
    I would also allow that there are some skills might be better optimized for specialization. Simon Baker posted a blog this weekend talking a bit about ‘generising specialists’. Apparently there are a few of us contemplating these issues this weekend:
    http://www.think-box.co.uk/blog/2008/04/challenges-for-product-stream-concept.html
    I would want the teams of specialists to be the exception rather than the rule. Optimize for team first and then handle the exceptions as necessary.
    Here is a link to a post I wrote this weekend on the subject:
    http://www.leadingagile.com/2008/04/what-about-me.html
    Thanks for your post!

  • http://noop.nl Jurgen Appelo

    “you compare the economics of a whole society to the economics of a relatively small development team.”
    @Bas: Actually, I’m comparing an organization creating a magazine with an organization creating software. There’s no difference in scale here. And I think you’re wrong regarding drifters on a deserted island. Why should all of them learn how to fish, how to make fire and how to make a roof? Why not co-operate and specialize?
    “The complexity that comes from specialization is mind-numbing”
    @Mike: If you don’t believe how such complexity (of specialization) can be sustainable in the long run, then what do you think of organizations that create magazines? or newspapers? or musicals? or conferences? They are all complex organizations with highly specialized workers. If they can do it, why can’t we?
    But whatever my disagreements, thanks for your comments! It’s quite interesting stuff…

  • http://blog.perfectapi.com Steve Campbell

    The generalization that Agile encourages is less about technical skills (dba, interaction designer, etc) than it is about business domain knowledge. It is intended to counter the often-seen phenomenon of “silos”, wherein one person has all the domain knowledge for a single part of a system.
    Silos are always risky (http://en.wikipedia.org/wiki/Bus_factor). Paradoxically, they can also be unproductive (due to boredom of the developer, no monitoring of time spent). Hence the “team of generalists”, which takes a small productivity hit in bringing multiple people up to speed in a particular area, but increases the future flexibility of the team and raises the bus-factor.

  • http://www.davenicolette.net/agile Dave Nicolette

    Jurgen,
    A clever post, but I think it is based on a weak analogy and also mixes terms.
    When we talk about cross-functional teams in the agile community, the context is software development, not magazine publishing. We need not arrange for celebrity visits and so forth. Agile methods are most usually applied to business application software development. That sort of work doesn’t usually require narrow-and-deep specialists – at least, not for the entire project.
    It seems as if you’re mixing the terms “cross-functional team” and “generalizing specialist.” A cross-functional team may well comprise individuals with different specialties. For business application development, a team of generalizing specialists usually works well and provides the cross-functional skills needed to get the job done. In other domains, this may not be feasible, but that doesn’t mean it’s impossible to have a cross-functional team.
    A software-related example of a cross-functional team with definite specialties might be game development. Consider a company such as High Moon Studios, for example. A new or improved game requires very disparate skill sets – character development, story line development, art, animation, and software development to support two distinct specialized areas: physics and rendering. For the portions of the work that involve software development, High Moon uses very rigorous and disciplined agile methods and all the programmers are generalizing specialists within the scope of the software development work. Obviously, they are not also expert artists or story writers. Yet, the total team is a cross-functional team that covers all facets of the work.
    I appreciate the fact you are thinking independently about these issues, but I think you missed the mark this time.

  • http://noop.nl Jurgen Appelo

    “It seems as if you’re mixing the terms “cross-functional team” and “generalizing specialist.””
    @Dave Nicolette: actually, I was responding to the use of the term “cross-functional team” by the Scrum people. I know what the *original* meaning of the word is, and I have no problem with that. I just disagree with the interpretation given to it by Scrum. Just google on “Scrum cross-functional” and you can see that *they* are the ones mixing up the terms.

How to Change the World - free Workout - free
CLOSE