Design Team Dynamics

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 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.

2 Comments:

Blogger Eric (the M) said...

Osmunication

<3 cool software projects that are meant to make people work more effectively, but...

I'd push back, and say that these are actually not forms of osmunications, that task management tools, like "ineffective and labor-intensive documentation", actually get in the way of having a team be fast and effective.

The ideal: I'm crammed into a small office with my teammates; everyone has stickies up on their workspace and each of us has our work laid out on the table; by looking to my left and right I can immediately see where we are as a team. I can yell out, "What do you need me to do?" and I'll get immediate responses. Personal communication, all the way.

PM software would be useful for distributed projects, when you simply can't have face-to-face, personal communication-- but when there is the option for personal communication, that's the option people will always take-- it's easier, it's higher-bandwidght, it's immediate, it's cool.

Knowledge-management software would be cool, though... as the second reading often mentioned that as a task which fell to the team leader. Is that a good thing?


On "choosing" a leader

forming - people try to fit in prescribed, comfortable roles
storming - something goes wrong with that
norming - new order emerges

... and with that, a new leader.

I haven't yet really explored this (hence the blogging), but here's my hypothesis: at Olin, most teams don't get beyond the "forming" stage-- when the team will seek security by assigning leadership to "someone who knows what they're doing" - or at least, the team member who ca n convince everyone that she knows what she's doing.

I would expect, thought, that if a team is truly flexible, the "storming" phase will tear down those initial roles, and the team will go through a painful re-assessment and re-assignment of roles. At which point the real, most effective project leader will emerge, in the norming phase.

thoughts this brings up:
-Is it more effective to quickly move into storming?
-What can a team do to make norming more effective?
-When can or should someone be designated as the team leader?

hrm...

11:30 AM  
Blogger Mel said...

Completely agree with the in-person > PM software bit. For distributed teams and documentation, you can't beat PM software, though - which is where it gets tough; what communications should you document? (Yes, it's faster for the two of us to sit down and talk about a spec sheet in person instead of writing it down, but if that spec sheet needs to be read by Joe Q. Intern three years down the road, maybe we're better off sitting at a desk together and typing it out in the first place - Xtreme SpecWriting, so to speak.)

The best PM things (in-person communication, stickies, and across-the-studio shouting included) are the ones that document as they go, are transparent, and don't require extra thought... they should be automatic as humanly possible. The team leader can't and shouldn't have to run knowledge management, although they're the ideal person to make sure knowledge management is done (by everyone else on the team as they're going).

On picking a leader...

A leadershipless team is (or at least is seen as) a dangerous thing. There's no central point of contact; there's no central point of responsibility. If things fall through, nobody is there to step up. So there's a tremendous amount of discomfort when people see or are put on a team with no leader. It terrifies us, and it should.

Having said that, I agree completely that the storming phase (which we usually don't reach at Olin) is where that leader emerges, and that you need to let go of everything and have the hierarchy dissolve into temporary chaos in order for it to reorganize itself in a better way.

Is it more effective to move quickly into storming? Yes, if the entire team is conscious and agreeing to this process; trying to force a team to fight more is just going to make it take longer to stop. Having everyone on the team realize that now is the time for chaos and dissent, however, opens up the possibilities for it to be handled in a more sane/mature/caring manner.

I'm not sure what you mean by "making norming more effective." I think the biggest problem teams make is moving into norming while a couple of the members are still storming; gotta let everyone get that out of their system first.

When can/should someone be designated as the team leader? I don't know, but here's how I'd like to try it on my next team:

1. Designate a temporary volunteer leader (coordinator/point person) at the start, making it clear that they're for consolidation of communications, the sake of outside people not being freaked out, and willing to step down if someone else wants to step up.
2. Let 'er rip.

My guess is that the temp leader will, more often than not, be the end leader - but this provides for the possibilities of the storming/norming shift without the tricky issue of stepping on someone's toes; if they were willing to step down in the first place, there are no toes to step on.

8:26 PM  

Post a Comment

<< Home