Tim: Team evolution and dynamics

Things We Do Right
It 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 Wrong
The 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.

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 36signals
Open 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?)

I'd love to hear what people think about this.