Global Software Development — Working with Legacy Teams

IMG_0114Continuing from the thread I started a while back. There are several things to consider. The teams that got you to this point are going to have a reaction to adding staff in different locations. For some, it may feel a bit like they are on a roller coaster ride. Could be anywhere from exciting to gut-wrenching.

Or perhaps the following may be a better visual. Whether or not (and when) you choose to discuss the topic, there are elephants in your room. You’re considering changes. There are consequences, and odds are pretty good that you have a bunch of very bright people who will have a reaction.


Assuming that you’re venturing into a global organization from an existing team, there are inevitable questions.  As a leader in the organization, you have two general choices, one is to not bring it up with the team, the other is have a more candid conversation. Depending on where you’re taking this, either are worth considering (I have my bias, but its really up to you).

Thinking back to some of the observations when I started with this series, one has to be aware that people are going to have a series of reactions to any form of change, some will be positive reactions, some fueled by uncertainty. Regardless of how you envision your approach, I think its wise to minimally understand how your existing team is going to react to adding new team members in a different location This could be anywhere, another building, another town, state, province, or country all-together. Any time you change the team, people will have questions.

I think that this article by Jack Welch captures many of my sentiments about how one communicates with people. In particular, check out points 1 through 3. All of them emphasize trust, communication and follow up. Short story is that its much easier to work with people with whom you have a solid rapport than not. I’ve found that I do better with an open rather than closed book, and above all be honest. I recall a clever former coworker of mine quipping that he wasn’t smart enough to lie. Way too much to remember. I don’t know that many (hopefully any) people are smart enough to get away with lies for very long. Also, secrets are awfully difficult to keep, particularly when you’re probably looking into something that will undoubtedly require coordination amongst several people.

So here are some thoughts:

  • If you have no (or very little) concern for how your legacy team feels about things, or their continued support, you may be able to get away with not sharing any information. Beware of this. Even if they all become irritated and leave on their own volition, you will be developing a reputation as an manager/employer with no allegiance nor loyalty to your employees. In high supply times, you’ll probably survive this, although it may be difficult to sustain in the long run. Your new teams may also see this and develop a negative outlook.
  • There may be things that you’re ready to discuss, others perhaps not so much so. Be sure that you have reasonable and credible answers to the questions that your team will have. If you don’t answer them, they will, and their answers are likely to have more negative consequences. There’s not much point in trying to stifle your team’s imagination!

More than likely, you are going to need the help of the people with whom you’ve worked to the point of the transition. My preference is to be honest with them, hear there concerns, and share constructive thoughts that they may have. You will likely hear a range of reactions. As you best can, work with the team to consider the positive aspects of the change and understand the risks. I’d be careful about making commitments that you can’t deliver (statements like “don’t worry, you have a job for life”). People probably won’t believe you, and your credibility will suffer.

So, once you know enough to share (I’d be careful to share only info that has some credibility — lots of alternatives may cross the management team’s mind early in the process), let them know what you can and what you’re considering, and if they voice concerns that aren’t fully founded, let them know that things are still in flux and keep them informed as you work through the process. I’ve learned from past experience that plans and reality don’t always align. Be careful to speak confidently when you are able, and not waste energy on those things that have yet to evolve (and aren’t apparent).

More importantly, you are probably (almost definitely) going to want/need to have your current team help manage the process. More than likely (almost definitely), these are the people who know your products and directions. You will want their help.


About Mike Rodbell

I'm a technology leader, engaged in developing software for the telecom, online commerce, and business process/analysis markets. All of the teams I've worked with have had a great deal in common. They need to be good at what they do, listen, share, and collaborate towards a shared set of goals. This blog is dedicated to those activities. I hope you enjoy reading it.
This entry was posted in Uncategorized. Bookmark the permalink.

1 Response to Global Software Development — Working with Legacy Teams

  1. Pingback: Global Software Development Processes/Approaches | Mike Rodbell's Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s