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.
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?"
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.
In his book The Difference, Scott Page showed how heterogeneous groupsteams of people who think differentlycan 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 directionthese 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
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 teamwe 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:
So what did we learn? Clearly, teams usually perform better than individualsbut 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 themthey 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.
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.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2012 ACM, Inc.
This is exactly the kind of content from CACM that I'd love to share with my colleagues, most of whom are not computer scientists, and not members of ACM. Unfortunately, it's premium content, so I can't send them a link. I think it would help to make a more general business audience aware of the breadth of CACM content to make articles like this (Business of Software) open.
I agree, content like this should be readable by non-members, so that you can share the link on Twitter or via E-Mail.
Dear Martin Remy and Michael Mayer,
You and other ACM members will soon be able to share this and other CACM articles with non-members. A "Send By Email" link will be available from the toolbar of each article on the newly revised CACM website, and the email recipient will have full-text access to the emailed article. The revised CACM website, with the "Send By Email" link and other features, will be available in beta format in the near future.
Displaying all 3 comments