Skip to main content
About HEC About HEC Faculty & Research Faculty & Research Master’s programs Master’s programs MBA Programs MBA Programs PhD Program PhD Program Executive Education Executive Education Summer School Summer School HEC Online HEC Online About HEC Overview Overview Who
We Are Who
We Are
Egalité des chances Egalité des chances Career
Center Career
International International Campus
Life Campus
Sustainability Sustainability Diversity
& Inclusion Diversity
& Inclusion
Stories Stories The HEC
Foundation The HEC
Coronavirus Coronavirus
Faculty & Research Overview Overview Faculty Directory Faculty Directory Departments Departments Centers Centers Chairs Chairs Knowledge Knowledge Master’s programs Master in
Management Master in
MSc International
Finance MSc International
Masters Specialized
programs X-HEC
programs Dual-Degree
students Visiting
Certificates Certificates Student
Life Student
Stories Student
MBA Programs MBA MBA Executive MBA Executive MBA TRIUM EMBA TRIUM EMBA PhD Program Overview Overview HEC Difference HEC Difference Program details Program details Research areas Research areas HEC Community HEC Community Placement Placement Job Market Job Market Admissions Admissions Financing Financing Executive Education Executive Masters Executive Masters Executive Certificates Executive Certificates Executive short programs Executive short programs Online Online Train your teams Train your teams Executive MBA Executive MBA Summer School Youth Programs Youth Programs Summer programs Summer programs HEC Online Overview Overview Degree Program Degree Program Executive certificates Executive certificates MOOCs MOOCs


How to Structure Teams for Optimal Performance

Operations Management
Published on:
Updated on:
November 04th, 2020

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.

How to structure teams for optimal performance - HEC Paris Professor Sri Kudaravalli ©Fotolia-adrian_ilie825

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.”


There is a limit on how much a single person can coordinate.

Distinguishing between types of tasks

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.

Practical Applications

Focus - Application pour les marques
The most obvious application of these findings to the corporate world is the necessity to organize teams differently for design work and for technical work. Managers should involve as many people as possible during design activities, but clearly delineate roles and responsibilities during technical work. This recommendation implies that social skills are important when hiring (or picking) for design tasks, as team members should be willing and able to communicate with their teammates. As Sri Kudaravalli points out, the question of team design is applicable not just to software development, but to pretty much any domain, be it sales, finance or many others, but still requires investigation.


The researchers based their study on a survey of 71 software development teams containing 484 members in a large North American high-technology firm. They asked team members to identify design and technical experts and based on that information, constructed interaction networks for each expertise area to observe the configuration of team collaboration. To measure the effectiveness of team interaction, they asked the team managers to rate coordination success (lack of redundancy in work, smoothness of work relations...).
Based on an interview with Sri Kudaravalli on his paper “A configural approach to coordinating expertise in software development teams”, co-written with Samer Faraj and Steven L. Johnson, published in MIS Quarterly. This article has received the "Prix académique de la Recherche en Management" (Consult'in France), with the theme "Reinventing Management". This article was also summarized at Harvard Business Review: How to Get Experts to Work Together Effectively.  

Related content on Operations Management