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.