Team building

Posted: February 21, 2004 at 10:01 am in management

Several of the engineers based at our parent company in Toronto came down to our San Francisco site this week to sync up with us on the project that we are collaborating on. Our project manager thought this might be a good excuse for a team building exercise. Suggestions included going bowling or ice skating, or perhaps doing one of those participatory murder mystery type games. The whole discussion seemed so ridiculous to me that I started trying to pin down why I thought the concept of team building was ludicrous. I don’t really have any answers, but I figured it might be worth jotting down my thoughts.

Part of the problem is that I’ve been heavily influenced by Peopleware by Tom DeMarco and Timothy Lister, which has a whole chapter devoted to team building. Actually, it doesn’t. The authors tried to write a chapter on “making teams jell” and realized that they had no prescriptions: “What was wrong was the whole idea of making teams jell. You can’t make teams jell. You can hope they will jell; you can cross your fingers; you can act to improve the odds of jelling; but you can’t make it happen.” Instead they realized that what they _could_ do was figure out ways to ensure that teams _don’t_ jell. They called these techniques “teamicide” with examples including defensive management, bureaucracy, physical separation, fragmentation of people’s time, quality reduction of the product, and phony deadlines.

So DeMarco and Lister list what not to do. But that leaves the question of what does it take to build a team? So I started looking at our team of folks at the San Francisco site, because it’s the team I know best right now, and one that I feel works pretty well together. After thinking about it this week, I felt that the key ingredients to a team were respect and trust and roles. Each member of our team has a relatively well defined role. Everybody else defers to them when it comes to that specialty out of respect for their expertise. Moreover, we trust them to get their job done. This isn’t to say that there isn’t crossover among roles; but that crossover is built off of the mutual respect that has been developed over the past couple years. And for any given problem, there’s generally an obvious answer to the question of who’s responsible for dealing with it. Since I maintain the software, all software bugs are thrown to me. And my teammates trust me to deal with fixing the bugs; once it’s reported to me, they forget about it and move on. Nobody sticks around to nag me about the bugs or to micromanage how I fix them. It’s kind of scary; there’s nobody else to point to if things on my plate don’t get done. But it’s also an empowering feeling, because I’m in charge of my own destiny.

What makes a team a team? Generally, we think of a team as a unit where the whole is greater than the sum of its parts. For that to happen, it can’t all funnel through one person, because then the team is limited by that one person. Good teams are about letting go of control and trusting your teammates to get their job done, instead of skulking around after them checking up on them. I think that’s the part that managers have the toughest time with – they feel that because they have the responsibility, they need to have the control as well, so they start to micro-manage, disrupting any team vibe which may exist.

It’s interesting how these principles apply just as well in any collaborative environment, from the environs of a company to an athletic team to a chorus. Good sports teams are all about having well-defined roles and each person taking responsibility for their own role. Even Michael Jordan didn’t win his championships alone; he needed Scottie Pippen shutting down the opponent’s star on defense, Horace Grant and Dennis Rodman picking up the difficult rebounds, and John Paxson or Steve Kerr spotting up for the three. Two of the greatest moments in the Bulls run of NBA Championships were Jordan driving down the lane and dishing out to one of his teammates (Pax in 1993 and Kerr in 1998) for an open jumper. They knew their job was to bury open shots, Jordan gave up the control and trusted them to do their job, and they won the game. Heck, every May when they start running NBA finals ads on TV, I still get chills when they show the pass to Paxson and the announcer screams “Pax for three….GOOD!!” Anyway…

Respect and trust and well-defined roles. In light of those requirements, the superficial nature of typical team-building exercises becomes apparent. Respect is not something you get in an afternoon. It’s earned over a period of time, as you continue to execute your responsibilities at a high level. Trust is also earned over time; only after somebody has come through again and again will they earn trust. Such respect and trust can only be earned in the workplace performing your role, because it’s the trust in your ability to do your job that will get other members of your team to trust you. You may be a great guy outside of work, they may have great respect for your gardening or rock-climbing skills, but if you don’t consistently get your job done at work, your teammates will never feel comfortable depending on you. So all of the offsite team-building exercises are bunk. They may be fun, they may be a nice distraction and provide the opportunity to get to know co-workers in a non-work setting, but they do not contribute to better teamwork in the office.

Picking up the other aspect of team requirements I mentioned, well-defined roles can be assigned quickly, but it takes time for people to settle into those roles and figure out how the team fits together. This gets back to my belief that good management is putting people in a position where they can succeed; in this context, that means assigning them a role on the team where they can earn the respect and trust of their teammates. But even if roles have been assigned in an ideal fashion, it still takes time for a team dynamic to form, because the team members need to learn to trust each other in those roles. Like anything else in life, you only gain confidence when you’ve accomplished a task. All of the theoretical exercises in the world aren’t as effective as the actual experience. The same thing applies to a team. The best team-building exercise is accomplishing a task together. And I don’t mean some stupid artificial task like a scavenger hunt or a ropes course. I mean finishing a project at work together, where everybody did their job. Once you do that once, a team becomes much more powerful; they gain the confidence of knowing they’ve done it before and can do it again.

So that’s why I think those team building exercises are pointless. They’re a band-aid at best. They’re the sort of things that managers do so they can say they did something. To refer to DeMarco’s list of teamicide techniques, it’s defensive management – doing something solely to be able to cover one’s ass later.

What would I do differently? I’d treat a new team like I’d treat a new worker. When I was learning a new programming language at work, I started out by doing small toy programs. These programs would have minimal functionality, but getting them to work gave me the confidence to try harder and harder programs. If I were managing a team, I would start them out with small short-term projects, so they get a sense of how roles are distributed among people on the team. If a small project isn’t available, a big project can be segmented into smaller chunks to achieve the same effect. By succeeding at these projects, the team develops confidence, and the team members develop their respect and trust in each other. Move on to harder and harder projects. Each one reinforces the team members’ trust in each other and their confidence that they can accomplish things as a team. Pretty soon you have a really powerful weapon at your disposal.

The problem with throwing a new team, no matter how talented, at a very hard problem is that there is no sense of shared confidence to fall back on, so when things go wrong, people start to panic and try to take over each other’s roles and trust breaks down completely. Things start getting done multiple times because nobody trusts other people’s results. People start concentrating on their own narrow little responsibilities and lose sight of the big picture so that they can say “Well, I did my part” when everything goes down in flames. And, yes, I’ve seen it happen – it wasn’t pretty.

Anyway. I’ve babbled on long enough. Next time, we’ll talk about something completely different.

9 Responses to “Team building”

  1. The Rantings of Eric Nehrlich || Cognitive trust || March || 2005 Says:

    [...] It’s interesting to me because it provides an obvious extension of the cognitive subroutines theory to interpersonal interactions, at least in a team sense. I’ve talked about team building before (and actually say something very similar to Norman’s quote), and part of what I think makes a good team is that we can offload tasks onto other people; as I put it in that post, “my teammates trust me to deal with fixing the bugs; once it’s reported to me, they forget about it and move on.” A team can achieve more than the sum of its parts because each can farm out processing to others who are in a better position to handle a given situation. [...]

  2. Eric Nehrlich, Unrepentant Generalist || The Discordant Element || March || 2007 Says:

    [...] The take home lesson is contained in the post title. Notice the discordant elements in your company. If something doesn’t align with the company goals, remove it. It might seem minor, but it could be preventing synergistic organization overtones from forming. It’s like Peopleware’s description of how to build a team – first avoid all the ways in which you can prevent a team from forming, avoiding teamicide. It’s also similar to the Broken Windows theory, where fixing the little things makes it easier to fix the big things because all elements of the system are then in alignment. [...]

  3. Eric Nehrlich, Unrepentant Generalist || Iteration and feedback in management || June || 2007 Says:

    [...] in which iteration and feedback can be incorporated into a management setting, but they depend on a having already built a team. When there’s a problem with a project, the manager can’t unilaterally make a decision [...]

  4. Eric Nehrlich, Unrepentant Generalist || SBS Award for CellKey || October || 2007 Says:

    [...] Team building [...]

  5. Eric Nehrlich, Unrepentant Generalist || The Wisdom of Teams, by Jon Katzenbach and Douglas Smith || March || 2008 Says:

    [...] manufactured by applying the principles described in this book. As the Peopleware authors observe, team building is more about removing the obstacles to the team forming. I think that the observations of [...]

  6. Eric Nehrlich, Unrepentant Generalist || Management lessons from ultimate frisbee || May || 2008 Says:

    [...] takes time to learn how different team members think, how best to work with them and persuade them. Building a team is a long process, as each person needs to develop trust and respect for their teammates, and find [...]

  7. Eric Nehrlich, Unrepentant Generalist || Social capitalist || June || 2008 Says:

    [...] not in that world yet, but that seems to be where things are headed. People that learn to build those social bonds will have an advantage as that world takes [...]

  8. Eric Nehrlich, Unrepentant Generalist || Social technologies || June || 2008 Says:

    [...] Another challenge is that even if the communication is in place, the team can fall apart without trust. In a high-functioning team, the team members trust each other to give a heads up about relevant new information, so they spend their time working on their piece of the project otherwise. Without that trust, each team member spends time double checking information, gossiping at the water cooler to make sure they know what’s going on, concocting theories about ulterior motives in the information being transferred (e.g. is the due date artificially early to induce us to work longer hours?), etc. All that time is wasted productivity that could be gained back if a bond of trust is established within the team. [...]

  9. Eric Nehrlich, Unrepentant Generalist || The Future of Organizations || December || 2008 Says:

    [...] takes time and experience together to build the trust necessary for a team to function effectively and efficiently. Teams do not begin jelling as high performance units until each member of the team trusts the [...]

RSS feed

LinkedIn profile

Twitter

Speaking of biking, I just finished the San Juan huts mountain bike tour from Durango to Moab: plus.google.com/u/1/+EricNehrl…

Recent Posts

  • Thinking Fast and Slow, by Daniel Kahneman
  • How is your memory indexed?
  • Expertise as exception handling
  • Maximizing collisionability
  • Hosting update
  • Random Posts

  • Paul Graham
  • Virgin America
  • Quick hits of February
  • Management lessons from ultimate frisbee
  • Rules as thinking substitutes


  • Archives

  • Categories