UNC Kenan-Flagler Insights

The science behind building a high-performing team

June 15, 2011 By Heather Harreld

diversebusinesspeoplFor many managers, putting together a team for any given project is a pretty straightforward art. Try and find people you think will best represent the needed skills.  Pull together employees from all the functions and business units whose performance depends on the outcome. And, of course, avoid pairing up people who can’t stand each other.

But leaders who really want to improve the performance of the teams of knowledge workers they manage should think of the process as not just an art, but a science.

Recent research by UNC Kenan-Flagler professor Bradley Staats shows that when building teams, paying attention to familiarity (how much members of the team have worked together in the past) and diversity (specifically, how many members of the team have experience with a broad array of clients) could help more projects come in on time, under budget and with the best quality results.

Staats got interested in the topic after hearing from companies that said some of their biggest difficulties were in managing and coordinating teams, especially as the business world has become so much more globally inter-connected, technologically driven and geographically far flung.

“We know how hard it is to coordinate a fully ‘co-located’ team that has spent years in the organization together,” he says. “But then magnify it to where team members are from different cultures and they speak different languages.”

Staats studied software engineers at Wipro Technologies, the Bangalore-based tech services giant, to understand how past experience has an impact on team performance, and reports his finding in three papers.

He first measured how often team members had worked together on past assignments. Not surprisingly, Staats and his co-authors, Harvard Business School professors Robert Huckman and David Uptonound, found that high “team familiarity”—the average number of times each member had worked with every other member of the software development team—resulted in better performance. Seniority, meanwhile, did not matter.

Staats took the idea a little further in a forthcoming paper in the journal Production and Operations Management. He looked not only at whether team members had worked together, but under what conditions and in what roles. He found, as one might expect, that teams that had worked together at the same location had better performance than those that had been geographically separated. Additionally, he discovered that high levels of familiarity between project managers and engineers resulted in better efficiency, while high levels of familiarity between engineers resulted in better project quality.

He looks at team diversity in a third paper, also forthcoming. This measure doesn’t refer to race, gender or age, however. Nor does it allude to the management trend du jour of putting people from across the company—an HR director, a front-line hourly worker and a chief marketing officer, let’s say—in a room together to brainstorm in hopes that sparks will magically fly and innovative business ideas will spontaneously flow forth.

Rather, Staats studied which of the following was more important for performance:

  • “interpersonal diversity” (the differences in experience from one team member to another)
  • “intrapersonal diversity” (whether team members were more or less specialized)

When it comes to the constantly changing nature of projects in today’s business world, he found, the latter contributes to improved performance, while the former might lower results.

For example, say you had two teams of 10 software developers. In one team, each of the 10 members had worked on projects for the same client for five years, but each of the 10 clients was different. In the other team, each of the 10 members had worked with five different clients, but each for only one year. While you might expect better performance from the first group—a team of specialists each contributing their own accumulated expertise—the latter group of generalists (the team with higher “intrapersonal diversity”) are likely to perform better.

“A team of generalists are more flexible than the specialists,” Staats says. “The more different we are,” at least in terms of work experience, “the more we run into problems.”

There’s an element of common sense in these findings, to be sure. One would expect teams that have worked together many times in the past—especially if they’ve built relationships working side by side in person—to be smarter, faster and more efficient than others. A little more surprising, but still logical, is the idea that the more well-rounded nature of generalists produces better work than  does a group of highly specialized experts.

The fast-paced nature of business, however, results in managers who frequently don’t look beyond technical skills and external relationships when forming teams. Staats’ findings provide evidence for why leaders should look at a team’s internal bonds, too. “In most organizations I’ve interacted with, there are no formal mechanisms” for looking at such measures, Staats says. “There may be a team leader who has an ability to go out and pick people, but it’s not that there’s any kind of formal structure to it.”

While Staats has mainly studied software development and consulting firms, he believes his research has applications for other, less project-centric businesses. Encouraging managers to think more rigorously about structuring teams increases the chances of better performance. Doing so also can help create a competitive advantage that employees can’t take with them.

“If our most valuable resources walk out the door every day,” Staats says, “then we have to think about managing not only our product portfolio, but how we manage the portfolio of experiences that individuals have.”