Design Team Dynamics

Sunday, April 16, 2006

Tim: Team evolution and dynamics

Things We Do RightIt seems like a flat heirarchy is mostly preserved in teams here. Frequent delivery seems less necessary because changing requirements for an assignment aren't really tolerated in an academic environment and our "customers" are readily accessible and tend to have built-in oversight.

Things That Go WrongThe Troubled Teams symptoms seem to come down mostly to flawed leadership, incompatible personalities, lack of skills, unclear objectives, and an inadequate or otherwise hostile environment.I feel that the problems that affected my Design Nature team experience most were about communications and an unwillingness to express frustration to other team members or confront power imbalances we were uncomfortable with. I think this relates to the idea of personal safety in teams -- our size works both for and against us, and I think in this case our status as newly-minted first-years in an unfamiliar and very small social environment contributed to our team's problems. I agree with Eric's note that we may feel hesitant to raise concerns about team members -- our small community makes us more sensitive to the potential for conflict.

I almost wonder if there's a difference between how teams function in an academic structure like Olin's and how teams function in the Real World -- which could potentially indicate a failure of Olin's team curriculum. This is completely unbridled speculation since the aforementioned DN group is only real team (even in the loosest sense of the world) I've been on.

Why I've never had any good teams...

I can't say I've had magically good teams at Olin -- nothing that makes me feel like we're about to change the world.

A few thoughts about why...

-Different commitment levels and motivations (particularly with class teams)-Not enough time - barely enough time to build up any norms.-Never effectively storm - because we're all so nice, we never feel that we can really express frustrations-No clearly defined roles

... and also:-Goals unclear-No sustained commitment to managing the project or looking ahead-Don't work closely enough, often enough - often, parallel work gets done outside of the team, rather than in physical proximity.

Friday, April 14, 2006

Mel: Software vs. Hardware reflections

I'm at a family reunion in Chicago and absentee from this week's meeting, sothis post is an attempt to make up for that.

Tools to promote osmunication

The first reading was on software design teams and how they could be made effective. I was especially taken by the idea of osmotic communication, which is that state of interconnectedness where team members seem to be reading each other's minds. Information flows so freely, it's almost unconscious; you bump into someone in the hall, yell across the room, peek at their monitor, modify a shared file, and move on. Like every skill that's been mastered to the point of unconsciousness, osmunication (my term for it) takes a lot of work and careful design to put the right structure in place, and then the courage to let it all go and see what happens. I've come across several free software solutions I'd love to try out to see if they will help osmunication happen faster. Anyone interested in doing a short project using one of these to see how it goes?

Basecamp and Campfire from 36signalsOpen Workbench (like MS Project, but free)Trac by Edgewall Software (the Olin Intelligent Vehicles Lab used Trac last summer; it looks like it worked well).

One caveat: these solutions are geared towards software development teams, as is the book chapter referred to above. Software != hardware. To change software, you type. (It's not an easy process by any means; sometimes changing one line of code ripples down through dozens of other files.) However, it's a lot easier to modify than hardware, which you need to get material for, machine, polish, install... If you're writing a program, it's possible to notice something six months after writing the first file and still have a chance at going back and fixing it. If you're building a house, you can't repour the foundation after you've installed the windows.

Keep this in mind while you're reading about software development practices. Most of the same things apply to other teams; some of it will not.

Choosing a team leader

The second article examined case studies of several successful and unsuccessful teams. In all these case studies, the leader was seen as having a clear role in the success or failure of the team. Specifically, the leader must be respected by her team and have a style of leading that transforms the people he works with. This is echoed in the book Good to Great by Jim Collins; leaders need to be quietly transformational.

"Project Agamemmon" was one case study, a team led by a new manager named "Frederick." The team ultimately fizzled; Fredericks's lack of experience was cited as one primary factor. Without technical expertise, he couldn't earn the respect of his workers, and ended up fading into the background as the leader-in-name-only with one of the senior technical workers taking up the real lead.

It's tough to pick a leader; often the best leader is not the one with the most technical expertise, and often the ones with technical expertise are not the best at motivating others. (Olin tries to produce people who can do both, but this issue still comes up). It's a little easier to pick a team leader if all the folks in a group already know each other's skills and strengths at the start; in those cases, everyone almost automatically knows who ought to be in charge. But on a team where nobody knows each other and skill sets seem to be even enough at the start not to set someone apart from the rest, how do you choose a good leader? (Or do you even choose a leader at all?)

Wednesday, April 05, 2006

DDIS Weeks 5-6: Task Management

Probably the thing that struck me the most about these readings were the need to really establish good rapport with other members of the group. Trust plays a major role in all this, and to build trust one must first build familiarity with one another. It is therefore important to spend some time in a group just allowing group members to get to know each other a little better. By building trust, a team will work much more effectively as a whole as team members who trust one another will keep an open line of communication which will help maintain clarity of goals among team members.

Looking at the two articles on virtual teams brings the issue of interpersonal communication to the forefront. In such teams you don’t have the advantage of being able to easily communicate with your team members face to face so a much greater effort must be made toward establishing clear communication between team members. This rather extreme situation of group structure reveals how important clarity is to managing a group and assigning tasks. It’s important that all group members have a shared set of goals that are communicated to all members of a team. Assumptions made by individual team members can be dangerous in this case, because they run the risk of having team members develop different assumptions for completing a task and thus can cause the team to pursue different, disjoint goals.

One other thing that I found interesting was the way group effectiveness is defined. When we think about group effectiveness, we usually think of the end product or deliverable of the group. However, group effectiveness has other indicators as well, such as how well group members will be able to work together in the future and whether or not the members grow or learn through working in this group. The effectiveness of the group, thus, is largely related to the well-being of the individual group members as well as the interpersonal relations of these people. A group that learns to work well together will be equally or even more productive in future group projects and will learn more which then can contribute to future projects as well.