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.
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
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
a These are some of the ways of approaching
problems described by Edward DeBono in Six
Thinking Hats: An Essential Approach to Business Management. Little, Brown and Co., New
York, N Y, 1985.
Getting the ideas
is a good thing
but actually using
to create solutions
is a better thing.
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
˲ ˲ One team achieved an almost per-
fect score. When we looked at the com-
position of this team, we found it was
the only one that did not consist entire-
ly of engineering managers. In fact, it
included the general manager, his ad-
ministrative 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 engi-
neer, or a manager.
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
And a jolly good one he was too.
1. gardner, h. Frames of Mind: The Theory of Multiple
Intelligences. basic books, new york, ny, 1983.
2. Page, s.e. The Difference. Princeton university Press,
Princeton, nj, 2007.
Phillip G. Armour ( firstname.lastname@example.org) is a senior
consultant at Corvus International Inc., deer Park, Il,
and a consultant at QsM Inc., Mclean, va.