Skip to main content
About HEC About HEC
Summer School Summer School
Faculty & Research Faculty & Research
Master’s programs Master’s programs
Bachelor Programs Bachelor Programs
MBA Programs MBA Programs
PhD Program PhD Program
Executive Education Executive Education
HEC Online HEC Online
About HEC
Overview Overview
Who
We Are
Who
We Are
Egalité des chances Egalité des chances
HEC Talents HEC Talents
International International
Campus
Life
Campus
Life
Sustainability Sustainability
Diversity
& Inclusion
Diversity
& Inclusion
Stories Stories
The HEC
Foundation
The HEC
Foundation
Summer School
Youth Programs Youth Programs
Summer programs Summer programs
Online Programs Online Programs
Faculty & Research
Overview Overview
Faculty Directory Faculty Directory
Departments Departments
Centers Centers
Chairs Chairs
Grants Grants
Knowledge@HEC Knowledge@HEC
Master’s programs
Master in
Management
Master in
Management
Master's
Programs
Master's
Programs
Double Degree
Programs
Double Degree
Programs
Bachelor
Programs
Bachelor
Programs
Summer
Programs
Summer
Programs
Exchange
students
Exchange
students
Student
Life
Student
Life
Our
Difference
Our
Difference
Bachelor Programs
Overview Overview
Course content Course content
Admissions Admissions
Fees and Financing Fees and Financing
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
Home Home
About us About us
Management topics Management topics
Open Programs Open Programs
Custom Programs Custom Programs
Events/News Events/News
Contacts Contacts
HEC Online
Overview Overview
Degree Program Degree Program
Executive certificates Executive certificates
MOOCs MOOCs
Summer Programs Summer Programs
Youth programs Youth programs
Article

How to Structure Teams for Optimal Performance

Operations Management
Published on:

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.

Methodology

methodology
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

Aishwarya Karunakar
Graduate of the SASI MSc
Sustainable Development
Can ESG Save Life on Earth? Key Lessons
Helene Loning - HEC Paris
Hélène Löning
Associate Professor and Academic Director
clarisse pierre
Clarisse Pierre
MSc Sustainability & Innovation at HEC Paris, incoming Social Innovation Consultant
photovoltaic panels on house roofs-thumbnail
Operations Management

How Can Communication Boost the Adoption of Renewable Energy?

By Andrea Masini, Sam Aflaki

Operations Management
Why are Family Businesses More Sustainable?
Monica Santos Silva Knowledge HEC
Monica Santos Silva
Sustainability Projects Coordinator