Remote Development & Business Process Teams – Considerations for Success

George Michelson is a software development and business process expert with Sphere. He has extensive experience managing both in-house and remote teams around the world. Earlier this year, George participated on a TechDebate panel discussing considerations for managing remote development and business process teams. Techdebates.org was about managing remote teams and I wanted to pick his brain in advance about best practices. To attend future debates register at www.techdebate.org.  We’re always on the lookout for debaters – if you have something to say, let us know: https://techdebates.sphereinc.com/debater-registration

Remote Development & Business Process Teams – Considerations for Success

George Michelson is a software development and business process expert with Sphere. He has extensive experience managing both in-house and remote teams around the world. Earlier this year, George spoke at a Techdebates.org that discussed managing remote teams. We had the chance to dive a bit more deeply into the topic.

Based on your experience, under what conditions does it make sense for a company to hire a remote development team, instead of an in-house team? How would you counsel a client through the process of making this decision?

GEORGE: The process of deciding whether a remote team is a good fit for your needs requires several different considerations. 

Typically, clients are looking for unique skills sets. Or, they may be looking for qualifications that are hard to find in the locality where they operate. They might be interested in expanding their team larger than their budget would allow if they were to hire local talent. Or, they may simply be looking for ways to flexibly augment the team they already have.

As clients are making these decisions, they usually consider a combination of factors. But, typically, the question is one of how they can scale up their development or business process in the most efficient way. 

When clients hire remote teams, are they typically looking for specialized talent, or are they simply looking for larger pools of general IT workers?

GEORGE: In the past three to five years, I have found that most companies are looking for very specific areas of expertise. The era of generalized labor is over for software developers. Clients do not want to spend time teaching someone a tool or teaching someone a business. Clients want people who can come in, reinvent themselves, and be productive quickly.

Beyond some of the obvious advantages of hiring a remote development team—such as minimizing head count—could you describe some of the value remote teams can provide to a business?

GEORGE:  When you hire a remote team, regardless of where the team is located, a tremendous advantage is that you expand the expertise available to yourcompany. One of the interesting things I have found is that there are certain places that specialize in certain skills. So, if I have a project that requires a lot of mathematical skills, I know that there are locations around the world that are very good for acquiring that talent. If I need to test devices and I need a skilled quality assurance team, I know there are locations with a lot of experience with those skills. It is not just a headcount, it’s what you get in return.

What are the most common mistakes companies make when they hire remote development teams?

GEORGE: One of my former coworkers once said, “India is not Indianapolis.” While this statement is somewhat obvious, its true meaning does not really sink in until you try to forklift a process and move it across the globe. 

Whether it is development with a remote team or business process outsourcing, you have to realize that a process that worked beautifully in one place will not necessarily work somewhere else. You might get lucky, but most often you won’t. You are going to have to adapt the process to the locality where you are operating to get the best result.

The other factor that is really important is the maturity of the project or process. For instance, a “back of the napkin” software product idea is going to be difficult to communicate with remote developers. When a business person turns over an undeveloped idea to a developer, they are asking them to implement the idea as well as they can be based on what their understandings and coding skills allow. This highly informal/immature idea would be difficult to outsource successfully to a remote team. Too much would be lost in language translation, time zones, and overall mentality. It is critical to have a process in place and the process must be tailored to remote teams.

Informal communications on the phone or over Skype will likely not be enough to explain what will ultimately become a complex project. It virtually never works.

Miscommunications can result from differences in mentality, as well as core language issues. People around the world think differently, so an existing process may simply not make sense to them. You have to figure out how to overcome that. 

Language is another factor. Everyone on the team may speak English, but there are many different versions of English. A lot can be lost simply through differences in local usage of a language. With that said, I will close with a story that I still laugh about to this day. 

I was in Bangalore in front of a roomful of developers I had hired for a large new project. I had meticulously prepared for the project kickoff meeting and was confident that everything was in order. I was about an hour into my presentation when one of the developers raised his hand and said, “I have a doubt.” 

I tried to not let on, but I started to panic. I thought I was incredibly well organized and prepared but had I overlooked something important? Did I fly halfway around the world and commission an entire team of developers but make a mistake that now put the entire project at risk? 

Thankfully, I soon realized that “I have a doubt” in the current vernacular of that region of India meant, “I have a question.” I tried to wipe my brow without anyone noticing, but it was a jarring reminder of the miscommunications that can so easily happen.

 

Previous

Next