There is an art intrinsic in working
with distributed teams. There is also an art in surviving working
with distributing teams. This is an article which deals with the
latter, the unsung and the unglamorous skill and craft of managing
day to day survival working with a distributed team.
The core skill one need to have is relationship building. None other will
help you in you daily work. Especially if you want to be great at it.
Why? Teams are group o f people. For a
group to function people need to have good relationships with each
other. If people are collocated those relationships build only by the
fact that people work closely together. Of course this doesn't mean
that those relationships are great, but they generally exists in a
greater degree then those which naturally occur with distributed
teams. Relationships need work and effort and not many people do
spend it. Especially in the IT business.
Now, if you work with a distributed
team, especially if you never or seldom met or worked in person with
other team members chances are that you are not going to have a great
relationship with them. Now, you will talk to them and manage your
normal day to day assignments but that will generally be all.
Lets say you have a problem. You fouled
something up, or you don't know something. Something happened which
doesn't ordinary happen and you need help from one of your
distributed team mates. And that help is generally something which
will distract that person from their regular work for a couple of
hours or more. What will happen?
You call that person, if it is a normal
person she will try top help you. For an average half of an hour
everything will be OK. Then a full hour will pass and that person
will became nervous. And then she will find some excuse to continue
working her regular work or she will just ditch you. What can you do?
You can try calling someone else or try with escalating the issue to
get the help you need. Both will generally not result in happy
coworkers. If you call someone else that person will also be
distracted from their work and be nervous and if you escalate the
issue the person which will be dragged to help you (usually your
first call) will not be happy that your superior made a point of
noticing their failure with help you with your critical problem.
Just for a moment imagine that you
spent some time during the start of the project getting to know your
coworkers or just re-catching their life story if you worked
previously together. Maybe just talking about their families, helping
with their problems, discussing general stuff. Building a
relationship.
And when you have a problem you need
help with that person will be more likely to step in and help and
stick to it because she will help a friend not a coworker.
The other scenario which I encounter
and is a problem with distributed teams is getting steel cage death
match allies. Sometimes during a project you will get into a team
wide, or a subteam discussion about a technology solution, or a
problem which needs to be solved, or you just need to defend your
work. You need allies, you need people backing you up. If you spent
some time talking with people and building a relationship they are
more likely to be helpful if a problem arises and back you up. And
even more helpful if you spent some time before hand asking a their
opinion and discussing their ideas with the topic you are going to
have a steel cage death match over. People respond well to being
asked to express their ideas and opinions, especially engineers. If
you want to win people over in a software team you need to ask them
what they think and what they want and respect their ideas.
Now this a fallibility of mine which I
some times fall into. I forget to do that, and then I get bitten into
my humongous ass. If you are in a technical leadership role you
cannot just enforce your opinions and ideas on other. You need to ask
them what they think, what are their opinions and ideas. And wonder
of all even the most junior person of the team will have something
valuable to say.
In software development people and
relationship matter. No matter the deadline, no matter the cost,
think about the people first. Make your coo workers your top
priority. And when the proverbial rear exiting stuff hits the fan
they are going to be the people sitting next to you at six in the
morning fixing last minute defects on the presentation tier of the
application for the client presentation in the morning.
There is one thing I almost forgot to
write. Talk do not write. All distributed teams use one from of IM
communication or other. If you want to solve your problems fast and
build relationships talk to the person on the other side do not
write. Writing is good for quick ideas and exchanges but if a
discussion is in place you need to talk to the other person, you will
see how more quickly you will solve your problem.
