In the 50 year old book, “The Human Side Of Enterprise“, Douglas McGregor lists the attributes of effective groups as follows:
- The atmosphere is informal, comfortable, relaxed.
- There is lots of pertinent discussion and it stays on track.
- The group’s task is well understood and accepted.
- Members listen to each other and have no fear of looking foolish.
- There is disagreement and no conflict avoidance.
- Decisions are made mostly by consensus.
- Criticism is frank, frequent, relatively comfortable.
- Members freely express feelings on problems and group operation.
- Clear assignments are made and accepted.
- The group lead doesn’t dominate and there is no struggle for power.
- The group is self-conscious and periodically reflects on performance.
So, do you think this list is outdated and inapplicable in this day and age? How many effective groups have you had the privilege of participating in?
For grins, let’s look at an inverted version of the list:
- The atmosphere is formal, uncomfortable, tense.
- There is lots of impertinent discussion and it wanders all over the map.
- The group’s task is vague, undefined and thus, unaccepted.
- Members ignore each other and put on a mask of infallibility.
- There is no disagreement and conflicts are avoided.
- Decisions are made by authority
- Criticism is personal and uncomfortable.
- Members cover up and suppress feelings.
- No assignments are made and tasks fall though the cracks – accepted by no one or the ubiquitous “we”.
- The group head dominates and there is much politicking to curry favor.
- The group is unconscious.
Which of these lists feels more familiar to you?
I’m currently working on a really exciting and fun software development project with several highly competent peers. Two of them, however, like to operate open loop and plow ahead with minimal collaboration with the more disciplined (and hence, slower) developers. These dudes not only insert complex designs and code into their components without vetting their ideas before the rest of the team, they have no boundaries. Like elephants in a china shop, they tramp all over code in everybody else’s “area of ownership”.
“He who touches the code last, owns it.” — Anonymous
Because of the team cohesion that it encourages, I’m all for shared ownership, but there has to be some nominal boundary to arrest the natural growth in entropy inherent in open loop systems and to ensure local and global conceptual integrity.
Even though these colleagues are rogues, they’re truly very smart. So, I’m learning from them, albeit slooowly since they don’t document very well (surprise!) and I have to laboriously reverse engineer the code they write to understand what the freak they did. Even though feelings aren’t allowed, I “feel” for those dudes who come on board the project and have to extend/maintain our code after we leave for the next best thing.