Specialization is for Insects

I have been talking about team work with my team lately. It seems that a image common issue that comes up, is specialization.
Everyone has a place, everyone is a piece of the machine, each piece should know what to do, and they should all work in perfect synchronization.

I know that this is the common belief, it just doesn’t feel right to me.
As I always give examples from sports teams, the team keeps on giving me the example of football (soccer) in which each player has his place.

Then I saw the amazing game between Barcelona and Real, and I noticed that what makes the former the best team in the world is that every player can do all the different jobs.
The defender Gerard Piqué run from his defense position to help the wingers then continue running to help the strikers and score a goal. Amazing.

This is what an exceptional team looks like, there is no specialization, to be the best team, everyone must know and be able to do all jobs. This will allow them to understand and learn a new point of view and be able to fill in. 

A developers must be able to do other jobs to become exceptional.

I had a casual talk with a developer. He said that he would never do a QA’s job, it boring, below his honor, he would do all he can not to do it. In his company they sometimes had to do a week in QA, but he would not do it, he would just sit around and not do it. No wonder developers are becoming sloppy and allowing bugs to flow to the QA team.

To become an exceptional, you have to understand the other parts of the system, and to do that you have to do it yourself.

  1. I think there’s sort of a balance that needs to be struck between specialization and generalization. It’s definitely a good goal to be able to work on any aspect of a given system. Too much specialization requires, as you mention, perfect synchronization.

    At the same time, no specialization at all is where the phrase “Jack of all trades, master of none” came from. I might be able to do a little of everything, but there’s not enough time in the world to be really good at all of them. There’s too much to know, particularly with technology moving at the rate it does.

    I blogged a bit about this a couple of years back when my company tried to reorganize things to “break down the knowledge silos.” Two years later, we continue to try to ensure people can understand and generally work on all parts of the system, but we still have subject matter experts and specialists in areas. On a sufficiently large system, I don’t think that’s escapable.


  2. I tend to disagree, I think that we as humans *can* excel and to be an expect *must* be able to learn and understand all parts of the system. A coder that understand SQL is by far better then a coder that don’t.

    I also believe that the silos and specific source/subject experts appear *mostly* because we are scared to leave our comfort zone. People like to do the things that they are good at. The experts comport zone is that he is known as the expert, it give a sense of job security. The person who need the expert, is scared to make a mistake and to take responsibility, so instead of trying, he asked the expert. It is a system that leads to mediocrity as both sides are comfortable.
    For a GREAT team, mediocrity is a killer!
    Everyone is comfortable in their specialized zone and no one grows. The thing about mediocrity is that you will wake up one day and not be needed. There will be many people who know what you know or it will be a silo that is no longer needed

    Don’t focus on breaking the silos, focus on being great, on learning and expanding and the silos will disappear.

  3. reality is that motivation is important. a Dev who doesn’t want to do QA is not a good Dev to have, but you have to ask why they don’t want to do QA and think if there are good lessons to learn and things to fix as a result.

    e.g.: don’t hire people who aren’t very passionate about the whole system you are creating.

Add Comment

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