- Familiarity Breeds Performance in Project Teams
- Try Speed-Dating to Create a Team
- Why an Ex-Criminal May be Your Best Hire
Sometimes teamwork science hands you a gift. We all like working with people we’ve had good experiences with in the past. If you’re a project manager who sometimes struggles between choosing someone you like versus someone with more experience, three Harvard Business School researchers have some evidence you’re going to like.
In a study of a large software company, how well a project manager (PM) knew the team members and the team members knew each other was a greater predictor of success than anybody’s job experience. Clearly a certain base level of knowledge and skills is required. But the results reminded me of a study reported in the news saying money can buy happiness, but only up to $75,000 (US). After basic requirements are met, other facts become more important in selecting a project team (or being happier!).
Robert Huckman, Bradley Staats, and David Upton analyzed data from more than 300 projects over 20 months in one company. Wipro Technologies was the third-largest software services firm in India at the time. Wipro’s internal databases allowed the researchers to calculate figures for data such as:
- How long a team’s project manager (PM) had been a PM.
- How long its developers had been with the firm, which probably reflected their overall experience, given that two-thirds joined the company less than two years into their careers.
- Other factors that could affect the results such as the type of contract, how much of the development was done off-site, and the software’s complexity.
How often project team members had worked together was more strongly linked to team performance than the members’ job experience. What scientists call “team familiarity” was linked to fewer code defects and greater likelihood the project was completed within the labor estimates by themselves, or labor and schedule estimates combined. Higher familiarity related to fewer problems in every area except meeting schedule estimates. So the best predictor of success on most measures was how well people knew each other, not their years in their jobs.
PM experience was linked to the degree of labor estimate accuracy, and engineer experience to a simpler yes/no measure of whether the labor target was met. (The authors said additional factors had significant correlations, but I use a more conservative statistical standard.)
PMs more familiar with team members might be better at assigning work based on member skills, the researchers suggest. People who know each other might be more willing to, and find it easier to, interact. Also, familiar engineers might be more willing “to put their reputations at risk by asking questions and sharing errors earlier in the process,” they write. The authors suggest that managers might do well to consider familiarity, not just work experience, when putting together project teams.
I asked Staats, then an assistant professor at the Kenan-Flagler School of the Univ. of North Carolina, why that would be. “It makes people more likely to share information,” he said. As a team member, “I learn that it is okay to take a risk in this environment. Or maybe I learn that it’s not okay,” he added. Knowing what you can and cannot safely do is useful in avoiding conflicts, I suspect. Many studies have shown that teams perform better if members share information freely. Staats pointed out that familiarity makes it easier to know who to go to for specific information; easier for that person to share; and easier to use.
Meanwhile, “Managers are more effective at allocating work” and more likely to get open feedback when dealing with someone they know, he said. Trust helps a group operate smoothly, and there’s no better way to develop trust than the trial-and-error of taking risks with each other.
You may rightly question whether results from one company in one industry in India applies to your company, but this research method eliminates some other concerns by providing an apples-to-apples comparison. Since all of the teams were doing similar work with similar workers from a well-defined culture and subject to the same corporate environment, the likelihood is pretty high that familiarity was the key instead of some other hidden factor.
I asked Staats how much weight to give experience versus familiarity when choosing project team members. He said it could be a second-round filter. For example, he said, a developer may have to know Java for your project. But if there are three of those available, you now have scientific backing for choosing the Java developer you know the best even if that person is not the most experienced.
There are some possible downsides to familiarity. We know teams with one or two newcomers to the industry and/or company perform better than similar teams that don’t, probably because the newbies inject new ideas or question assumptions. After you’ve used the same group several times, it may be time to add some new blood, and it’s always smart to invite outsiders to meetings when they have a stake in the topic.
Also, if you manage permanent teams, too much familiarity could lead to the dangers of “groupthink,” where members stop listening to anyone outside the group or risking dissension within it. Staats said he thinks that does not happen to all teams, since familiarity makes questioning others feel safer. Based on a study cited in his article, he said it could take more than four years for groupthink to become a real risk.
If you’re a manager or on a self-directed team, here are some suggested steps for team selection from a class I used to teach on the science of team leadership. I suggest creating a job description for each role even if only choosing internal candidates. First determine the knowledge, aptitudes, and technical skills (KSAs) the perfect candidate would have. Add in behaviors you expect from team members, like, “Does not yell at customers.” Then identify the KSAs and behaviors on the list that the person absolutely must have to be productive which can’t be quickly learned on the job. Make those the only “Requirements,” and list the rest, the “nice-to-haves” and items that can be learned quickly enough, as “Preferences.” That way you don’t filter out people who might meet other criteria better, like familiarity. My reading of teamwork science including the Harvard study suggests you will maximize team capability by following these criteria when selecting project team members, in the order shown:
- Ensure team “must-haves” are covered.
- Choose people who have worked together previously and you know, allowing room for #3.
- Provide diversity of background and of time within your industry or company, trying to include some relative newcomers.
- Use “nice-to-haves” as tie-breakers.
In this case, doing what feels right—choosing people you like—may also be the scientifically right thing to do.
Source: Huckman, R., B. Staats, and D. Upton (2009), “Team Familiarity, Role Experience, and Performance: Evidence from Indian Software Services,” Management Science 55(1):85.
Despite the claims of many consultants, we don’t know much about how to create a team. As European organization researchers wrote, “the question of how to form effective teams remains largely unanswered.” In 14 years of looking, I found very few studies relating to the choice of people to maximize team performance. Through research and experience, I’ve learned quite a bit about hiring into a company or hiring for the best fit between a worker, the skills required, and the manager. But anyone who claims their personality tests or similar tools predict how well job candidates will perform as a team is at best fooling themselves, and at worst trying to fool you.
A study by that European research team takes a bizarre step in the direction of practical team-making tips. The study says, “we use a matching procedure, popularly known as speed dating…”
Yes, they’re serious.
The researchers compared undergraduate class teams built to maximize diversity of gender and nationality to another set in which members basically selected themselves. Every student in that set met with 17 other students briefly, and then chose people they would like to work with. Giving extra weight to pairs who selected each other, the researchers created teams of five to six students each at the start of a semester. At the end, the students completed one teamwork questionnaire per team by consensus.
On every measure, the “team-dated” teams reported higher scores:
- cohesion (“the tendency for a team to stick together,” the study explains)
- potency (“the team members’ collective belief that the team can be effective”)
Team members also worked by themselves to create “cognitive maps” related to the course subject. Each student was given 20 cards with different concepts and asked to organize the cards any way “that made sense to them,” the study says. Then the student wrote down how each pair of concepts was related. Possibilities included cause-and-effect, order in time, hierarchy (like an organization chart), and four others. The individual maps were combined by the researchers to see how complex the team’s thinking was, with more connections equaling more complexity. They also had experts in the subject matter create maps, and compared the team maps to the expert maps to judge accuracy. The team-dated teams had a more complex and accurate view of the subject matter than did the teams selected for diversity.
If you’re thinking higher diversity hurt that set of teams, it turns out the self-selected teams were not much different in their diversity levels. Besides, among all teams, those with more diversity of nationality had more concept complexity and accuracy. I’m sure there’s no connection to the fact that the research team, led by Petra Curşeu of the Tilburg Univ. in The Netherlands, was multinational itself, including Belgian and German scientists.
The research team recommends team-dating for creating teams from two organizations, giving the example of a company merger. That doesn’t mean you have everyone team-date everyone else. Say you were splitting up the merging companies’ marketing teams among various product lines. You could have all of the marketers team-date to select the teams, and then assign those teams based on level of knowledge of the product line. Another possibility is forming project teams that each need a similar mix of skills from a pool of people with those skills—project managers and Java developers for several Java projects, for example.
The way the researchers did this was to set up nine people in separate rooms. Nine others were each given a sheet of paper showing the order in which they were to switch rooms. They met for two minutes, then had 30 seconds to switch. The “sitters” had similar sheets on which all could check whether they would like to work with the persons they met with. They could choose up to eight. Combining the results, the researchers were able to draw a map similar to a concept map with lines connecting people according to their preferences. Clusters of lines and people were pretty obvious and each grouping became a team.
We don’t get a direct measure of team performance like grades in this study. But we know teams with formal procedures, higher satisfaction, and better shared knowledge of their tasks generally perform better. So as much as it amuses me to say this, if you have a situation in which team-dating is possible, I think it’s worth a shot!
Source: Curşeu, P., P. Kenis, J. Raab, and U. Brandes (2010), “Composing Effective Teams through Team Dating,” Organization Studies 31(7):873.
If you would like to have a hard-working, loyal team member, consider hiring an ex-criminal. At the very least, it may keep you out of trouble.
No, I’m not joking on either count. We’ll start with the latter. An article published as far back as 2010 by the Society for Human Resource Management (SHRM) states that “pre-hire testing and background screening of applicants’ credit reports and criminal histories have come under increased scrutiny…” U.S. Equal Employment Opportunity Commission (EEOC) hearings and its successful lawsuits against these practices are evidence.
The EEOC asserted in one that the plaintiff company used credit histories and criminal background checks to unlawfully “deprive a class of black, Hispanic and male job applicants of equal employment opportunities and otherwise adversely affect their status as applicants because of their race, national origin and sex.”
A “policy guidance” page on the EEOC’s Web site explains, “the use of arrest records as an absolute bar to employment has a disparate impact on some protected groups, (so) such records alone cannot be used to routinely exclude persons from employment.” Only if the crime is “job-related and relatively recent” can a blanket ban be justified.
If you are hiring an accountant, an embezzlement conviction is probable a valid reason not to hire them. A conviction for a bar fight probably is not, nor is an embezzlement conviction for someone who will have no access to money. (Usual disclaimers: I ain’t a lawyer, contact yours for legal advice, just reporting what I’ve been told.)
The logic is, since minorities and males are more likely to commit crimes, criminal history can be used as a dirty trick to discriminate against otherwise qualified candidates. Don’t want to hire a male into your all-female office, but a male is the most qualified candidate? Check his criminal history, and refuse to hire him regardless of what the crime was or what he has done to make up for it. Since males commit more crimes than females, the odds favor your bias. But the EEOC does not.
What about increased risk to your company or workforce, both valid concerns? Two relevant statistics are bizarre in their similarity given that experts in different fields presented them. Remember that Jacob Blass reported that 93% of ethical violations are committed by people with no prior record. Earlier that same year, a column in the Raleigh News & Observer by a social work professor stated that 96% of sexual crimes are committed by first-timers. As someone said from the audience at the Blass talk, you are only increasing your risk by 7% when you hire an ex-offender.
Furthermore, Blass said, ex-offenders often are excellent workers because they are so grateful for the second chance. Logic indicates an ex-offender knows she is being watched and thus is likely to toe the line even more carefully than workers who feel more secure about their career options. A “blanket ban” on ex-criminals may well harm your company by cutting out the best possible hire without reducing your overall risk. If you consider yourself an ethical or religious person, you have plenty of other reasons to respect each individual on a case-by-case basis.
Do make the person explain their crime, when it was, what the circumstances were, and what the person has done to make up for it. Listen to the words they use, to see if they accept responsibility. Make sure the explanation matches the background check results. Consider how long ago it was, and how similar the situation was to anything they will face in your workplace. Then use your best judgment, lest even in times of worker surplus, you miss out on hiring the best team member for the job.
Update: An update to the EEOC site removed the first direct quotation above, but the principle remains in place. For example, it now states, “A policy or practice that excludes everyone with a criminal record from employment will not be job related and consistent with business necessity and therefore will violate Title VII, unless it is required by federal law.”
- The U.S. Equal Employment Opportunity Commission (1990), “Policy Guidance on the Consideration of Arrest Records in Employment Decisions under Title VII of the Civil Rights Act of 1964, as amended, 42 U.S.C. §2000e et seq. (1982).”
- The U.S. Equal Employment Opportunity Commission (2012), “Enforcement Guidance on the Consideration of Arrest and Conviction Records in Employment Decisions under Title VII of the Civil Rights Act,” <https://www.eeoc.gov/laws/guidance/enforcement-guidance-consideration-arrest-and-conviction-records-employment-decisions> [accessed 8 May 2020]
See the Full Scale agile™ site for detailed instructions on forming a new project team.