On Specialization

Over the past few months I have become more and more convinced about the fact that specialization in software development – which includes programming, design, architecture, and testing to me – is a terrible idea. I don’t know when this came up in the history of our craft, and I think we need to stop it – now. I also know that I am probably upsetting some folks with these statements, still I think you should critically read this blog entry, and make up your own mind about the matter.

Relays vs. self-organization

The agile community uses an analogy when comparing specialization and cross-functional teams. A cross-functional team consists of everyone that you need to get a particular job done. For software development that includes skills in business analysis, programming, software architecture, and design as well as software testing. For football (in the European sense of the game) this includes defenders, strikers, and probably a goal keeper. Even though a defender’s main job is to get the ball from the goal zone in a game, he is also able to score a goal. The same holds true for other team-based sports.

Compare this to sequential activities. (Hope I am not drawing a false dichotomy here.) In sports, when running a relay, you have a more sequential activity. One runner starts, passes on the baton to the next one, until all four runners have finished their job. Most of the same points hold true for sequential software development.

As you may know, I have been involved in swimming a bunch of years. We also had relay competitions back then. In comparison to running, in the swimming world there are a couple of reasons a swimmer might be disqualified. For example, if he’s swimming breast-stroke, and ends the lane by putting just one hand on the wall, the swimmer is disqualified. In relays, if a swimmer starts before the swimmer before him has finished, and put the hand on the wall, the whole team will be disqualified. There are about 100 rules why a swimmer or team might be disqualified.

Now, the thought that occurred to me just last week was, that in relay swimming a single point of failure exists. If you have a bad swimmer who’s making a mistake, he can disqualify the whole team. The same is true for other relay sports – even for other sequential activities. The specialist becomes the single point of failure. One guy screws up, bang, the whole team will be cursed. (Maybe that is why there is so much focus put on blaming each other in these cultures.)

Now, compare this team sports like football, rugby, or the cooperative game of software development. There are occasions where the whole team might get disqualified – but these are rare cases like someone from your team taking steroids. Yeah, I know these happen, too, and they are heavily discussed by the larger public. (Maybe that’s good.)

But if an ice hockey player is thrown out of the game for a penalty, then the team needs to find ways to adapt, and still either score another goal, or avoid getting goals scored against them. They need to collaborate to compensate for the situation. That’s probably when you need some specialist skill, but you will need more generalists – people that can score a goal, and defend the own goal.

You need to shift your thinking from blaming each other (which would paralyze you from doing anything good) towards constructively finding ways to win the game, still. You need to work together with your teammates in order to win as a team.

Also notice that a team in sports has more degrees of freedom – within the constraints set by the coach, and the referee (and the underlying rule system). Within these constraints the teams need to navigate through the complex problem of getting the ball to score a goal, and defending against players of the other team.

Also notice that it does not make sense to ask every player in a team sport to run as fast as they can all the time. For football, you would end up with a team that is tired out after 30 minutes, probably. Of course, they need to run fast, but they also need to take their time for tactics. In relay sports it makes more sense to ask everyone to run as fast (and as efficient) as possible. In a team sport more efficient on the individual level means being less effective on the whole team level.

The same holds true in software development. With team-based software development you have more degrees of freedom to navigate through the complex field of the cooperative game of software development. You also increase your flexibility with a more cross-skilled team that has fewer specialists on board. More and more this factor becomes crucial in order to have a competitive advantage in the modern world.

Not that I am not saying that you should have a team consisting of generalists alone. That would be a false dichotomy. Instead, you should have “just enough” specialization, and diverse skills on the team. The problem, though, is an over-reliance we currently face in most companies I have seen with specialists that are no longer able to work as part of a cross-functional team. I think we need to move away from that deep-specialization-thinking in our craft.

Specialization and ego

There is one problem with the transition from specialized experts to cross-functional teams. Most of these specialists have followed a career-path towards this specialization. For example, a tester started as tester, and became a test manager over time because that was the way to move forward in her career.

Now, if you confront these folks with the idea of generalization, and cross-functional teams, you might be telling these folks that the path they followed for the past ten years was pretty much worthless to get the job done. Ouch. I would hate that, too.

The problem is that the ego kicks in for these folks. People want to feel recognized, people want to know a clear path to their advancing in their career. I certainly can understand that. What I learned from egoless programming is that we shouldn’t adhere to our past career path too much. Just as we should detach from the code that we once wrote in order to constructively work with the feedback from reviewers, we should also be open to overthink our current career direction, and try to take a different perspective on how to actually build software that solves a problem for someone that matters again.

I know this is hard. I know this will be a long journey for all of us. I know this will also mean to re-think some of our underlying assumptions about software development, management, and whatever specialization we followed (thus far). I truly believe the re-evaluation of some of our assumption will lead to some serious innovations in our field – and eventually we might find out how to constructively work together with our customers again. I think this goal is worth giving up some of my ego. How about you?

  • Print
  • Twitter
  • LinkedIn
  • Google Bookmarks

4 thoughts on “On Specialization”

  1. This attitude is not just wrong, but bizarre. Look around at our civilization. It is full of specialists. Our civilization cannot exist without them.

    I am a specialist in testing. If I weren’t a specialist, my work would be shallow. Specialism makes depth possible. It’s okay with me that many people are satisfied with shallow achievements, but deep work is what leads to new mathematics, new forms of art, almost any long non-fiction book, great scientific breakthroughs, and wonderful software. I want to get to the bottom of testing. I want to understand it as no one has before me. Are you telling me that is wrong? No one should learn that much about one thing?

    You think it is about ego? Well sure it is. I want to respect myself. I want to be very good at what I do. For that I focus my efforts. You say we need just enough specialization… Well, just enough to me means a lot.

    Instead of attacking specialism, I would prefer that you attacked bad work.

    1. What if you found out, that your speciality shouldn’t exist in first place? How likely would you be able to digest that message on the context ear, rather than the ego ear? Just think about it.

  2. I have to agree with James that specialization is important and often necessary. You used Hockey as an example but were referring to the players, you need to consider the goalie. Goalie has an important specialty and is a necessary part of the team. It is possible to play without a goalie but most teams realize that this isn’t sustainable. I’m not against overlapping skills or increasing breadth of skills, but I feel that depth of knowledge is important to great development and testing.

    1. Well, think about the consequences of a goal keeper receiving a penalty or red card in soccer. The attached risk to that specialization is a dramatic one.

      Thus far we – as an industry of software development – habe dealt terribly with the attached risks. I think we need to go back ans define the skills a reasonable developer needs, and also work on the attached depth to that.

Leave a Reply

Your email address will not be published. Required fields are marked *