If you’re working on a distributed creative team, especially ones spread across timezones, today’s post from Steve McConnell is a great reminder that you’re not alone in your struggles:
Travel restrictions and offshore development
The article is right: there’s currently no substitute for travel at those kinds of intervals. “The half-life of trust is 6 weeks” rings true.
Even in normal times, this is a heavy cost to bear, both for the company and for the people on the road. I’ve been at companies that have handled this “ok”, but never seen it be 100% positive and pleasant — this is a very hard problem. There’s a reason why Microsoft largely kept everyone on the same campus for almost 20 years up to the late 90s — and a reason why you should think about keeping things simple that way as long as you can, too.
If staying single-site as long as possible is the first line of defense, the second line of defense is trying our best to minimize and partition multi-site development in careful ways — e.g. into distinct products, projects, or features — to minimize trust issues and cost of communication. But this can only go so far in avoiding the issues of trust entirely. At some point (likely sooner rather than later), the worlds must meet, rules must be followed, decisions must align, and work on the product will overlap.
So, then, how do we design our processes and communication to be multi-site friendly? What processes and culture do we insist stay common or allow to be flexible? How do we maintain the trust to coordinate the things that we must? How can we hire more forgiving personalities for whom trust and camaraderie come easier?
There are certainly lessons to be learned from highly distributed open source projects (in particular, the tools they use and the ways they use them), but also cautionary tales of the borderline chaos that can ensue when the ties that bind are so loose and light. And I’m waiting for a good tell-all to be written on Google and some other other more recent companies who have embraced highly distributed organizations.
Going back to Steve’s post and how there’s no substitute today for spending time in person: we can only hope someone eventually finds a way to make multipoint video conferencing and techniques of remote socialization and team-building much more effective. It’d be great to not consume the time and energy of flying all over the planet — but that day doesn’t yet appear to be here.
Perhaps we could start with some company-sponsored network gaming to have some fun and get to know each other better? … of course, we then must decide which of the Bangalore, San Francisco, or Cambridge teams we’ll ask to get up at 7am to play. Hmmm.




Dew Drop – August 7, 2009 | Alvin Ashcraft's Morning Dew | 07-Aug-09 at 5:12 am | Permalink
[...] Multi-site teams: travel and the half life of trust (Bernie Thompson) [...]
Matthias Marschall | 11-Sep-09 at 1:36 am | Permalink
There is one important difference between open source projects and corporate settings that is often overlooked.
In an open source project you usually have _individuals_ working together whereas in corporate settings, you usually have _teams_.
In my experience it is very important to understand the team dynamics at all locations as they re-enforce the “us vs them” feelings.
Bernie Thompson | 30-Oct-09 at 10:25 am | Permalink
Hi Matthias – very good point. And, in fact, where you do have “teams” within open source – usually people working for Canonical vs. Red Hat vs. Intel, etc. — those tensions and “us vs. them” feelings definitely rear their heads (e.g. see http://video.google.com/videop.....7824733336 ) The “pressure valve” is the choice to (at least temporarily) branch and deliver competing versions — even if it’s not always the right thing for the technology or for the end-user. And that happens all the time in Open Source. Commercial companies tend to force their teams to deliver just one thing.
Trent | 28-Oct-10 at 10:56 pm | Permalink
It can be difficult enough to manage multiple teams at the same location. Once you spread out to separate locations, especially across timezones, things become just shy of nightmarish. Whatever can be done to mimic the qualities of same location (video conferencing, travel, etc.) is worth the effort.
SaaS | 23-Jan-11 at 12:12 pm | Permalink
Bernie brought up a good point about the “us vs. them” problem, but that is not the only problem in that arena. The cultural differences and the way english is understood by other cultures is a problem that is not often identified and dealt with. There are words and phrases that just do not translate between languages. And often the way others learn language is incorrect. In software development those differences can manifest themselves in clients not being satisfied with the end result and support costing more than just money. Thanks for the post.
Kathia Gourmen | 05-May-12 at 4:08 pm | Permalink
Hi Bernie,
You are spot on with your article on Muti-site collaboration.
I have the answer for you: iObeya!
This application allows multi-site teams to collaborate in real-time while visualising the same ‘virtual’ white boards.
Happy to answer any of your questions.
Kathia