How to Structure Teams for Optimal Performance

This article by HEC Paris appears originally on Knowledge@HEC.

Should teams be hierarchical, with clear task delegation, or should they be flexible and self-organizing?

So far, literature and practice offer as many examples as counter-examples in favor of each model. By distinguishing between the types of tasks and the coordination each require, a new study of software development teams is able to recommend the best configuration for successful teamwork – a finding potentially applicable to any domain.

We’ve known since Aristotle that the whole is greater than the sum of its parts, and it’s certainly true of teamwork in any setting, from the football field to the operating room – and of course, the office: team ability is more than the sum of individual abilities. But coordinating team members’ varied skills and levels of knowledge to achieve the holy grail of a highly performing team is a major challenge.

This is particularly true in the context of software development, because of its intellective nature and the different kinds of expertise it requires. Factor in the difficulty of gathering and stabilizing requirements, the constant evolution of technologies and tools and the high level of abstraction of software, and the Standish (Chaos) 2015 report figure of a mere 29% success rate for IT projects sounds less surprising. “Some say that software development is one of the most complex endeavors undertaken by human beings,” says Sri Kudaravalli, who explored the collaborative mechanisms underlying team performance in that sector. He and his co-authors Samer Faraj and Steven L. Johnson examined how expertise is coordinated in practice, with a study of 71 software development teams in a large IT firm in the U.S. By differentiating between two major areas of collaboration in IT projects – design and technical work – they were able to overcome the limitations of traditional team design models. Their results are potentially applicable to many different domains.

Top-down vs decentralized models

Conventional wisdom relies on the analysis of formal procedures and group structure to recommend two canonical structures for software teams: a centralized, top-down configuration and a more decentralized one. The former relies on a key individual to lead the team and manage requirements gathering, client interaction, task delegation and so on. “The ‘chief programmer’ model, whereby engineers with experience in processes and tools are promoted to the role of team leader, was popular in the old days, and still is,” says Sri Kudaravalli. But in recent years, the limitations of this model became apparent: having just one person overseeing large teams results in a bottleneck. “There is a limit on how much a single person can coordinate,” comments the researcher. So more decentralized methods have been proposed, with flexible roles and collaborative decision making. One popular concept in such “agile” structures is “pair programming”, with not one but two programmers writing code together, with more back-and-forth and more chances to catch errors.

But again, this model, perceived as more relevant for small teams, is far from perfect, as increased interaction creates increased coordination challenges, delaying decision-making for instance. “It is no accident that groups that need to react quickly, such as the military, are organized in that hierarchical way, because clearly defined roles and responsibilities mean more efficiency,” points out Sri Kudaravalli. “In a surgical team, for example, everyone contributes depending on their expertise, but in the end the surgeon makes the call.”

So how were the researchers able to take the debate a step further than centralized vs decentralized? They theorized that the optimal team configuration depended on the type of expertise being coordinated, and focused on two key types of expertise: design and technical. “The distinction is widely accepted in practice and roughly parallels the one between designing and constructing physical structures where designs are developed by architects and handed off to contractors,” write the researchers. This distinction is crucial because the problems in each domain are fundamentally different in nature: design problems are said to be “ill-defined” in that there often are many possible solutions, and none (or rarely) absolutely correct or absolutely incorrect. In contrast, technical problems are “well-defined”, a bit like puzzles, with precise goals and procedures. Sticking to the physical construction analogy, Sri Kudaravalli explains that there is no single answer in the early stages: “Whatever design you come up with, there may be 100 alternative designs depending on individual preferences, aesthetics…but once you’ve picked one, and go into the specifics, there are fewer alternatives, for instance, perhaps only one material strong enough for a certain supporting beam.”

Knowledge and conflict

The field study showed that centralizing team interactions in technical collaboration resulted in more successful outcomes, whereas design collaboration benefitted from less centralized interactions. According to the researchers, these outcomes are mediated by one very human variable: conflict. “When design is centralized, the process may be perceived as arbitrary and unfair, because team members don’t know how the solution was chosen among the many alternatives,” explains Sri Kudaravalli. But when design questions are handled in a decentralized way, with more people bouncing ideas back and forth and discussing their respective merits, the outcome is better accepted, resulting in less conflict and eventually better team performance. On the other hand, technical tasks, which fall into the well-defined category, make formalized division of labor less conflictual, resulting in more effective teamwork. Another variable that comes into play is tacitness of knowledge, or the ease with which it can be articulated and shared. When tacitness is high (knowledge is difficult to share), centralization works even better for technical collaboration and so too does decentralization for design collaboration.