28 April 2012

Surviving a distributed software development team


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.