Download - Stop look and listen before you talk
Stop, Look and Listen before you talk
Nuno Brito
Universidade de Coimbra / Carnegie Mellon University
Abstract
In software development, people focus on reaching a
solution to a given problem. In software engineering,
before focusing on a solution, people focus on knowing
the real problems and consider them prior to decide on
a solution approach.
In this paper we approach the communication side of
software engineering. A characteristic that is difficult
to control, evaluate or quantify. Yet, communication is
a fundamental factor in the outcome of a project that is
often overlooked and becomes a secondary priority.
We consider a good communication practice to exist
when it becomes a productive tool for the team. This is
only possible when we are capable of looking upon our
own behavior and understand how it affects the
behavior of others in the team.
Therefore, the goal of this paper is to reflect how a
healthy communication should be encouraged since
day one, starting with yourself to set the example for
others.
Acronyms
MSE – Master of Software Engineering
CMU – Carnegie Mellon University
UC – University of Coimbra
Preface
In this paper we use as example the aftermath analysis
of a Master of Software Engineering Studio Project in
the 2009/2010 CMU|Portugal program. The Studio
project is a software development project developed
within an academic environment that lasts 16 months.
Studio projects pass through all lifecycle phases of a
typical software development. The goal of this project
is to let students experience in first hand the hardships
of a professional environment that can be inspected
within an academic context. The project is developed
under the constraints caused by an intense workload
derived from other classes at each semester.
Recognizing and evaluating the consequences of these
hardships matches the intention of the CMU program
that encourages teams to solve hardships after
following a careful reflection of the available resources
and goals to be reached.
Since the inception of a project until its delivery to the
client, we, as a studio project team use the present
paper to reflect and present a lesson we consider as
relevant to raise awareness.
Introduction
For the author, one of the most important lessons to be
kept for future reference is the care for upholding an
efficient process of communication throughout the
project development.
This aspect of human interaction is nowhere simple to
place under a microscope for analysis. Albeit aware of
this fact, I will nevertheless try to document on this
paper some of the lessons that we, as a team, have
learned through our own journey during the Studio
project. Some of these lessons have helped us to avoid
communication issues with potential of escalating onto
a level of personal conflict between our team, and it is
my best hope that this paper can help other teams in the
future to recognize the importance of communication
earlier in advance.
Despite our attempts of different strategies and adopted
processes across each of the semesters in the MSE
program, we observed recurring communication issues
within team elements as time passed. As a result from
these observations, I will discuss some of the types of
communication issues that were noted to occur with
more frequency within our team, while also proposing
some hints for future MSE students to keep in mind
across their own path on this road.
We use a Studio project as example of a real situation
where communication issues causes impact on team
productivity since the work and pressure demonstrated
during the project development are real manifestations
of human nature that occur when a person is faced with
situations of conflicting interests and strict deadlines to
meet.
Across this project, one of the most interesting details
was the fact that regardless of the adopted techniques
to solve some of the problems that were occurring, we
admittedly fell into the trap of pursuing a solution for
the symptoms of the illness, instead of treating the
illness itself.
For example, if our proposed work items started to get
behind schedule, we’d likely worry more about
working additional hours to balance the delay than
actually understanding the reason with the delays were
occurring in the first place. This is an example, as there
was indeed a process to evaluate what went wrong with
estimation of work after looking at the results from
effective work.
However, when we look at possible causes, the lack of
efficient communication is rarely seen as the culprit.
Yet, as evidences piled up, we came to agree that we
also needed to address this problem before it caused
further damage to our project and to ourselves.
We will focus on the following themes:
1. How people are
a. Behavior styles
b. Influence of size
2. What can go wrong
a. Miscommunication
b. Conflictive communication
3. How can we avoid it?
a. Communication cues
b. Cooperative communication
There is no one-size-fits-all type of shoe to cover all
the possible issues to which a team might be exposed
during interaction between team elements.
Often, we can to some extent discuss some of the keys
details that are relevant to be alert in order to prevent
issues of relatively small dimension from escalating
onto harsh personal conflict between team members.
The intended audience of this paper are future MSE
students and also development teams interested in
gathering an informed idea of the possible road(blocks)
ahead, raising awareness to communication issues as a
factor in team dynamics that should not be neglected.
1. How people are
While looking back to our team elements personality
and reflecting in the manner how it has impacted of
development process then it becomes a valuable
exercise to evaluate the conditions that have lead us
onto disruptive situations of communication issues in
the first place. Therefore, we can safely assume to
some extent that our team conflicts were directly
conditioned by our particular personality styles while
interacting as a team.
A persistent and durable factor in a team is personality,
a human characteristic that is built across each person’s
life. The Oregon State University [6] defines it as:
“personal beliefs, expectations, desires, values, and
behaviors that derive from the interaction between
culture and the individual. Personality is the behaviors
and techniques for solving problems that are used by
an individual. Personality is to the individual as
culture is to the group”. From this sentence alone we
can deduct how different personalities will lead from
the start of their interaction to different decisions
during team dynamics across the development of a
project.
We can even risk stating that personality is also built
using professional and personal experience gathered
from the past. So, whenever working with a team it is
important to take into account the inherent personality
style of each team member in order to forecast with
some level of accuracy the chances that a team will be
capable of working together and reach the intended
goals as planned.
Across our project, we found particularly interesting to
look upon our behavior style as a factor that influenced
the communication flow between ourselves.
In extreme cases, some members depicted a seemingly
more aggressive behavior during meetings while other
would depict a more passive approach. One of our first
errors noted across the first semester was overlooking
some of the indicators at our reach that predicted with
some accuracy how behavior styles could clash during
the intense phases of software development.
1. 1. Behavior styles
Since the beginning of the Studio project, we have
categorized the type of individual personality using a
method entitled as the “platinum rule” [1]. The goal of
this rule is to help others understand in a concise
manner the type of personality to which a given person
is more inclined. Albeit at the beginning its potential
was not entirely clear, as time moved on we’ve began
understanding how these categories would fit with
relative accuracy onto the behavior profile of the
people in our team.
Platinum rule
This rule helped our team understand the weight that
personality affects the communication paths between
us. It is helpful when used to categorize each team
member by placing that person inside the context of a
quadrant and gather a more clear notion of the aspects
of human behavior that they will typically value the
most.
There exist four distinct behavior types in this rule:
Relater
Thinker
Socializer
Director
We cover with more details each type of behavior at
appendix A of the present paper.
One should also note that different contexts will often
lead to different types of behavior on the same person.
In fact, the same person might even share evidences of
a secondary behavior type at the same context while he
also demonstrates a predominant type across most of
his interactions with other team elements throughout
the development of the team project.
For the purpose of this paper we assume exclusively
the professional work context for the development of
our studio project to analyze the behavioral style.
Studio project individual results
Our studio project team counted with 6 elements that
we designate as: A, B, C, D, E and F.
Categorizing their behavioral styles as predominant and
secondary, we see them distributed as noted on table 1.
Team member Predominant Secondary
A Socializer Director
B Director Socializer
C Relater Thinker
D Socializer Thinker
E Socializer Director
F Thinker Relater Table 1 – Behavior types of team members
Given this categorization, we now proceed to a listing
of each team member preferred communication style
according the types defined by Christopher L. Heffner
that categorizes communication styles as aggressive,
passive and a mix of both as passive-aggressive.
The results for each element on the team using the
same A, B, C, D, E, F designation can be viewed on
table 2.
Team member Communication style
A Aggressive
B Aggressive
C Passive
D Passive-aggressive
E Passive-aggressive
F Passive Table 2 – Communication styles of team members
Using this data and also the experience gathered across
all the semesters of the Studio project, I would state
that from a perspective of communication, our team
tended to balance on a level of passive-aggressiveness
style of interaction.
This tendency on the style of communication leads to
avoidance of solving critical matters in a direct fashion,
and this tendency caused indeed our team to languish
across a series of smaller conflicts, clear symptoms of
the unresolved issues that we didn’t wanted to address.
Using the platinum rule to position people inside a
given communication style could have served as a flag
to avoid possible conflicts of this kind, however, we
were still inexperienced on personality categorization
during the first semesters and trusted our own instincts
and past experience to work and interact as a team.
Looking back to the point when we started to work on
this project and to know each other in the team, I note
that an informed team manager could have used this
type of information to raise awareness of the role that
each team member would potentially feel inclined in
assuming during team interactions, while also serving
to pinpoint possible personality clashes between team
elements.
However, human nature tends to raise communication
conflicts without notice and therefore does not exists a
fail proof way of preventing clashes from occurring.
In either case, having this type of information available
at hand remained as an accurate indicator to predict
how communication could occur since it also applied to
our team as we observed across the months to come.
This type of tool becomes particularly more valuable
when the available sources of information are scarce
and the team is assembled together without prior
contact in past projects.
I have also found it useful for a post mortem reflection
such as the case of this paper, where we can look back
and analyze how some of the predicted actions have
triggered positive or negative aspects of interactions
prescribed by the platinum rule.
Given the context of the MSE environment, teams are
assembled from the pool of available students on each
course year. In most cases there exists no prior relation
between team elements, except perhaps for the fact that
elements deriving from the same company are often
positioned inside the same team in case the studio
project is also intended for use at their company.
Under these conditions, teams were gathered in regard
of the company to which students belong, so we can
state to some extent that avoiding possible personality
conflicts is not a factor taken into consideration on this
process of team assembling.
A possible cause for this fact is also driven by the
reason that scarce information exists about students and
their personality traits prior to the enrollment on the
MSE program,. Team elements are expected to also
maintain a civilized behavior when working in the
context of a software development project.
Albeit in most situations the team dynamics will flow
with occasional conflicts that are solved with success,
we can also note that per times the personality style of
elements inside the team will fuel a dysfunctional team
onto a series of dramatic conflicts as documented on
the MSE Chronos team [8] during the 2008/2009 years.
Therefore, the process of assembling a given team in
the context of the Studio project is meant not only to
deliver an end product to the client but also to become
a learning experience where a team becomes exposed
to adverse conditions, confronted with the challenge of
solving these situations under an academic context.
There is a clear co-relation between the size of the team
and the quality of how communication will flow
between elements. This quality is directly driven by the
behavior styles and over the next sections I’ll describe
our experience on this regard while also reflecting on
what could have been done to prevent some issues from
occurring.
1. 2. Influence of size
If we understand communication as the process of
sharing information between several elements on the
same network, then we can apply Metcalfe's Law [4].
Metcalfe observed in 1980 that "the value of a
communication system grows at approximately the
square of the number of users of the system".
When mapping this concept to the context of a team of
software developers, we observe that communication
will indeed flow with better quality on smaller teams
rather than large teams.
Throughout some of the literature related to software
practices from authors of 37signals [5] and Brooks [9],
it seems common to find reports that whenever
increasing the number of people inside a team to sizes
bigger than three, we also begin observing a lowering
curve in terms of efficiency at the communication paths
between them.
Albeit common sense might depict that doubling the
number of people doubles communication inefficiency,
doubling the number of people raises the inefficiency
of communication at an exponential rate.
The common solution at sight is the adoption of formal
methods for communication. One such measure is the
scheduling of multiple meetings across the week along
with formal reports. This is a way for managers to keep
track on the team progress and also share information
across all team members.
On this case, I’ve found interesting to read how some
of the problems exposed by 37signals [5] are avoided
at smaller teams, to an extreme point when these small
teams become capable of being just as productive as
large teams. It is interesting to look at communication
characteristics that deteriorate as size increases:
Less communication between team members
Overhead becomes a necessary evil to share
information; formal meetings and reports will
require more time to be produced and digested
High traffic of email between multiple parts
causes the team to lose track of discussions
Not all members will be aware of the team’s
direction and current progress on the project
Consensus becomes difficult if not impossible
to reach during group meetings
Not all opinions are considered, lowering the
motivation of team members
Before composing a software development team, these
conditions should be given focus. It becomes necessary
to take into consideration that efficient results are only
achieved when a team manager becomes aware that the
communication process need to be adjusted to the team
size and work culture.
In the case of our studio team project, I’d risk stating
that our team sized in six elements was slightly above
the ideal dimensions for the project at hand.
Across development, at one point was noted that each
team member should devote 12 hours per week to the
studio project and that not all members would fill this
time slot appropriately.
Using the same line of reasoning, one might note that
filling a given number of hours just for the sake of
appearing busy is also not an indicator of productivity.
But if we have elements with extra time that is not used
for the studio project then it clearly indicates that our
resources were used inefficiently and that a smaller
team could indeed achieve similar results, lowering the
costs on the pocket of our project stakeholders if we
were placed under a strictly professional context.
Nevertheless, I am also inclined to believe that not all
hours were used efficiently due to other factors as well.
One of the most relevant factors causing this condition
was the difficulty in sharing information between team
elements.
Our communication process was not efficient and thus,
the team productivity became efficient. To understand
the causes of this problem, it is also becomes necessary
to look on the communication cues between the team
elements and observe the different types that exist.
2. What can go wrong
A paradigm observed across the MSE program is that
our project mentors and professors often ask: “why?”.
This is a valid question and always assumes a critical
relevance when it is placed on the context of a public
presentation of the project where we need to justify the
decisions that were made.
It can be also be found applied to cases where a person
presents a course of action and is faced with the need
of thinking ahead on the consequences of this choice.
So, whenever a person is faced with such question, an
internal process of reasoning is built on measurable
facts and proper reflection, or otherwise the person in
question will risk that his line of thought fails to
convince the audience that is hearing his explanation.
All of this serves the purpose of explaining that we, as
elements inside a team should interiorize this particular
question across all development phases of our work,
and be prepared to answer it when necessary.
However, after passing 18 months inside a team in the
context of a Studio project, I noticed that “why?” was
seldom a time asked aloud during our team meetings.
In contrast, the more frequent question that we found
ourselves asking was “what went wrong?”. In turn, this
question would trigger our team to quickly point blame
onto other team members when a result wouldn’t match
out as originally expected, instead of leading to a
productive course of action.
So, I observe that from the point in time when our team
no longer felt comfortable asking the question “why?”
to other members without fear of repercussions, it has
also exposed a very clear symptom that communication
problems existed in our team and that something ought
have been made to address them.
As reflection on the outcomes from this behavior, it is
fair to say that our team became exposed to unforeseen
consequences if the “why” question was not answered
or justified properly with a realistic perspective.
Ignoring to perform the “why” process inside our own
team led to decisions being made across our project
that went wrong without being properly dealt and
discussed when they were first proposed.
This type of episode assumed particular relevance on
the discussion of approaches for the user interface on
our project. A solution involving a technology that no
team element had previous experience was assumed as
the only approach and no alternatives were defined, nor
a realistic way of measuring results was established
internally.
This eventually forced us to drop interface support on
the fourth semester when several obstacles on its
implementation have depleted all the resources
available to this component.
In our case, not asking the “why” question has brought
us several episodes of miscommunication and episodes
of conflictive communication between team members
when we become faced with these problems. These
were some of details about our project that went wrong
and that we will discuss over the next chapter.
2. 1. Miscommunication
Miscommunication inside a team occurs whenever the
communication paths are not efficient. This event is
influenced by factors such as the behavioral styles of
each person and also by the context and team size as
seen on previous sections.
Over this chapter we focus on the cases noted on our
team when two or more team elements engaged into a
discussion or when some of involved parties would
believe to be discussing a topic on the same context
while each of them held a different idea of what was
being discussed.
Despite our efforts to prevent miscommunication from
re-occurring, in reality, this issue would remain visible
across all development phases. Upon closer inspection,
it was noted more often across:
Email messages
Live meetings
Remote meetings
Email messages
During the first semester, email messages were without
doubt the most relevant way for passing information in
asynchronous manner across team members. However,
we can also state with due fairness that this means of
communication quickly become an ineffective tool.
The main reason is the fact that all team members were
often engaged into time consuming tasks such as the
other classes on the program. These classes would
often compete for the attention of the studio project
tasks and caused studio project messages to be left on
the inbox of the recipients amongst all other messages
from other classes, where they would also compete for
attention. Noting that our inbox would receive a large
number of messages, we noticed how often studio
messages could pass unnoticed or not replied by other
team elements when feedback was necessary.
Looking in retrospective, I would line up the factors
that that turned the use of email as a communication
method into an inefficient tool:
Large number of messages from the Studio
team were exchanged on daily basis, keeping
ongoing topics hard to distinguish and track
Difficulty in backtracking the discussed topics
on previous emails
Difficulty in remembering emails for plans set
on a timeline farther than the current week
Other classes generated a significant number
of daily messages; on average, around 50 new
messages would arrive per day on the inbox at
some point during the program.
As an attempt to give priority to studio, team
messages were marked as “[urgent]” on the
subject line, however, this technique became
used so often that it also began being ignored
Emails messages were occasionally not sent to
all team elements either by human mistake or
ISP spam email filtering.
Not all team members acknowledged when
they had read a given message; causing the
message to be left without feedback regarding
the approval or denial of a given topic.
Email messages toke a toll on time required to
reach a decision, if a deadline for reply was
set, then it would often be forgotten
Some team members did not felt comfortable
exchanging messages in English language as
previously agreed; in fact, some weren’t even
comfortable in email use, preferring to discuss
matters strictly in live presence.
All of these factors demonstrated how our team had
serious communication issues. This fact became felt
with relevance on the case of email messages when
there was the upmost need of relying on this method to
solve a work item and it did not provided a solution.
As a consequence, despite the fact that we already had
a tight schedule to meet our multiple work tasks, we
still required several live meetings across the week to
ensure that some work items, which could otherwise
have been discussed using email, were properly dealt
with.
This only confirms what was demonstrated empirically
on the “Rapid Software Development through Team
Collocation” paper research [3], stating that offline
communication is susceptible of causing breakdowns
that eventually result in schedule delay and added costs
to the overall development effort.
Live meetings
One would naturally expect that holding a meeting in
live person could provide us the decisions that were
necessary, since some of our team elements preferred
to discuss them in live presence rather by email.
However, a live presence would gave wave to engage
into a type of discussion that would also fail in bringing
an effective set of results for involved parties.
Mostly across the first semester and to lesser extent on
the second semester, we would often note that
whenever holding a meeting with the duration of one or
two hours, it would instead require several hours that
would move well into later hours in the night without
hope of reaching a reasonable team consensus.
There were cases where even after resorting to a team
voting regarding a given matter and the majority of the
team had voted in one direction, we’d note that this
voting would not be respected and discussion would
continue until one of the sides gave in.
Failing to achieve a cooperative mentality from all
involved parts in the meeting or even agreeing to use a
mediator to enforce the rules for participation, we set
out the ground conditions to frustrate our efforts of
working together towards a collective goal and reach a
win-win situation rather than a frequent win-lose state
as also mentioned by Tjosvold [11].
I will not claim that all of our meetings reached an
extreme point of polarized discussions as mentioned
above, however, given the frequency of unproductive
meetings to reoccur across the first and the second
semester, we have (accidentally) discovered remote
meetings as a way of circumventing the live presence
deadlocks that we had encountered in the past.
Remote meetings
To perform our remote meetings, we would often use
Skype (a remote conference software application). This
type of use started during the second semester while
studying in Pittsburgh, USA.
At the time, Skype appeared as a valuable tool due to
the weather conditions that brought intense snow and
forced team members to stay at their home, instead of
holding our meetings as usual inside a closed room.
During the first remote meetings, the general feeling
when compared to live presence meetings is that our
focus to stay on topic in a succinct manner had been
greatly improved.
Unlike initial concerns regarding a remote meeting, our
team was getting better results when compared to live
presence meetings because:
Meeting agenda was followed within the
allocated time slots
Participation was noticeably more balanced
between all members instead of polarized
Writing text on the chat window allowed to
decide on action items, avoiding ambiguities
A general sense of consensus on the decisions
that were made became frequent.
The fact is that using Skype for remote meetings would
not be better than live presence if our live meetings had
been performed in a truly effective manner in the first
place, but in overall it was better that we could indeed
be productive even if meeting remotely than not, and
this was seen as a benefic approach.
This situation brought further emphasis to the fact that
existed miscommunication between ourselves. Albeit
all team elements had experience working as part of a
team, it was also expected that certain types of
unproductive behaviors should not be found but yet
existed even if unsolved. When reflecting upon this
clear contrast of productivity between remote meetings
and meetings held in live presence, most of the team
agreed that we were:
Often losing focus on the action items that
should be discussed and diverting attention to
items not covered in the agenda
Ignoring allocated time for each action item,
causing the meeting to last far longer than
initially prepared
Adopting a competitive style of participation
between two or three elements where it
seemed that the objective was winning a fight
and prove dominance over the group decision
So, albeit during the second semester it is possible to
state that Skype meetings helped all team members to
be aware of the problems present while meeting in live
presence, I should also note that we experienced the
negative factors from using remote conference as our
regular meeting method during the third semester that
we will now detail.
During the third semester of our Studio project, we had
decided to work non-collocated with all team members
scattered across a significant geographical distance.
Given our experience from the second semester, one
could reckon that our expectations for the remote
meetings would remain efficient as seen on previous
semesters.
While one can note that this fact was true during the
initial development weeks, we also gradually began to
note how several negative behaviors and aspects began
to occur more frequently:
Team members would sometimes forget about
the scheduled time to be online and wouldn’t
be available to participate in group meetings
The Internet connection and location from
where the team members would participate on
the meeting was often not consistent, causing
difficulty to listen or even talk due to the
background noise
Since we can only hear the voice of the other
team members and not see them, it would
often be noted that some elements were not
focused on the meeting
Per times, team members abandoned a team
meeting without notice to pursue other tasks;
for example, there were occasions when a
given team element would either go to the
bathroom or started to cook something while
the meeting was running, causing discomfort
between other participants
Ignoring email or skype messages of other
team members; unlike a live presence where
we can meet the person in face and request
help, over skype it was relatively common to
ignore requests from other team members.
So, these issues led to several conflict occasions during
our third semester that would have not occurred if we
had worked on a live presence environment.
Despite our best efforts to overcome these issues, these
are without doubt some relevant side effects from
remote communications that should be recognized and
prevented whenever possible.
Had we better discipline on our live presence meetings
and perhaps some of this discipline would also appear
reflected on the remote talks. At this point I should also
note that the success of an adopted communication tool
directly depends on how participants use it.
As ultimate result when things go wrong, either due to
miscommunications or ineffective meetings, we can
also note how the interaction between team elements
might evolve to a more conflictive type of behavior that
I will address on the next chapter.
2. 2. Conflictive communication
This type of aggressive communication consists on the
repeated interruption of another speaker in the group
until the continuously interrupted speaker ceases any
attempts of completing his message, or even further
participating in the group. Martin Sani describes
conflictive communication in good detail at his article
entitled: “La communication conflituelle” [2].
Events of this type are direct and offensive, displaying
a clear lack of respect for the opinion of the interrupted
speaker. The conflictive person(s) adopts a posture of
aggressive superiority towards the interrupted person.
The other person is regarded as an adversary that needs
to be silenced regardless of displaying validity of the
facts in his line of reasoning.
The aggression on this case can incrementally scale
from a level of offensive verbal intervention, to a
louder tone of voice, going up to an extreme situation
of threatening the physical integrity of the speaker in
case he does not comply with silence.
Despite seemingly aggressive, this type of situation is
possible to encounter in groups where one or more
elements inside the team will typically assume an
aggressive or passive-aggressive communication style
and attempt to rush decisions that are only favorable to
their side, placing pressure on the other elements when
they do not comply.
Across the MSE studio experience, it was possible to
experience episodes of this style of communication
across each semester. I’ve first observed this type of
conflictive communication during long meetings that
would per times last up to four hours discussing inside
a room with members growing exhausted until no other
person would contest the most active and loud voice in
the group.
Albeit successful in reaching a decision, seldom times
it was reached with consensus or involvement of all
team members.
It should also be relevant to add that this style of
decision removed the advantage of using a group of
people with different opinions and perspectives to
consider multiple angles and possible flaws of a given
approach. Any diverging opinion is discarded during
this style of communication where one or two persons
are striving to win their arguments over all the others.
On our case, we fell as victims to this communication
style during the architectural design discussions. When
evaluating whether to use technologies such as JBoss,
SEAM and MySQL over simpler and lightweight
alternatives that required less overhead and technology
already familiar with, such as POJO, Swing and INI
files.
Instead, the discussion became a battlefield polarized
between two java experts in our team where side
opinions from other elements were often not taken into
account under the assumption that they lacked the
required java experience to make informed decisions.
With java experience or no java experience, in good
truth I should note that reasonable good sense ought
have driven these decisions instead of turning our
meetings into a competition, since we all desired a
good outcome but our aggressive communication skills
clearly played to our disadvantage.
As outcome, our graphical user interface soon grew too
complex to complete, leaving our project without a
user interface after more than 450 hours invested in the
development of this component alone.
This outcome brings us to the final chapter, where we
discuss how these type of events can be prevented from
occurring in the first place.
3. How can we avoid it?
On the previous chapter, I provided an example of how
a poor communication process combined with a more
aggressive style of behavior, can give rise to a sense of
competition between the team, raising conflicts that
(not surprisingly) are later seen as bad decisions rather
than not.
Of course that on the case of my team, we truly desired
to reach success on the project and attempted to opt by
all the “good” decisions even if our way to reach them
was not good at all.
But I also favor the opinion that sometimes people
need to clash and err, so that they could later
acknowledge their own mistakes openly and perhaps
learn a valuable lesson for the future.
The opposite of a conflictive style of communication as
discussed on the previous chapter is when people
engage into a cooperation style of interaction.
Working in true cooperation is easier said than done. It
requires trust, time and mutual respect between all team
members. But nevertheless, this is indeed the honorable
goal to keep in mind since it helps to achieve results
that are benefic to all the parts involved in the project,
helping to avoid unproductive situations of win-lose
competition inside the team.
3. 1. Communication cues
Communication cues are the forms used for one or
more individuals to express a given message. It is
closely related to their own communication style as
mentioned on previous sections. These cues are split
across three major groups:
Verbal – Talk or characteristic noises such as
“hmm..” and so forth
Vocal – The tone and expression of voice that
is used while talking to others
Visual – Body language expressed by the
speaker
Explaining with more detail each of these groups, we
can state that verbal communications represent the use
of words as a mean of communicating to other people.
They are the ideal form of expressing more complex
lines of reasoning. They are also an expressive form of
acknowledging our own opinion about a given subject
resorting to expressions such as “hmm..” and “uh oh..”
amongst many others that we are familiar with.
Vocal cues represent another relevant characteristic,
allowing emotions to be perceived through different
tones of voice that is used to carry over a verbal style
of communication
Visual cues encompass the body expressions. Crossing
the arms, laying back on the arm of a chair or pointing
fingers across a meeting represent a myriad of many
small indications that reveal emotions and state of mind
for those involved in the communication process.
Most of these characteristics depend on the skills of the
observer to recognize the nuances of body language
that might in turn also cause a wrong analysis to the
observer due to factors not evident on the surface. For
example, a person with a weak handshake might be
interpreted as a sign for lack of self-confidence without
knowing if that person is not suffering from sclerosis
that prevents her from applying more pressure on the
handshake.
In either case, whenever we neglect the analysis of part
of these communication cues, we are also ignoring a
relevant part of communication and feedback regarding
the way a given message is expressed by others.
As the topic of this paper entails, these are the ideal
moments when one should stop for a moment, look
around the room and listen carefully to these signals.
Only we can prevent a unidirectional communication
void that is nowhere desirable to see at group meetings
as covered by Stellman [10]. Failing to do so will lead
to problems.
I focus on some of the problems experienced after not
observing these communication cues and how they
have impacted our project development across the next
chapter of this paper.
3. 2. Cooperative communication
A cooperative communication style starts with an open
mind about other colleagues in the team. One needs to
adopt a learning perspective where differences occur
and should be understood rather than criticized:
Different work cultures
Diametrically opposed personality types, for
example: Thinker vs Socializer and Director
vs Relater
Age difference (generation clash)
Different styles of communication: guarded,
open
External factors: family involvement, context,
financial situation, religious beliefs and so on.
One of the foremost common mistakes is when a team
manager or team element assumes that everyone on his
team is synchronized with his own perspective. This
assumption is prune to create a discomfort feeling that
might later turn into a conflict.
We cannot be certain at all times that all elements on
the team are following our line of thoughts and an
effort should be made to open the communication
channels in a manner that is clear for everyone
involved.
As described on the previous chapter regarding how
“conflictive communication” flares, it is often noted
that a conflict will start from little details that bother a
person about someone else and incrementally erode the
willingness of working in a cooperative manner as a
team.
During our studio project, we’ve fallen onto this error
right from the start of the MSE program. Perhaps the
problem was carrying into our mind one single word in
mind as “processes” and that in our own way, this term
represented bureaucracy and a method for working in a
professional manner that would need to be embraced
regardless of inconvenience or hassles it could cause to
team morale and well-being.
We languished over never-ending meetings, adopted
hefty templates for reports that would take longer to
prepare than the content itself and even organized our
internal documents in a manner that was cryptic and
not intuitive for daily use.
Per times, it would even seem that managing our
paperwork and documentation resembled the one you’d
expect from a medium-large sized project with dozens
of workers at our disposal.
And all of the sudden the term “process” took a twist in
destiny and bitten our feet when nobody seemed happy
with the outcome of having our team working for the
process instead of having the other way around.
A process that is fit to the available team resources is
far better than a process that only sees deliverables as a
collateral result and this was one of the most important
lessons that I have learned across the MSE program.
“Process” became a way of organizing our individual
set of skills towards a common goal and working in a
cooperative manner to reach it.
Once the meaning of process was better understood, it
has indeed helped us to keep focus on several key
aspects of development such as communication, the
analysis of decisions and also the backtracking of
choices that allowed to evaluate with more accuracy if
our progress was going on the right track or not.
In due fairness I can state that only at the last semesters
of the Studio project we’ve finally come to see a more
balanced distribution of participation amongst all team
members.
After the fights to gain territory inside the team and
also after understanding that this style of disruptive
behavior did not helped our team move forward, we’ve
seen some of these conflictive elements to adopt a more
cooperative style of participation.
Based on this experience, I’d like to list a simple
guideline that could help to set the pace for a more
cooperative behavior right from the inception of your
project:
Keep the adopted processes simple
Define high level goals right from the start
and decompose them onto lower level goals
that are feasible to track at each week
Always, always, always include a plan B;
especially when opposing voices exist since
there might exist some reason behind them
Make sure that everyone in the team has
quality time to speak; round-robin is useful if
coercive discipline needs to be enforced on
conflictive team members
Before starting a meeting, define the action
items to be discussed, assign a time slot for
them to prevent over-time and follow it
Ensure that everyone respects the rules of the
meeting. Someone will inevitably try to
monopolize the meeting, diverting any chance
of productivity unless it is kept under control.
Final thoughts
These are some of the most important lessons that I’ll
carry from the MSE Studio project. A meeting is a
form of art that needs to be planned carefully to ensure
that we (as a team) can reach a productive and efficient
result for our team to make real progress.
In some occasions, it would have helped to keep a door
sign saying: “keep your ego at the door step” in the
meeting room. I am speaking against myself in regard
to this advice, as my behavior across semesters was
certainly not exemplar, albeit serving as knowledge
base to write this paper.
Reflecting in our progress as a team, I believe we have
learned how to handle a substantial part of our internal
communication issues. Even thought communication
has certainly improved, that fact alone is still not
enough to regain the trust once lost while engaging into
disruptive discussions within our own team, and this is
one of the aspects that still saddens me the most.
References
1. Alessandra, T. and O'Connor, M.J., The Platinum
Rule: Discover the Four Basic Business Personalities
and How They Can Lead You to Success, Warner
Business Books, 1998.
2. Martina Sani, La communication conflictuelle,
Università degli Studi di Milano – Facoltà di Lettere e
Filosofia, Dipartimento di Scienze del Linguaggio,
2010.
3. Stephanie D. Teasley, Lisa A. Covi, M.S. Krishnan,
Member, and Judith S. Olson, “Rapid Software
Development through Team Collocation”, IEEE
Transactions on software engineering, Volume. 28, No.
7, July 2002.
4. Carl Shapiro and Hal R. Varian (1999). Information
Rules. Harvard Business Press. ISBN 087584863X.
5. Jason Fried, David Heinemeier Hansson, Matthew
Linderman.Getting Real: The smarter, faster, easier
way to build a successful web application. 37Signals
Web development.
6 . Definition of personality,
http://oregonstate.edu/instruct/anth370/gloss.html as
retrieved on the 24th
of October 2010.
7. Platinum Rule website.
http://www.platinumrule.com/index.html as retrieved
on the 24th
of October 2010.
8. João Viegas, “People issues in an MSE Studio
group of individuals”. CMU/UC MSE Chronos Studio
project reflection paper, 2009.
9. Brooks, F., The Mythical Man-Month: Essays on
Software Engineering, Addison-Wesley, 1975.
10. Stellman, A. and Greene, J., Beautiful Teams:
Inspiring and Cautionary Tales from Veteran Team
Leaders, O'Reilly, 2009.
11. Tjosvold, D., The Conflict-Positive Organization,
Addison-Wesley, 1990.
Appendix A – Platinum rule
The platinum rule is a concise method that categorizes
behavioral preferences onto four distinct styles:
Relater
Thinker
Socializer
Director
This rule, as documented by Dr. Tony Alessandra,
allows others to identify individual qualities and help
understand the reasons why some behaviors occur in a
given manner. Albeit not a magic and infallible rule, it
does help to know better a person and avoid behavior
conflicts to some extent.
We will now focus on a brief summary description of
each style.
A. 1. Director
Directors are the style of person that demonstrates
being driven by two goals: to control and to achieve.
They can be portrayed as goal-oriented that are
notoriously comfortable when placed in front of a team
or a given situation. Directors are not afraid of bending
the rules to meet their purpose. For them, it is easier to
beg forgiveness than to ask permission. One can also
depict them as dominant, often characterized as
stubborn, impatient and insensitive to the feeling of
others.
A. 2. Socializers
Socializers are friendly and enthusiastic. They can be
found wherever there is action. They thrive on the
feeling of admiration, where recognition for their
efforts plays the upmost importance.
They are known for their enthusiasm and are superb
speakers that are capable of moving people to follow
their vision. Socializers are also considered as “eternal
optimists”, their hope is that things will turn out well,
allowing them to break deadlock situations where a
decision needs to be made.
As side-effect, socializers are also known as risk-takers
with a short attention span and aversion to be left alone
in the group.
A. 3. Thinkers
Thinkers are the style of people that fits those who are
more inclined to methodical practices and detail
oriented problem solving.
They value facts over intuition to an extreme; this is a
characteristic that comes with the advantage of
evaluating situations without emotional inflation but
also comes at the cost of not understanding emotional
nuances that would be evident to others.
Thinkers are perfectionists, they have the cunning will
to perfect a given process or work on their own
impulse, but they will also fail to participate in group
meetings if they are not based on facts to support their
opinions.
A term often associated with people depicting this style
of behavior is “paralysis by over analysis”. In the
process of trying to process more data about a given
decision where the facts are not clear, they will
sometimes fall into a situation of not deciding at all to
prevent making a decision that they cannot assure as
correct.
They often get irritated by surprises that force them to
change the original plans and feel uncomfortable
amongst very outgoing people such as socializers that
are diametrically opposed to their own behavior style.
A. 4. Relaters
Relaters are team players by excellence, they tend to be
risk aversive and enjoy building connective networks
with others in a warm and reliable manner. They are
also seen as devoted friends and persistent workers that
are loyal to their companies.
Relaters are also known for their willingness to share
responsibilities. One key aspect to note is the fact that
since relaters are often risk adverse, when faced with
changes in the original plan they’ll rather modify their
own plans to incorporate the external changes rather
than forcing their way into a conflict that prevents these
changes from occurring. They are also known as people
that often succeed in keeping a balance between each
aspect of the professional and personal life, keeping an
image of stability and composure.
Relaters rarely oppose to other opinions even when
they do not agree. They desire avoiding conflicts at all
costs that might place a personal relation at risk. In the
decision making process, they enjoy including other
opinions into consideration rather than deciding alone.
A. 5. Conclusion
The platinum rule is a tool that provides guidance in
regard to the way how a person matching one of these
category types will likely prefer to be treated. As with
all tools that deal with human nature, we also need to
use this tool with care to avoid wrong assumptions.
This appendix is a very concise description and a more
complete description can be found at the platinum rule
documentation and website on the Internet [1][7].
