Teams, Two Ways They Can Drag You Down…
My favorite class in undergrad was: “Organizational Behavior and Theory”. I’m a people watcher, and I find the dynamics between people fascinating. Interpersonal subtleties at work are often complicated, generally everyone has his or her own agenda. This plays out the most intensely when it comes to team projects; not surprisingly the size of the team has a drastic impact on its effectiveness.
How teams CAN drag you down
There’s been research done on optimal team size for well over 100 years. French engineer, Maximilien Ringelmann discovered what is now called “The Ringelmann Effect”. Ringelmann measured the force of individuals pulling a rope. All members were measured individually, and then each member was added to a team. As people were added to the team the sum power increased, but not by the amount that everyone could produce on their own. Individual effort simply diminished at the size of the team grew.
A modern twist on this view is a theory Jeff Bezos has. The theory is loosely: if a team can’t be fed with two pizzas the team is too large. Bezos clearly understands the results of Ringelmann effect, when teams get to large there’s room to hide. Maintaining smaller group sizes keeps visibility forefront. We’ve all had experiences in small groups where it was blatantly evident when one person wasn’t pulling their weight. General research shows that when teams get to approximately 12 – 13 people visibility and motivation breaks down.
How does this translate into IT? I don’t know if you’ve spent any amount of time with IT folks, but we can eat a LOT of pizza… If a team must meet the two-pizza limit, an IT team working on a project maybe smaller than an accounting counterpart. All humor aside, an IT project team needs to be just large enough to make sure personal bias isn’t leading a company’s technical direction. I’m sure we’ve all seen cases where someone wanted to persist in a technology decision for personal gain. I have an insurance client who was evaluating Exadata by Oracle. Over a private lunch the senior Oracle engineer told me: “I don’t know if this the right move for the company, but it’s great for my resume.” This is a case where the team dynamic wasn’t healthy, there weren’t enough people on the team to identify and stop an individual from railroading the project for their personal gain.
Many people speak of the benefits of team diversity, but when it comes to getting complex tasks done in a timely manner, diversity may not be optimal. Research done by the Whorton School of Business (link here) found people who share mental models and a common understanding of a problem were more effective in completing tasks. The source of this loss seemed to be complexity in communication that is more prevalent in groups that don’t have common points of view.
This directly contradicts current notions that diversity increases quality. This may be true in areas such as marketing where you’re trying to target a wide group of people for sales. I’m sure this is controversial for some, but I would state this, research doesn’t state to omit gender or racial diversity. Data shows that people work most effectively with others who have similar mental models.
Again, how does this translate to IT? Let’s use a relevant trend in today’s enterprises, public cloud adoption. If you work in or have worked with enterprises, you know this is a controversial topic. Many individuals with a long history in enterprise IT simply don’t understand public cloud. If rolling out a new application quickly is the objective, cloud-first individuals and two traditional infrastructure individuals, may not be the best team structure. There will simply be a mental model difference, and the project will likely grind to a halt.
I do see at least one area where mental model diversity is a positive: teams that are designed to cause disruption. In the example of public-cloud adoption I would attempt to construct a team that would be filled with healthy conflict. Conflict is the only way that change occurs, and if companies today want to maintain relevance they must evolve to meet customer needs.
Where’s the Proof
While the effects of these complicated relationships are hard to measure we do have some academic proof. Three researchers: UCLA (Staats), Penn State (Milkman), and Chapel Hill (Fox) conducted a study where teams of various sizes were asked to build a LEGO model. Teams were grouped in twos and fours, they were shown a LEGO construct, and had an image of the construct. They were then instructed to rebuild that construct exactly as it was. The results are shown below.
The results are astonishing: the teams of two finished 16 minutes faster than teams of four. Not only did smaller teams finish faster, they estimated a lower completion time out of the gate. It seems that people naturally build in extra time for interfacing with other individuals. That time interfacing seems to grow exponentially as the size of teams grow.
There’s a fine balance between having IT teams with enough knowledge to complete a task, and being too big to be effective. With complex IT projects that require many individuals it’s recommended that sub-teams are created; sub-teams are assigned tasks with specific outcomes. This limits the ability for individuals to hide within the larger organization. This method also allows individuals in maintain a sense of ownership for their piece of the project. Lack of ownership is a fundamental reason people disengage.
A side benefit of having smaller teams allows individuals to attend meetings that are only relevant to their roles and responsibilities. This frees up time and cycles to execute on the mission at hand, and stops the cycle of having meetings for the sake of meetings. By avoiding these pitfalls, your teams can be more effective and productive on their projects, and you won’t be dragged down by The Ringelmann Effect.
Harvard Business Review: Why Less Is More in Teams