Design Team Dynamics

Sunday, February 26, 2006

Mel: Teams vs. Working Groups

Brought this up at our first meeting last night, but didn't do a good job of explaining it. The difference between teams and working groups is an important one that's difficult to articulate, especially since most people label working groups as "teams."

Working groups

A working group's performance is a function of what its members do as individuals. There is no sum > sigma(parts). You take the work, divide it into people-hours, and portion it off. The metric for how well a working group member performs is how well they complete the person-hours of work apportioned them. Incidentally, this sounds an awful lot like the capitalist labor society Marx criticizes in the Communist Manifesto; people are hot-swappable work-hour units with different skill sets.
Since individual accountability is a convenient thing to have, most organizations (especially large ones) use working groups, and they use them well. Most committees, councils, task forces, and "teams" are really working groups. Most Olin projects, since they're relatively short-term (0.5-1 semester), are really working groups, and I'd generalize this to most short-term technical project groups in general, though I can't back that up. These groups are usually called teams, since "team" sounds good, but saying something's a team doesn't automatically make it one.
Here's what the powerpoint presentation says about working groups:
  • They share information, perspectives, and insights.
  • They make decisions that help individuals do their jobs better.
  • They reinforce individual performance standards (the work-hour units metric I mentioned earlier).
  • They focus on individual goals and accountabilities; members do not take responsibility for results other than their own.
  • They do not develop incremental performance contributions requiring the combined work of two or more members (sum !> sigma(parts)).
Working groups are not inferior to teams! Sometimes they're the quickest, most effective way to get the job done; on small-scale, short-term projects, they almost definitely are. At Olin, we learn how to serve on working groups with extreme efficiency.

Teams

Let's begin with the powerpoint's bullet list again. Now, teams:
  • They require both individual and mutual accountability.
  • They rely on more than group discussion, debate, and decision.
  • They rely on sharing information and best-practice performance standards.
This begs the question of what they do rely on. Gimme a second here.
  • They produce work through the joint contributions of their members.
  • They make possible performance levels greater than the sum of the individual bests of team members.
  • Their performance includes both individual results and "collective work products" (what 2+ members must work on together - it reflects the real joint contributions of team members, not just sums of individual work-units).
Teams rely on interdependence and this sum >> sigma(parts) phenomena. My own theory is that teams are effective at getting their entire group into a collective flow state. Since the flow state is naturally the most productive mode of any individual person, having a way to keep all their individuals in flow state is to have a way of getting sum = sigma(parts) at minimum. But teams go further by enabling one individual's flow state to merge with another's - and this is where the sum-is-greater-than-the-parts phenomena comes in.
The team phenomena is most obvious in athletics and music. Good sports groups are teams; good orchestras, choirs, and drum troupes are teams. They can't afford to be otherwise.
Teams don't have to be working on the same project. Whereas working groups congregate around a job at hand and dissolve when the job is finished, teams endure past the completion of an assignment.
Teams have 10-year reunions. Working groups reconvene to complete another task.

A comparison

The powerpoint had a nice chart that showed some key differences succintly. I don't think it's complete, but it comes pretty close. (The formatting here may be wonky; sorry about that. It's standard html, but I can't get Blogger to like it.)


































Working group Team
Strong, clearly focused leader Shared leadership roles
Individual accountabilityIndividual and mutual accountability
Purpose is the same as the broader organizational missionPurpose that the team itself delivers
Individual work productsCollective work products
Runs efficient meetingsEncourages open-ended discussion and active problem-solving meetings
Measures its effectiveness indirectly by its influence on others (such as financial performance)Measures performance directly by assessing collective work products
Discusses, decides, and delegatesDiscusses, decides, and does real work together


Teams are illogical. They shouldn't work; they do things inefficiently on account of the overhead it takes to transform a working group (and they all start out as working groups) into a team, but once that point is passed, their performance rate skyrockets.

I'd also like to point out that Apollo Groups (groups made from the highest-performing individuals) are ineffective when you think they'd be completely great - this is a subtle corollary of the nature of team vs. working group dynamics and performances.

Sources

Powerpoint presentation on teams

I've had several discussions with different individuals on this topic, but I believe it was Mark Penner who first showed me the article (from his New Ventures class) that first got me thinking about it. I have no idea what article it was, where it was from, or where it went, though - if someone from the class knows what I'm talking about, I'd like to find that article again.

Saturday, February 25, 2006

Week 1: Reading

My experience with design teams is fairly limited. Before Olin, Odyssey of the Mind was my only real experience with integrated team activity; our designs were only fortuitously successful. Team activity was mentioned in high school but not given any real emphasis -- we quickly broke team problems into division-of-labor scenarios that we worked on independently because teamwork was perceived as difficult and of lower quality. Design Nature at Olin revolutionized the way I see design activity and design teams.

Snodgrass outlines two sets of design metaphors: the rationalist model of design and the romantic model of design.
The point that there's no one formal design process to supercede all others in all cases is an important point. I'm not sure how I feel about discounting intuition.
Snodgrass quotes Heath: "Heath believes successful designers have a method, 'but it is not yet an explicit method.'" Will it ever be quantified? Is it even possible to quantify? It sounds like Snodgrass is suggesting no; I feel like I have to agree to some degree. Is that why we started this IS? I don't think that's an answer we're likely to get.
What's the Olin curricular design model look like? Are we in the analysis-synthesis-evaluation mode? Design Nature definitely does, particularly for the instructor-directed hopper project. Elsewhere?
It would be interesting to see what the post-realistic world looks like.

Team of one: So are teams really useful? Is the wider perspective attained from using teams the best way to do things? / an efficient use of person-hours? Why does everyone use the team model if teams aren't really the best answer? Is it really just an effective model for peer review? I get the feeling that wider perspectives are useful, but it seems like these perspectives are just as likely to be wrong as right. What's the balance? I'd like to ask people in industry about this.

Belbin evaluation
I was interested to find that my Team-Worker score on the Belbin inventory was zero. That doesn't square with how I view myself operating within a team and I'm wondering why I interpreted my the statements in the inventory as outside my experience. Is my limited experience biasing my response away from my "real" orientation, am I not really acting in a manner consistent with how I vew myself? I'll have to think about this when my next team project swings around.

Mel: Background information

Thought it would be a good idea to start with an introduction, so you can get a sense of what kind of filters I'm running all my blog posts and conversations through.


Pre-Olin


Before Olin, I was peripherally within a social group and participated in several team-intensive activities, notably math team, drama club tech, math modeling, improv, and the newspaper. Most of my time was spent as an individual working while the rest of the group (social or working) puttered around me; I would poke my head in as often as I thought I needed to. I wasn't divorced from the group - often I'd fill the role of teacher and translator - but my mode was very much "knock something out, pass it on."

At Olin

I'm mildly more social at Olin and definitely more adept working in groups, though I still tend to knock things out independently. Sophomore year I was Editor-In-Chief of Frankly Speaking, the school paper, and promptly recieved a painful crash course on how to not lead a team - so I've had my share of failures. I'm a notoriously prolific tutor, and I suspect this is the main reason seem to respect my judgment more than they should given my actual technical ability. I love to teach and explain things, so I often end up writing plenty of documentation and working with group members who need to catch up.

Teammates have described me as a "swiss army knife," able to fit anywhere, work with mostly anyone, and do most anything; I've pointed out in return that I can do many jobs, but don't fit any of them particularly well ("I can hack at many things, but I can't do more than hack"). I'm better at helping others get work done than I am at getting my own work finished. I have a marked tendency to gravitate towards the role of Alpha-Teacher-Geek, but dislike this preference and attempt to counteract it by consciously stepping back; this doesn't always work.

I have a tendency to think meta in a mildly narcisstic manner, so you'll hear many analyses of my actions (and analyses) in this blog.

Belbin self-perception inventory scores

One article Tim sent out this week had a Belbin self-perception test attached. It's analogous to the Myers-Brigg (for the record, I am a strong INFP), but is focused on how you function within a team context. Click here for an explanation of the categories.
  1. Plant - 19 (Extremely high)
  2. Resource Investigator - 14 (Very high)
  3. Implementer - 12 (High)
  4. Teamworker - 10 (Average)
  5. Coordinator - 7 (Average)
  6. Monitor Evaluator - 5 (Low)
  7. Complete Finisher - 2 (Low)
  8. Shaper - 6 (Ridiculously low)


I'm not surprised by the low Complete Finisher score; if anything, I'm an "Incomplete Fini-Ooh, Shiny!" and need plenty of hounding in that department. I was surprised by the high Resource Investigator score, though. I'm not extroverted, am mildly uncomfortable around unfamiliar people, and am terrified of speaking on the phone (I'm hearing-impaired, so it takes me a while to get used to a new person's voice, and if I can't lipread, I'm lost). I do ask a lot of stupid questions, write copious amounts of email, and read prolifically, so that might make up for my awkwardness around, y'know, actual people.

And that's enough about me.

How are you?