14. Face Time

The distributed project team relies on lots of face-to-face contact among the sites, to build the familiarity and credibility that enables long-distance teamwork.

“At computer society meetings one continually hears young programming managers assert that they favor a small, sharp team of first-class people, rather than a project with hundreds of programmers, and those by implication mediocre. So do we all.”

Some of you will recognize this excerpt; others may be surprised to learn that it was first published more than thirty years ago.¹ You still hear this today, though “programmers” have become “developers,” and today’s managers also specify a preference for a small, co-located team of rock stars. It was true thirty, forty, and fifty years ago, and it remains true today—this is the best way to build software.

¹ Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering (Reading, Mass.: Addison-Wesley, 1975), p. 30.

And yet, large and geographically distributed development teams seem to be more common than ever. You may encounter project teams spread across half a dozen or more development sites, though two or three sites form the more common configuration. Granted, a large distributed team may be composed of smaller co-located teams, but it must be managed as a distributed team if the sub-teams are working on elements of an integrated system or product.

Regardless of the motivation, distributed development may be proliferating simply because the availability of collaboration technology makes it less daunting. Teams cope with the challenges of distributed development by using instant messaging, wikis, video-conferencing, and Web-based meetings, in addition to good-old conference calls and e-mail.

Those who make distributed teams work best are careful to introduce opportunities for members of the group to get together at least occasionally. Why is face-to-face contact so essential to the success of distributed teams? In the absence of adequate face-to-face contact, teams at one site tend to regard those at the other sites with disdain. “Other sites” often comes to mean “bozos.” Face-to-face contact that is regular, reasonably frequent, and cross-functional builds up the reserves of goodwill and benefit-of-the-doubt that we spend down on all those conference calls and Web meetings.

So, how much face-to-face contact is enough? This varies from team to team, but these general guidelines may help you to decide for your project:

• Those most responsible for coordinating work among the sites need the most frequent contact. These people usually carry titles like program manager, project manager, or release manager. They need to meet multiple times per release cycle. Meeting quarterly is not enough.

• Among developers, QA engineers, and technical writers, the more-senior people need to meet their counterparts at other sites at least once per release cycle. Establishing mutual credibility and respect at this level enables opinion leaders to influence more-junior team members back home.

• Occasionally allowing junior team members to travel to other sites helps them see how their work fits into the team’s overall mission, and it exposes them to mentorship and career development with senior people at other sites. It also helps when you are arguing for a raise for your wunderkind to have a peer at another site support your high opinion of him.

Consider the following fool-proof recipe for guaranteeing the failure of a distributed development effort: Following the acquisition of a team at a distant site, the organization responds to the inevitable pressure to cut costs by restricting business travel “temporarily, until things improve.” To succeed at distributed development, you almost certainly will have to increase, not decrease, your travel budget.

Distributed development is an inherently difficult, high-risk practice. Sometimes, the potential to access or retain desirable talent justifies the risk. To borrow Tom Wolfe’s phrase, “I don’t advise it, you understand, but it can be done.”² Face time is one essential element.

² Tom Wolfe, The Right Stuff (New York: Farrar, Straus & Giroux, 1979).