A Review of Common Team Effectiveness
Techniques
July 22, 2002
Purpose
The team is an integral part of today’s software
development process. The lone-ranger coders, and single domain masters
have been retired for teams of developers, domain experts, team leads
and other software professionals. Today managers must manage the wide
range of people, personalities, work styles, age ranges, and personal
objectives that compose this work team. An integral aspect of managing
these teams is working to improve their effectiveness.
The dynamic of managing an effective team involves balancing simple and
formal psychology, effective communication, and formal measures. This
is not an easy balance to obtain, and most modern experts would agree
that training, for both the team leader, and the team members is essential
to the successes of any team. In some opinions, corporate America’s
greatest failure in effective team based project managements is hoping
that the mere creation of teams will encourage more efficient work. Many
successful team management professionals agree that deciding when to use
a team, monitoring the dynamics of that team, and training the team are
essential to promoting team effectiveness.
A Review of Common Team Effectiveness Techniques
To Team or Not to Team
The evaluation of team effectiveness must begin at the
evaluation of teams. Several noted authors and project management professionals
have asked if in fact the team is innately better than comparable individual
efforts. Polly Schneider’s, “To Team or Not to Team”
challenges the industry’s wide acceptance of teams as the fundamental
element of a project’s success. She reminds us that “the 90’s
was the decade of the team: team bonding, team empowerment, hot groups,
team bonus plans . . . “ (Schneider). Polly cautions project managers
that teams, like any solutions, are only as successful as the efforts
put in to them to make them successful. Drawing from the expertise of
leadership consultant Fritz Mehrens she
provides some basic guidelines for encouraging team effectiveness.
Despite the common focus on software project teams in almost every major
company in this country, most do not have formal or clear definitions
of what defines their teams. Based on an informal study of “more
than 350 mid-level managers and team leaders . . . the near universal
observation is that no effort was made to define how the teams should
operate, provide training in team building, or create the support structure
needed for effective team operations” (Schneider). Mehrten’s
advice is simple, “don’t use the term team lightly”
(Schneider). It is elementary that members of an organization cannot focus
around something they cannot define. How can the sense of belonging to
a team be developed, if it is not clear what the team is? Our author reminds
us, “being a team must mean something, not only to the team members,
but to everyone in the company” (Schneider).
Companies must define what it means to be a team and all of the elements
that constitute the definition of a team. This means that organizations
must define and train team leaders. As Schneider states, “a company
really can’t implement a team culture until it has trained a cadre
of team leaders “ (Schneider). The method for choosing team leaders
varies from company to company, with a general bias towards choosing the
most technically adept individual. It is true that for functional managers
and team leaders a strong understanding of the technology behind the project
is beneficial. Some experts however, claim that choosing the most technically
proficient person, as a team leader is a mistake. Most of these arguments
focus on the benefits of stronger interpersonal skills. Other psychology
professionals make arguments for specific psychological traits that will
be discussed later in this review.
For now, suffice it to say that the personality of an individual with
well honed technically skills may not be the person with the best-developed
interpersonal skills. Schneider’s article admits that even technically
qualified people with exceptional interpersonal skills often fail to comprehend
the dynamics of leading a team of diverse people”(Schneider). If
this is true there is a clear need, even among the most agile team leaders,
for training in team leadership. In the author’s words “training
in leadership is not only mandatory, but is a prerequisite for an effective
team culture” (Schneider). When that team is formed, managers should
be prepared to train the individuals in the team.
Deciding when to a form a team, if at all, is not born from a list of
hard-and fast- criteria. Merhtan does help managers by describing 5 considerations
for when to form a team. They are as follows:
[1] “Is there a defined task with a measurable
outcome?
[2] “Does the task require the collaboration of people from several
parts of the organization”?
[3] “Is the task unique (not routine)?
[4] “Is the accomplishment of the task sufficiently important to
demand the assignment of critical people?”
[5]”Does the management fully support this work?”
Not surprisingly, these are also the types of questions a project manager should be asking his or herself when undertaking any project. Consideration one roughly equates to a reasonability test of the activity to be assumed. Software project managers should always assess the reasonability of the requested activity by asking such questions as does this request constitute an actual activity or set of tasks and is there a way to know that this activity is completed. Considerations two and four are other commonly asked question by responsible project managers. These are simply questions of human resources - will I have the resources or where will I get the resources to complete these tasks. Consideration three is the least likely to be asked often by project managers. Essentially, it reads, is this the kind of activity that requires a whole team at all? Although it is an elementary question, Mehrtans admits that this question is sometimes forgotten. The final consideration, whether or not management supports the activity, is integral to many levels of a project’s development. Without support from management a project has little chance of success.
Choosing Team Members
Once the a software project manager has decided that a team is the appropriate structure for the activity they plan to undertake, they should move their focus towards choosing the best individuals to form the team. The focus should be on identifying potential team members that will promote the cohesion of the team and in evaluating the personalities and aptitudes that assure that each person is a productive, contributing member of the team (Radosevich ). In many cases the team leaders, and sometimes even project managers, do not have the opportunity to choose what members will be a part of the their team because they have inherited the team and can neither add to nor dismantle it without just cause. They can however balance the team, and assign roles and tasks that promote the health and effectiveness of team.
Team Psychological
There are several psychological approaches to improving
team effectiveness. These range from simple training sessions that remind
teams and team leaders of the fundamental individual differences in working
styles to full fledged psychological profiles. In the mid 90’s,
while American companies had charismatically embraced the team model,
there was an increase in psychology tests being used for business team
improvement. One very popular test for these uses was the Myers Briggs
Temperament Indicator (MBTI).
The Myer’s Briggs Temperament Indicator (MBTI) is based on the work
of noted psychologist, Carl Jung. Jung’s Theory of Personality Type
identified 2 major functions that people use in daily life. These were
how people perceive the world and how they make decisions. Within each
of these activities, he identified two dichotomous relationships. With
perception, people may either perceive through their senses or through
intuition. With decision-making, people are apt to use either objective
logic or subjective feelings. Jung did not believe that these tendencies
were absolute. He theorized that there was simply a rank order tendency
innate to personalities that preferred one decision-making or perception
characteristic over the other.
The Myer’s-Briggs mother daughter team added the axis of judging
and perceiving to Jung’s work, and created the temperament indicator.
This temperament indicator is simply a test to identify personality types.
It helps individuals identify how they gain their flow of energy (inward
reflection or outward interaction with people), how they take in information
(through sensing the environment or through gut-reaction), how they preferred
to make decisions (through logic or through emotion), and the lifestyle
that they prefer (through evaluation or perception). A test taker is provided
a score that reflects their tendency towards extroversion (E) or introversion
(I), sensing (S) or intuition (N), thinking (T) or feeling (F), judging
(J) or perceiving (P) respectively.
In a feature article from 1995, CIO magazine’s staff writers covered
the then growing use of the MBTI. They claimed, “leading edge business
managers are turning to personality indicators such as the Myers-Briggs
test to boost the success rate of team-led projects” (CIO). The
benefits include diagnosing potential team conflicts and balancing personalities
to encourage the team’s success. CIO reminds us that “executives
can use the Myers-Briggs to create a team with a balanced ratio of personality
types necessary to reach the project’s objectives, or they can examine
how different personalities are going to interact” (CIO).
Even then these practices did not get full support in project management
circles. The writers warn us that “quantitative business types may
be tempted to dismiss MBTI as so much unsubstantiated bushwah” (CIO)
but that the test is backed by the center for applications of Psychological
Type. This center owns more than 230,000 personality profiles and has
even helped to reveal the proliferation of certain personalities in Information
Technology. According to the article and other sources the introverted,
intuition and thinking based personalities are most common in information
systems. The article sites one study done by the Journal of Psychological
Type that “examined the IS department of a NASA contractor [that]
found that the three most prevalent types were ISTJ, INTP, and INTJ”
(CIO). The tendency towards introversion especially can produce problems
in teams, as the “preference of many computer professionals can
be almost diametrically opposed from . . . your average Joe in marketing”
(CIO). While people in marketing may have a strong tendency toward extroversion,
which makes them good at interacting with customers and asking questions,
good developers tend to try to solve the problem internally, without looking
for other opinions. Besides this likely conflict the “preponderance
of introverts in one department can make it harder for that group to focus
outward.” According to the MBTI, the personality that makes a good
software developer, is invariably the personality that makes a bad requirements
gatherer, usability analyst, or in extreme cases, team member. The introverted
personality simply does not encourage outward communication, and as often
identified, this type of communication is essential to effective teams.
CIO goes as far as to warn that introverted thinkers, the majority of
personalities in IT , “‘believe that they’re right so
much that it’s hard for them to draw in the perspectives of other
people’” (CIO).
Troubleshooting Team Effectiveness
If the Myers-Briggs helps to build an effective team,
but it lacks the ability to troubleshoot a team other than removing or
restructuring the problem members of a group. David Van De Voort an Information
technology workforce effectiveness consultant provides us with some simple
to follow guidelines for increasing troubleshooting and improving team
effectiveness. His four simple points are “avoid basic teamwork
obstacles, ” “recognize real differences,” “ create
team identity,” and “make group dynamics everyone’s
responsibility” (Voort).
Voort asserts that the basic detriments to team success are “unclear
goals, changing objectives, lack of management support for the team’s
assignment or the team, and ambiguous or undefined roles of team members.”
Voort’s concerns match those of Mehrtans. In particular, Mehrtans
and Voort both believe that clear goals and objectives are as important
as management’s support of the team or team goals. Once again we
return to the fundamental concerns that all project managers should be
aware of, not only for managing team effectiveness, but for the general
project health. He claims “team leaders must continuously reinforce
and clarify the mission of the group, challenge and validate attempts
to change that mission and regularly solicit management reaffirmation
of the purpose, value, and performance of the team” (Voort). These
should be familiar efforts to a successful project manager or team leader.
Volt’s second principle, “recognizing real differences,”
has resonance of other suggestions made earlier in this paper. Voort suggests
that “the IT professionals and the business process subject matter
experts have different education, work, experience, jargon, maybe different
values and many different perspectives on what makes a good system”
(Voort). These are issues addressed by managing the group dynamic, and
being responsive to the diverse needs of the team’s individuals.
As discussed, the MBTI is one formal means for discovering some of these
differences.
The second half of Voort’s recommendations for realizing differences
is arguable. He suggests, “by providing an easy to use non threatening
phrase, conflicts can be identified and dealt with before conflict escalates
and resolutions becomes more difficult” (Voort). The hope is that
by disarming strong rhetoric from team member’s language, they can
feel more comfortable communicating their concerns. He advises team leaders
to “make it OK to talk about differences and conflict” (Voort).
The general effort to focus on increasing communication and to make sure
“regular feedback is occurring” (Voort), is clearly less objectionable
than his ancillary notion that team leaders should use new language to
describe conflict. One might argue that by changing the language you are
changing the meaning. If a team member is aware of a legitimate problem,
communicating it as Voort suggests, as a “pinch,” does not
allow the person communicating to express the severity of their concern.
By turning the language into softer, less austere language, it either
elevates the level of meaning or deteriorates the effectiveness of the
general communication. If for example, pinch replaces problem, because
“a pinch is not yet pain” (Voort), what language will one
use to communicate something that is not yet pain? More importantly, why
should anyone have to waste the time and effort to establish an entire
lexical standard for intra-team communication, when there is already a
universal standard, namely, the language, that the team speaks (e.g. English
in an English speaking company).
Voort further emphasize the adoption of team-specific language as part
of his suggestion to “create team identity” (Voort). He recommends
developing “team speak” because “team-speak becomes
a powerful connector for the team” (Voort). Based on some linguistic
philosophy, his assertion is accurate. Languages do promote a sense of
community among its speakers. But languages may also isolate non-speakers.
The team-speak may isolate the team from the rest of the organization
and may make it difficult for new team members to assimilate into this
factioned team. The team-speak approach seems advisable for short term
increases in effectiveness, but it may be at the detriment of the entire
organization.
Voort’s final suggestion, to “make group dynamics everyone’s
responsibility” also raises some questions. His suggestion is simply
to “establish permission (a group norm) to observe and comment on
group process” (Voort). This in itself a reasonable request, but
in practice this may be too idealistic. As Jane Linder, a senior analysts
of leadership strategies at Forrester Research, “’someone
has to stand up and say, “we’re going this way not that’”(GLASSER).
While feedback on the group process is important, it is equally important
to manage through group and to make sure that team members are being honest,
fair, and non-competitive in their assessments of the process and individual
team member efforts.
One final suggestion that several experts have made is always be conscious
of the psychological affects of groupthink. Groupthink is the kind of
decision-making by a team or group that is characterized by non-critical
acceptance to the group’s prevailing point of view. It is a type
of conformity that typically occurs when groups work for too long, too
closely, and are bound to creating one common solution. Groupthink may
even create a solution that no single person in the group would ever champion.
Glassser reminds us to “consider how groupthink can stifle individual
initiative” (Glasser). In a somewhat clever metaphor he says, “never
forget that the herd instinct can also lead cattle to stampede”
(Glassed). More simply, be aware the affect of team work is having on
your individual employees and their productivity. It may become detrimental
to the team’s effectiveness and contribution to the organizations.
Real World Expertise
In an interview with Washington Technology, Mike Hughes, a Naval trainer who does consulting for companies like Electronic Data Systems Corp, discussed some team effectiveness enhancing techniques. When asked what the keys to helping employees set and reach their goals were he claims “they have to set them with guidance” (Washington). He says “when I have my team set a goal I ask them what they want to achieve” then he “tell[s] them what we have to do to achieve it” (Washington). He suggests a cooperative, self built approach, when “I’m in a business and we want to achieve a certain amount of sales, and we’ve decided this is how much activity we have to have to produce . . . then you are producing the activity to create the sales rather than the boss making me do it” (Washington). His theory is simply that ”the people are doing it because they have ownership” (Washington).
Conclusion
Managing and promoting team effectiveness cannot
be adequately explained in a few thousand words. It takes a myriad of
diverse skills ranging from the psychosocial to the creative. Teams require
more than the standard business practices. They require attention to the
needs and personalities of each of the individuals in the team. They also
require attentive monitoring to make sure that the group is being productive
and does not fall prey to the usual pitfalls of group activity. Several
experts have offered their opinions based on experience and research,
but ultimately there is no single prescription that will cure a team of
ineffectiveness, nor assure effectiveness. Managers should be aware that
although teams are part of the prevalent software management practice,
they are no silver bullets. The fundamental management concerns remain
the foundation for healthy project development.
Once the fundamentals have been covered, managers would be wise to consider
whether or not the creating a team is the right solution for their needs.
If so, training in team workshops and, for team leaders, leadership development
will greatly ease the movement into new or existing teams. When problems
do occur in the team it’s a good idea to look at the psychology
of the team to make sure that there aren’t personality conflicts
or other rot that may be deteriorate the team from the inside. Sometimes,
simply encouraging the team to act more as team, by inspiring a sense
of community may increase the effectiveness of the team. If the team will
be working for an extended amount of time, consider psychological profiling,
or other more formal methods to substantiate your decisions to form a
team of specific individuals. Profiling may also help insure a successful
mix of personalities. In all, the most important focus should be on making
sure that the team is more effective than the sum of it’s individual
members.
References:
Glasssr, Perry. “Go Team?” CIO Magazine.
June 15, 1998
www.cio.com/archive/enterprise/061598_reality_content.html?printversion=yes
Schneider, Polly. “To Team or Not To Team?”
CIO Magazine. March, 13, 2000
www.cio.com/leadership/edit/031300_team.html
Staff. “I’m OK, You’re Really Weird”
CIO Magazine. October 1, 1995
www.cio.com/archive/rc_manag_content.html?printversion=yes
Staff. “Perspectives from the field”.
Washington Technology. July 1, 2002
www.washingtontechnology.com/cgi-bin/udt/im.display.printable?client.id=wtonline
Radosevich, Lynda. “Team Spirit”. October,
1 1998.
www.cio.com/archive/100198_virtual_content.html?printversion=yes
Voort, David Van De. “Ask the Source:
Question” CIO Magazine. July, 10, 2002
www2.cio.com/ask/source/2002/questions/question1514.html?expert=124