Early in my career, I worked with people who sat across the room from me, perhaps at times in the room next door. Back then, it didn’t take much to meet and discuss work with my co-workers. This was pretty much the norm in the 80’s and 90’s.

But wow, things have changed. Most (well all) of the large technology companies I’ve worked for find themselves in a new world where development teams are spread all over the place. This occurs for a number of reasons:

• It is much easier to work with teams all over the world. With the incredible advances in networking technologies, its far easier and less expensive to communicate with people all over the world. I’m very proud of the work we accomplished at CIENA as a part of that boom. There were some incredible advances we were able to achieve in significantly reducing the cost of bandwidth. In kind, the carriers drove down the infrastructure and subsequent advances in networking technologies have led to new, incredible possibilities.
• Companies, large and small, merge with one another. Its not unusual for those mergers and acquisitions to involve companies with headquarters on different continents.
• Companies find themselves pressured to reduce costs, while still needing to meet development objectives. While this isn’t a terribly popular topic amongst employees becoming displaced in traditional western nations, it is a very definite factor in the high tech world. For the most part, folks in the US with good software engineering skills continue to be in high demand.
• Companies may need to expand at a rate that they can’t support in their primary locations. It may be easier to find the needed talent in other locations.

Regardless of the reasons for making the shift from having a geographically co-located team to a distributed team, there are a bunch of things to consider. These apply both when first setting up the team, as well as maintaining positive momentum once the teams are established.

There are two general areas that require consideration: the things that you’d want to do any time you’re hiring new people or teams, even they were to sit under the same roof, and the things related to the the geographic change.

Regardless of location (even if in the same location), there are some things that are absolutely essential. These include:

• Get the right leadership in place
• Clearly understand what it is that you want them to achieve, and be certain that it passes the sniff test.
• Hire people with the right stuff. Intellect, communication skills, EQ, etc.
• Hire people that want to do the job. If you need to build a team that is addressing defects in existing software, hire people that enjoy doing that work. Don’t hire a bunch of architects whose passion is in building new applications. They will probably not be happy, and not stick around.
• Create an environment in which they are able to succeed. Ideally one where they are given some autonomy and ability to develop the skills and team cohesion on their agenda.
• Plan on a reasonable time scale for them to come up to speed. Wherever practical, narrow the focus of the new team’s activities to allow them to add value sooner rather than later. But don’t be naive. It will take time for even the smartest folks to hit full stride. Time zones, and limited access to information can impede that progress.

Then there are the things that are unique to the distributed team establishment. These include:

• Consider the feelings of your current teams. They may look at the outsourcing or off-shoring activity as a threat. If you don’t express your intentions, your people will invent them. I think its better to have a frank conversation with the teams. It takes less energy to be candid than to put out the uncontrollable fires that result from hall talk. They may occur, but a transparent discussion will tend to help.
• The startup costs can be significant. Understand what you hope to achieve and balance that against the effort and distractions that are involved.
• Plan on the learning taking a bit longer, and put activities in place to help that along. Travel, structured presentations, frequent interactions amongst the teams can help.
• Time Zones. If you’re working across several time zones, plan on having meetings where someone is going to need to be flexible.
• Whenever possible, start with more senior folks. They will be a huge help in recruiting the right team, helping with the training process, and being both your, and the teams voice.
• Engage people across sites. This can help ensure that the right work is being done, and over time, can build stronger working relationships that can be extremely helpful.
• Treat the new team as you would any other. Give them sufficient latitude to contribute, and be proud of their contributions. There can be a tendency to micro-manage the new teams. Rather than directing specific actions, its often better to work in a mode that provides them with objectives and coaching towards success. We’ve found that greater ownership, responsibility, and the ability to verify the new team’s success pay significant dividends.
• Plan on as much interaction as possible. With services like skype, and other video conferencing, you will find the benefits of the efforts huge.
• Visit the team. Once people get to know one another, its far easier to communicate and collaborate.

Establishing and leading a distributed organization has its own set of challenges and opportunities. When done well, it can be a tremendously rewarding experience. The teams benefit from added diversity and I’ve found the experience of meeting and working with people across the world as a fascinating opportunity to learn more about the world and people’s views.