Earlier on in my Career, it was quite novel to have a Project or Product Team having members distributed across multiple locations. Well gone are those days. Distributed Teams are rampant in High-Tech nowadays and I do not see any reason for that to change in the near future. With the numerous Acquisitions, Traffic issues and resultant Remote Workers and Global Companies, Teams will only get more and more distributed. I think the best approach is to embrace this fact and learn to deal with it.

Most Projects start off with a confident-inducing schedule and the general feeling that things are under control. But then, almost all Projects have this “Frantic” and “High Pressure” Final Stages. As the Project progresses more, more and more Risks are brought out and things get into a tail-spin. I have rarely seen an ASIC Development Team claiming to be totally relaxed and under perfect control towards the last 2-3 months of the Project. If they do, then it is probably a Project which everyone (including the Team) has given up on! 🙂 Just kidding there … Saying that the Project “must not have a Frantic final stage” is like saying “there should be no corruption in Politics”. I wish it was possible. The difficulty is that the entire team has to be disciplined and organized for a Project Team to totally eliminate final stage jitters. Having just a few members who pace themselves perfectly rarely helps. That is why, I think, the last stage jitters is so common.

During the initial phases of a Project, Distributed Teams rarely have any issue with Time Zone differences. Hey, everyone is relaxed, Project deadline is way into the future and life is good! (Note: Diligent team members who are good at pacing themselves, typically do not fall into this line of thinking). It is in the Frantic Last Stage when things get real stuffy and everyone starts cribbing about the Time Zone differences, late/early conference calls, lost days etc.

I have come across a lot of Companies claiming 24-hour Work Cycles (especially in the Design Services Industry). It is quite a stretch in my opinion to claim that, for most scenarios. Two examples where it does work are: (a) Design Team at LocationA and Verification Team at LocationB. LocationA office hours can be spent on debug and bug fixing and LocationB office hours can be spend on testing and detecting bugs. (b) An overall Project being split into Parts A and B and each part being executed at different self-contained locations. In such a case, the overall Project time requirement is reduced correspondingly (assuming the Integration challenges are properly addressed. I will address my experiences with “IP/Design Integration” in another Blog).

The main way to tackle Time Zone issues in Distributed Teams is: Be Flexible!

Yes, it is that simple.

No one likes to work past the typical office hours in their Time Zone. But that does not bode well for Distributed Teams. So, accepting the reality is Task No:1. Instead of having a hard-coded 9AM-6PM working style, you might want to spread around that 8 hours of total work into different slots. It is not wise to insist on rules like “I wont check emails after 6PM”, “I am not available before 9AM”, “My cell phone number is more protected that the US President’s Nuclear Code” etc.

(Speaking of Cell Phones … I am sometimes amused by how protective some people are of their cell phone numbers. Maybe I am feeling this because having worked in Design Services and Product Development and having dealt with Distributed Teams for a long time, I am very open and flexible and do not see any issue with people contacting me for issues/updates. I prefer to know ASAP about an issue than to get to know about it several hours later. A lot many issues which I faced in my career were solved by a thought process (i.e. I had the solution in my mind) before I even got to office the next day. Then what about “Privacy” and “Personal Life”? Well, that is why we have “Voice Messages”, “Mute Button” etc. I put it in Mute during “Family Time” and check messages in a couple of time windows before calling it a day. That way, I am neither interrupted during “Family Time” and nor am I preventing myself from getting critical Project updates. Please note that in many a case, 5 minutes of your time can help prevent another person wasting his/her entire workday)

Some Tips for Frantic Stage Distributed Teams’ Communication:

– Keep it short, 30 minutes is a good rule of thumb

– Prepare the agenda and let the other party have an advance peak at it

– Keep it at fixed timeslots, unless of course a catastrophe occurs

– Keep switching the times, so that you do not force the other party to always be the one to babysit the phone at midnight or 4AM. I.e. take one on the chin for the “Distributed Team” …

– Be focussed and time manage the communication well …

Adios …