Winter '06-'07 Perspective: Teams Don't Move —by Steve McMenamin

Home About the Guild Articles Books –New Books –Guild Books –Guild Library Consulting Contact us Resources –Requirements –Software Engineering –Project Management –Other –Cocktails Requirements Template Seminars –Mastering Requirements –Risk Management –Requirements Modeling –Mastering the Requirements Process part II Services –Litigation Support –Project Clinics –Physical Exam Volere		Mergers and acquisitions create strange collections of software development teams. It is no longer uncommon for a company to have developers in half a dozen (or more) locations on two (or more) continents. Sooner or later, the complexities and frustrations of globally distributed development cause managers to fantasize about having all their developers in one place. These fantasies sometimes grow into plans to move teams from one or more distant sites to a single location, or at least to consolidate into fewer locations. The problem with such plans is that teams don't move. When used in this sense, "moving a team" is a self-deluding euphemism for destroying one team and building a new team in another location to take on the work of the destroyed team. Steve McMenamin Let's take a closer look at how companies get into this situation in the first place. It usually begins with a merger or acquisition. A European software company acquires a smaller U.S. firm to gain access to its technology and its talent pool. Or, two banks merge to combine their operations and expertise, bringing with them their separate application development organizations. In either case, you now have a distributed software development organization. Some companies take a very hard line after such a merger or acquisition: All operations of a particular kind (like software development) are immediately consolidated into one site. Employees located at the other site may get the opportunity to relocate to the chosen location, or they my simply be laid off. But in many cases companies find compelling reasons to retain teams in multiple locations. The situation becomes even more complex if the company is a "serial acquirer." One acquisition is followed by others, and before too long managers are struggling to synchronize the efforts of up to a dozen development sites. This is, of course, possible, but it is not easy. Over time, a good deal of management bandwidth becomes devoted to the peculiarities of globally distributed development (e.g., coordinating meetings across time zones, increased travel for face-to-face meetings, integrating and testing code developed in separate labs, etc.). As the inconvenience and expense of managing distributed development grows with the number of sites, managers often long for co-location. Consolidating teams into a single site can become appealing for several reasons: Versatility. Development priorities change over time. Managers need to respond to changing priorities by re-tasking development teams rapidly and effectively. You may discover that you need twenty server-side developers on the next release of a product, rather than twelve. However, suppose that you have only twelve engineers at the site in question, but you have up to fifteen more developers at another site that could be reassigned. You are faced with an ugly choice between hiring off the street at the first site, or creating a potentially artificial division of work between the two development sites. It would have been far easier if all 27 engineers were in the same place. Agility. Agile methods rightly place very high value on co-locating development teams to enable high-bandwidth communication among team members. Co-location gives you the best opportunity to get the maximum value from these methods. Cost. Managers are quick to notice when one of their development sites has a substantially lower cost structure than the others. Thoughts of "Gee, if I could do all my development at these rates, I'd save a bundle." are never far behind. Regardless of the specific attraction, site consolidation and co-location can become powerfully appealing to managers who are tired of paying the high tax on distributed development. When companies decide to move a team from one location to another, they typically offer the members an incentive to relocate to the new site. The nature and magnitude of the incentives vary widely. In some cases, the offer is nothing more than "If you want to keep your job, you need to move to Denver." In other cases, companies offer substantial financial bonuses to team members who agree to move, in addition to paying the employees' relocation expenses. Regardless of the incentives offered, attempts to move teams from one site to another rarely succeed. Some employees do agree to relocate, but typically not enough to provide "critical mass" for the team. It is pretty easy to understand why most team members decline to relocate: Many employees have working spouses who are understandably reluctant to disrupt their own careers with a move. Couples with school-age children are equally uninterested in forcing them to change schools, leaving their friends behind. During most of the past twenty years, software engineers have been in relatively high demand, so good developers usually can find work without moving. Once it becomes clear that only 10-25% of the team has agreed to relocate to the new site, managers are forced to begin building a new team, nearly from scratch. If the team is supposed to include 30 people, and only six have agreed to move, you now face the prospect of hiring (or reassigning) two dozen engineers to reconstitute the team in the new location. What once seemed like an attractive alternative to distributed development now has become a major re-staffing exercise that is bound to take months to complete. During the months of rebuilding, the new team will have limited development capacity as it deals simultaneously with both the learning curve and the hiring curve. So what is a software development manager to do? I have no magic solution to this genuine dilemma. I advocate facing the choices in front of you realistically from the start: Think long and hard about the high cost and complexity of distributed development before you get into it. If you are not sure that your management team has (a) sufficiently good reason to operate in multiple locations; and (b) adequate resources and experience to do so successfully, you might be better off forcing site consolidation at the outset (i.e., as part of the merger or acquisition). If you are already doing distributed development, do not fool yourself into thinking that you really have the option simply to move teams to one site to avoid the difficulties of the distributed approach. You can consolidate, of course, but doing so ultimately will mean starting over. Ask yourself whether the pain of distributed development is so great that you would actually prefer to blow up the distant team, and hire an entirely new team in the preferred location. If the answer is yes, and you can afford the downtime required to do so, then at least you are proceeding with your eyes wide open. Distributed development is difficult and expensive, but it provides rapid access to worldwide software engineering talent. Co-located development is efficient and agile, but it limits your growth to what you can achieve in your local labor market. Either can be right for your organization, provided you see the options for what they really are. — Steve McMenamin, Los Angeles, new year's day 2007 top of page

home |  about |  articles |  books |  consulting |  litigation support |  resources |  physical exam |  clinics |  template |  seminars |  services