Mike ran his fingers through his slightly unruly hair and straightened his tie one last time. At the secretary’s nod he took a deep breath, pushed the door open, and stepped into his first interview since graduating from college.
Mike’s interview
There were four people at a long table. "Come in Mr. McGinley, please sit down" one of them said, gesturing to the chair across the table. Mike settled in and tried to present a confident air. "Well, Mr. McGinley," said the man directly across from him touching his fingertips together and leaning back "…could you start by telling us why you want to become a computer systems analyst?" Mike was nonplussed. "Uh, what’s a ‘computer systems analyst’?" he asked after a moment. His questioner’s eyebrows raised and he glanced to the left and right at his fellow interviewers. "Why, it’s the job you have applied for. It’s the job you think your degree in applied mathematics qualifies you for." he said. "No, I applied for a job in Marketing," said Mike, "…and my degree is in anthropology."
The best problem solvers tend to operate in similar ways, so there is little benefit in having more than one of them.
There was a brief flurry of activity on the other side of the table as the panel quickly reread Mike’s application. "Well, it seems you have been sent to the wrong interview," one of them said, "…please excuse us for a moment." The four of them conferred for a few minutes in tones too quiet for Mike to hear. The lead interviewer cleared his throat and said, "Well, would you like to become a computer systems analyst?"
No Computer Qualifications
This scene occurred in the North of England in the early 1970s. Britain’s national steel company had initiated a rapid hiring program to staff up its computer departments. They had seen how computers were going to change the industry and needed people with the skills to program them. The trouble was universities were not turning out computer scientists and engineers. There were almost no courses or degrees in computers at the time, certainly not enough to satisfy the burgeoning demand. So the company was hiring people with chemistry and math backgrounds. The company was hiring mechanical and metallurgical engineers. They were hiring all kinds of people and this was not necessarily a bad thing.
Difference
In his book The Difference, Scott Page showed how heterogeneous groups—teams of people who think differently—can outperform teams of like-minded people.2 In fact he showed in some of his experiments that groups composed of highly (but similarly) skilled agents often perform worse than teams of less skilled, but more diverse, thinking people. As Page provocatively asserts: diversity trumps ability.
The reason is quite straightforward: the best problem solvers tend to operate in similar ways, so there is little benefit in having more than one of them. Diverse thinkers, however, may see the same problem from different perspectives and can create more optimal hybrid solutions out of these viewpoints.
Getting the ideas is a good thing but actually using those viewpoints to create solutions is a better thing.
Other researchers have noted this. One person on a team might have better spatial processing while another processes information from a linguistic, or a logical-mathematical direction—these three approaches being examples of the different kinds of thinking outlined in Howard Gardner’s theory of "Multiple Intelligences".1 Apart from the modality of understanding, described by Gardner, each of us might approach a problem from a different direction. One person might look at a problem and mostly see all the challenges and difficulties that could arise (an all-too-common engineering disease unfortunately). Someone else looking at the same problem may see the possibilities and rewards. Yet another may rely on intuitive gut feel whereas his colleague may simply absorb and process the information as is, without feeling the need to express her judgment at all.a
An Experiment
Some years ago my wife (a psychologist) and I conducted an experiment on 75 engineering executives and managers at a large telecommunications company. We first gave each person a set of deductive reasoning problems to solve and collected the results. Then we divided the group into 15 teams of five people and conducted some team development activities with them. Following this, we gave each team the same tasks they had completed as individuals but this time asked them to solve the problems as a team. Once the teams had finished, but before analyzing the individual and team results, we polled each team on a number of attributes related to their performance as a team—we essentially asked them to rate themselves as to how effective they thought they were. Then we compiled the results and presented our findings. They were quite interesting:
- Most teams not only outperformed the average of their individual scores, they outperformed the best individual score on that team. This is a common finding in team development programs.
- However, a few teams actually scored worse as a team than they had as individuals. Two teams scored much lower, lower even than their lowest individual score.
- When comparing their self-report of team effectiveness against their actual performance we found that those teams that reported lower effectiveness did, in fact, have lower effectiveness. Of the teams that self-reported high effectiveness, however, some were high performance and some were decidedly not.
- One team achieved an almost perfect score. When we looked at the composition of this team, we found it was the only one that did not consist entirely of engineering managers. In fact, it included the general manager, his administrative assistant, and one of the non-technical support staff. And when we looked at the strategy this team used to solve the problem it transpired that it was the administrative assistant who suggested the approach that allowed the team an almost perfect score. To the team’s credit, they embraced and built on the ideas even though they did not come from an executive, an engineer, or a manager.
Team Engine
So what did we learn? Clearly, teams usually perform better than individuals—but we already knew that. Secondly, sufficiently bad teams can make things even worse than the worst solution from one person. Thirdly, if a team reports it is not working well, you can trust them—they really are not working well. But if a team says they are great they might be so bad they don’t even know how bad they are. In this case you will have to look at the results they are getting (or not getting). Lastly, getting ideas from other viewpoints is a really good thing, even if the ideas come from people whose skills lie in different areas and whose "status" might be lower.
Getting the ideas is a good thing but actually using those viewpoints to create solutions is a better thing. This does, however, require acceptance and understanding of different perspectives.
Scott Page shows that we might be getting less than optimal results in the business of software if we focus only on technical skills and engineering or IT viewpoints and that it would be helpful to intentionally bring in different skills and perspectives. And learn how to use them, of course.
Mike’s Interview Redux
The remainder of Mike McGinley’s interview for the job of computer systems analyst consisted mostly of the interview panel carefully but enthusiastically explaining to him what the role would involve and trying to convince Mike that he should consider it. They did a good job. Mike was quite intrigued and graciously accepted the position, even though his degree was not on the list of prerequisites. And so an anthropologist became a computer systems analyst.
And a jolly good one he was too.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment