Wednesday, August 23, 2006

Requesting Advice 1

This semester, I'm involved in a team-class-project to solve an engineering problem. This happens a lot throughout my education, for obvious reasons. And once again the professors are distributing the usual teamwork-is-awesome stuff. Some of it pretty good this time around. However, in my experience with teamwork so far, there have been some disasters, and I was wondering how I might help steer the group clear of them, avoid causing them myself, and contribute more effectively.

My question is this: Are there any teamwork strategies that have worked extremely well from your experience, over others? Are there any failure modes that commonly happen that turn your team into a disaster?
If you were in the leader's position, how would you ensure that everyone had what information they needed? Keep meetings on task?
If you were in a follower position watching one of these failure modes occur, how do you counter it?
Do waterfall diagrams signify anything corresponding to the project? /sarcasm


Anonymous Gordon said...

It was interesting to watch the dynamics in my son's (BEST) robot club a couple of years ago. The first time it was all new and they all worked together and actually came up with a pretty good design, and made it to the finals at Texas A&M.

Well, next year more students wanted to be involved, of course, which made managing and teamwork more difficult. The larger group also meant it took much longer to communicate, to get everyone together, and to actually MAKE DECISIONS!

While the most obvious result was schedule slippage, there was a deeper problem - they never really got their heads together about the fundamental design problem. The rules/tasks for the robot had changed (it had to move balloons) and while I mentioned to my son a couple of times that moving one balloon at a time didn't seem like a good strategy, the dads pretty much stayed out of it.

The large group meant they moved toward a bureaucratic not-very-clever strategy that was settled upon without enough careful thought. This alone was enough to doom them, but they also failed to catch a design change that broke one of the rules. As a result, the leaders ended up redesigning a lot of it the night before the competition, after most folks had left.

Moral of the story: There is an optimal group size for teamwork to be effective. This varies but is usually smaller than generous resources would allow. Also, you must maintain independent thought that continues to question things throughout the design process (Burt Rutan calls this the "Always Question" approach, I think).

Also very important is that group size must not be allowed to create large lags in communications and decision-making, since this will reduce the number of prototypes/iterations. Midway through, they reduced the wheel size. I had a bad feeling about that, but didn't know why. This actually ended up being the final straw, because their robot kept getting stuck on power cords taped to the floor (a real bummer after staying up all night, which might have been discovered if they had iterated earlier and had time to test fully).

You're right that it's very difficult to keep meetings on task. I would also say that a little confidence combined with immaturity can quickly lead to arrogance. Once arrogance sets in, leaders don't listen any more and end up getting blindsided.

Always questioning and iterating quickly enough to allow plenty of testing can go a long way toward reducing risk.

A final point: I noticed that a lot of the less-technical folks (including my daughter, who joined the second year) were relegated after a while to "team spirit" type activities, painting posters, making t-shirts, etc. Keeping these extra folks busy will make them happier and allow them to make a real contribution without slowing down the design work.

Good luck!

Saturday, August 26, 2006 5:07:00 PM  
Blogger qwerty182764 said...

Thanks for your reply.

Saturday, August 26, 2006 5:42:00 PM  

Post a Comment

Links to this post:

Create a Link

<< Home