Breaking Up The Team

What would happen if midway through the the NFL season last year, the Pittsburgh Steelers, standing at 6 and 2 and leading the AFC North, had decided that their football season was over and disbanded the team? Or what if they decided to move Big Ben to the training squad because he was a prime performer and the training squad wasn’t really performing very well? What, you say? This would never happen?

No of course this would never happen for a variety of reasons not the least of which is that a team doesn’t just disband. A team doesn’t take their best performers and move them onto another project because that project is sucking wind. A team may lose a player here and there due to injury or trade or retirement but there is a sense of continuity to a team that exists above and beyond the sum of the team’s parts. A team has common, long-term goals like “winning tonight’s game”, “winning the division” and “keeping our superstars with the team”. Successful teams of all types typically have a common culture and no divas. Or at least the divas are under something resembling control. Even on NBA teams, where there are often divas of extraordinary divahood, winning rarely comes consistently unless the rest of the team buys into both the system and the superstar. Conversely, on bad teams, you may have one of the greatest players ever (see: Kevin Garnett pre-Boston Celtics) and still lose all the time.

This is true of all kinds of teams. Without some semblance of stability, culture, direction and goal, teams fail. In fact, they often implode. And yet, we in the software industry continue to call groups of people “teams” when they are at best, loosely grouped collections of individuals with similar skillsets working temporarily on a common project and at worst, highly dysfunctional trapeze artists who would like nothing better than to cut down the safety net and install 2 ounces of extra weight in the left side of their fellow coders balance bar. Project teams are not teams.

This is one of the gorillas in the room of current software methodology. We talk about software teams as if they want nothing more than to succeed when in fact, oftentimes, they could care less and may even have motives to foster failure. Of course, you could argue that we come up with methodologies to standardize these poor teams. But then someone might call you a cynic.

Granted, there are teams like this in the sports world but they don’t typically stay teams very long. They are broken up, sent away and rebuilt with the goal of having a real team. But in software, dysfunctional teams may stay together for office political reasons and completely successful teams may be disbanded in an effort to spread the success around, ignoring the fact that the team may have been successful because they were a team. We continue to treat software teams as if they are completely different from any other type of team we have ever encountered in reality.

As long as we keep trying to treat the symptoms of the disease instead of the actual disease, we’ll continue to have an industry that languishes. Stability is the critical component of the long term success of a software development team. Doing anything that undermines that stability contributes to the continued failures in software development that we keep trying to cure with a new methodology. A solid, stable, professional team can write software using any methodology. It’s only because we refuse that stability that we have to have silver bullet methodologies to try to cure so many of the symptoms of the disease.

6 comments on “Breaking Up The Team

  1. Excellent read Brett! Great stuff indeed!

  2. Excellent read Brett! Great stuff indeed!

  3. I do not think teams or groups of people consciously want to fail. I mean who wants to be a loser. They may not have the skills, cohesion, or social abilities to succeed but most people want to have success. Perhaps I am just putting my moral standards on other people in assuming people would want to succeed but that is how I feel.

    I also think in some ways Software Technology is a tough field to build long term teams in. Not all of it can be blamed on offices breaking up teams, and things like that. We work in a fast paced field and people tend to stay in jobs far shorter periods of time than they used to. In some ways this contributes to the difficulty of keeping good people together. The days of huge incentives for people to stay are long gone.

    Nice article. I agree with the concept even if I do not totally agree with all the points.

  4. I do not think teams or groups of people consciously want to fail. I mean who wants to be a loser. They may not have the skills, cohesion, or social abilities to succeed but most people want to have success. Perhaps I am just putting my moral standards on other people in assuming people would want to succeed but that is how I feel.

    I also think in some ways Software Technology is a tough field to build long term teams in. Not all of it can be blamed on offices breaking up teams, and things like that. We work in a fast paced field and people tend to stay in jobs far shorter periods of time than they used to. In some ways this contributes to the difficulty of keeping good people together. The days of huge incentives for people to stay are long gone.

    Nice article. I agree with the concept even if I do not totally agree with all the points.

  5. Scotch Drinker

    May 15, 2009 at 2:11 pm

    I agree that people don’t typically WANT to fail. However, I have worked with people who seriously wanted other people to fail, even people that were on their supposed team. Also, for a variety of reasons, I’ve been around people who do want the project to fail and will do small things to foster that failure. Luckily I don’t have to deal with that anymore but it’s certainly out there.

    I don’t think the overall structure of software development could ever be geared towards long term teams. There are too many Pointy Haired Bosses for that to happen. But even at enlightened shops, it almost always seems like teams are put together for projects versus given projects to existing teams. I think that’s a mistake for the reasons outlined in my post.

    If we look at the NBA as an extreme example, I can’t imagine there are many teams that don’t lose a player or two over the course of the year to a trade, injury or retirement. Yet, they are successful as teams (not including the Clippers or the Kings, they are awful). I think if you have the structure in place to foster teams, teams can succeed even when team members are disappearing on you.

  6. Scotch Drinker

    May 15, 2009 at 2:11 pm

    I agree that people don’t typically WANT to fail. However, I have worked with people who seriously wanted other people to fail, even people that were on their supposed team. Also, for a variety of reasons, I’ve been around people who do want the project to fail and will do small things to foster that failure. Luckily I don’t have to deal with that anymore but it’s certainly out there.

    I don’t think the overall structure of software development could ever be geared towards long term teams. There are too many Pointy Haired Bosses for that to happen. But even at enlightened shops, it almost always seems like teams are put together for projects versus given projects to existing teams. I think that’s a mistake for the reasons outlined in my post.

    If we look at the NBA as an extreme example, I can’t imagine there are many teams that don’t lose a player or two over the course of the year to a trade, injury or retirement. Yet, they are successful as teams (not including the Clippers or the Kings, they are awful). I think if you have the structure in place to foster teams, teams can succeed even when team members are disappearing on you.

Comments are closed.