Continuing the thread started here.

As you consider distributing your workforce, whether as a realignment or addition, you will want to determine how the roles of the different groups will relate to one another. Over the years, I’ve seen several models proposed. With enough thought, the right people, and processes, anything can work. Some patterns are just easier to handle than others. Regardless, you are preparing to set teams up that will need to dance with one another. Those dances work best when against the same sheet of music.

Lets first take a look at a few options with development teams. Some of the major themes  include:

• Separate the work to allow each team (here, there, everywhere) to completely own a particular part of the system problem. In this scenario, each team should include program, product, development and quality assurance. This can work well assuming all of the teams have the requisite expertise and that there are the right communication channels to align remote teams’ work with the broader portfolio and mission. Your big risk in this case is having remote teams go off track. If your team (like many) is committed to lean/agile practices, this may be your best option.
• Follow the Sun — this one’s been popular in cases where the teams are pretty far apart from one another (think US/India as a key example). One of the more popular cases of this scenario is to have the stateside engineers developing software during their day, and the Indian teams doing the test work during their days (as the US engineers rest). An upside of this is that you can establish a flow & maintain an effective work cadence. A major concern with this is that you leave yourself open for miscommunication & confusion. Any missing information in the exchange can pretty quickly lead to a wasted day (or more).
• Split work differently — have remote team handle more junior tasks. There’s often a mind-set that the legacy team knows best and should continue to define and direct your product’s architecture. Initially, this may make sense, however over the longer haul, I think that you’ll face two general types of problems. First, the remote team won’t take on the degree of insight and ownership that you may need to build the best quality product. Similarly, by building your team in this fashion, you expose yourself to more communications problems. What seems like a great idea to an architect can pretty easily turn into a mess if not properly understood nor finessed. If you’re dealing with significant distances (time zones can be a killer here!), these problems will recur.

You’ll find that there are many options, and you need to pick the ones that best suit your needs.  My personal preference is to split the work so that the remote teams can have as much autonomy as possible. The cleaner the interfaces & communications amongst teams, the easier life can be. That may be impractical in the early stages (the new team generally has a lot to learn), so you may want to consider staging a transition to whatever your end game may be. Also, don’t discount the value of travel and face time. When people get to know one another, and establish strong personal relationships, life is considerably easier.