Of Team Size, Social Loafing and Lack of Direction

Maximilian Ringelmann was a 19th century French agricultural engineer. I'm guessing there's not too many of those around right now - both from the engineering discipline and  country of origin perspective. Anyway, Ringelmann discovered that as more folks pulled on a rope, more force is exerted. However, the increase on the force is NOT commensurate. Maximilian measured a type of "social loafing" - the individual, per capita effort lessens as people are added.

As we select teams for continuous improvement activity, we must be mindful of the team size. Large teams, more than eight or so, increase the probability of two types of team muda: 1) social loafing, and 2) lack of direction. Social loafing, or the Ringelmann effect, reflects the inclination of participants to slack and hide...because they can.

If you can't feed a team with two pizzas, the size of the team is too large. - Jeff Bezos, Chairman, CEO and Founder of Amazon.com

Lack of direction can befall team members who outstrip, because of sheer number or perhaps industriousness, the aligning and facilitating capabilities of team leaders and coaches. (Here, we're not talking about problems that are generated by ineffective team leaders and facilitators.) We know that kaizen activity - the identification of opportunities, the countermeasures identified and assigned, the learnings and adjustments that occur throughout the trystorming process, etc. can make the process a little less than orderly and predictable. Added to that chaos factor, if the team is too large, team members are  more likely to experience the waste of:

  • Waiting. Nothing like hanging around for someone to assign another task for you after you just knocked off a countermeasure.
  • Over-processing and over-production. Virtually all participants want to do value-added work. So, if there is an absence of direction (and alignment), there's a decent chance they'll do something, perhaps more than is required (scope creep!!) or do it prematurely - like developing visual controls before the "system" is defined, which can lead to...
  • Defects. Redoing stuff when it's not part of the normal PDCA cycle is demoralizing. Sometimes it does not require rework, but rather scrapping - like when two people or sub-teams end up doing duplicate work. Not good.
  • Opportunity. Well executed kaizen is an opportunity for folks to improve the business. It's also equally about improving the worker's PDCA skill-sets and developing a lean culture. When teams are too large and they suffer the above described dynamics, we end up squandering these transformative opportunities. We then give people a good reason to call into question our competency and credibility as lean leaders.

So, how do we avoid the Ringelmann effect and the lack of direction trap? First, don't pick a team that is too large... and always employ effective pre-planning (inclusive of clarity in scope, measurable targets, best practice team selection, required pre-work, a solid initial strategy, etc.), proven work strategies (prioritization of countermeasures, assignment, frequent status checks, etc.), promote and enforce proper team behaviors (focus, shared leadership, candor, bias for action, etc.), all while empowering the team members to figure out much of the "how" (as long as it's consistent with lean principles) and providing them with the necessary encouragement, training and resources.

When a large team is required either by virtue of the scope/work that needs to be done or the need for multi-level and cross-functional representation, then (after you've decided that you can't reduce the scope), consider the opportunities for sub-teams, load up the team with folks who have strong kaizen experience, ensure that you've got an ace team leader and facilitator and make sure that you've done a heck of a pre-planning job.

I'm sure I missed some things. What do you think?

Related post: Kaizen Event Team Selection – No Yo-Yos Needed

There are 3 Comments

leansim's picture

I like small, intimate groups, especially useful for one-on-one training. Depending on the scope of the kaizen, I prefer a facilitator and 4 or 5 others. Each person can be involved in the problem at hand.
Of course, when doing large scale training, you can run great simulations with 10 to 20 people competing in teams. Due to the "loafing" aspect you mention, this is works best with generic overview style training.

Matt Wrye's picture

Mark, you are right on with this. I have seen teams get too large many times. I have coached managers in selecting appropriate teams for the kaizen events but sometimes they go against the advice, trying to get everyone involved. Instead, too many people end up standing around and you are trying to keep them busy or the group is too big and not as many ideas are shared because most employees don't want to share in front of a big group.

I really like you suggestion that if the scope is too big, have a core team and then smaller subteams. I have seen that work.

markrhamel's picture

Hi Matt,

Thanks for the comment and the sharing of your experience!

Team size is a fairly basic concept, but it gets complicated when we don't do a good job scoping the target or carefully getting proper team representation without including "everyone." Team selection is critical within a number of different venues and vehicles - strategy deployment sessions, kaizen events, mini-kaizens, daily kaizen activities, etc.

Best regards,
Mark