Building an Offshore Development Team

Building an Offshore Development Team

Offshoring isn’t just shifting repetitive, low value, or high volume tasks to lower cost resources. In this global economy, offshore resources are often the backbone of POC, MVP development, SaaS, and support teams. Whether you need to build a product to spec at low cost, deliver on a development contract, fulfill a statement of work, or support a product long term, offshoring is likely an integral part of your plan. Here’s how to select and build an offshore team that doesn’t suck.

ACT I : LEARNING FROM THE PAST

While I was running my own web development company, I noticed early on that I would get a lot of jobs to quote, but was closing fewer deals than expected. It turned out, they were going offshore — though they may have gone in different ways.

There were companies that sold themselves as “software development firms” that were really just sales offices that offshored the work. I learned much later that this is basically what is done in the software development and consulting divisions at many Fortune 500 companies. However, an increasing number of project originators were deciding to go to sites like eLance, oDesk, and Freelancer to hire and manage their own resources.

I followed up on each project that I did not win significantly after their expected completion date. Those results were:

Failure	81% The project was not fully completed, client was seeking another developer.
Unknown	12% We could not get an answer from the project originator.
Success	4% The project was completed successfully.
Ongoing	3% The project was still in an ongoing status.

This is when I had one of the worst ideas I’ve ever had. I thought there might be a business in helping failed offshore projects recover with onshore resources. This idea had a short life in the wild as already frustrated customers with no time and no budget must be one of the most difficult jobs on the planet.

ACT II : PROJECT POST MORTEM

We know that 8 in 10 projects where the project originator tries to coordinate offshoring for the first time will fail. I wanted to know where those projects failed. Is there something we can do to prevent failure and take over to win more business? So, I researched it with the same client base simply by following up two or three months after their project was supposed to be completed with the position that we still want their business and would like to see if we can help support the project or add features. In nearly all of the calls, the customer immediately vented their frustrations with offshore vendors and I simply collected the data.

When the project originator finally stopped an offshore project and declared it failed, on average, all of the original budget and timeline was used and about half again.

Most project originators said that they built in about 10% padding and knew the project was doomed when that was exceeded.

The next question I felt was obvious was “Would you try offshoring again?”

3%	41%	56%
Yes	Maybe	No

For now, we’ll ignore the “Yes” response. It’s pretty low and we’d need to dig deep to figure out any useful data there. The 56% “No” response was pretty clear cut. They had such a negative experience that they didn’t feel there was much of anything that could make them try offshoring again. The really interesting metric is that 4 of 10 “maybe”.

The “maybe” responses were a mix of people who went with an offshoring company and thought they could do better by hiring the developers themselves and people who hired developers themselves and thought they could do better through an offshoring company. Unfortunately, we don’t have data on the number of people who thought they could try a different method and what the result was of the different method.

ACT III : IDENTIFYING CHALLENGES

Now that we know how far the projects got before they were declared dead, we can discover some of the reasons behind the failures. It’s important to know what the customers complained about – especially for first time offshoring – so that when we decide to build our team of offshore rockstars, we can address these concerns up front.

When I evaluated responses to group them, it seemed we had a few fairly obvious buckets that the complaints fell into. They’re generally organized as follows:

Time Zone	Issues related to meeting times, working after hours, delays between requests and actions or issues and decisions.
Language	Lack of English language skill either in reading or listening comprehension, or inability to clearly express ideas on complex topics.
Experience	Failure to maintain best practices in development methodologies, amateurish solutions, and standards of international business.
Culture	Mismatch of work ethic, valuing long lunches and vacations over completed projects.
Education	Lack of understanding general business practices, inability to perform required mathematics, logical design, or documentation.

Here are some actual statements heard from people I interviewed after their failed offshoring experience.

“Everything took 24 hours minimum. We’d get an email that said “I can’t continue work until you make this decision”. We’d reply within a few minutes. The next day, we got the same thing again. This happened several times until we had lost two weeks of productivity. Every question took 24 hours or more to resolve.”

“Getting those guys on the phone after we signed the contract took a miracle. Between the time zone differences, technology problems, poor connections, and thick accents, I ended up getting up at 3am every day just to talk to them and try to keep them on track.”

“What’s happening with these resumes? It’s like they took the skills that I asked the offshoring companies to find and stuck different people’s names on top and called it a resume. Every time I asked a question in an interview, I swear I heard hurried typing like they were googling it.”

“These guys swapped out developers three times by the end of the first week.”

From the above challenges, we can learn a few things.

We need to ensure when building any offshore team:

Pre-screen recruits – try them on internal projects first, build a call back list
Business hours overlap – must be significant and ensure direct and clear communication
Constant interaction – finding you’re off track by a week in a report, can kill a project

ACT IV : REGIONAL SPECIALTIES

These are the common areas of the world where software development outsourcing takes place. Certainly Africa has some up and coming countries — and there are a few places in the middle east that have some value to add to the global picture, but the highlighted areas all tend to have “stereotypical” similarities. Certainly these pros and cons aren’t true of every person or organization in that area, but they are important to recognize.

Group	General Experience
Central / South America	The time zone isn’t too far off for US and Canadian clients. However, the culture in some countries values vacation, family time, and long lunches over accurate work and deadlines. Top Choice: US market apps that need to be bilingual English/Spanish
Eastern Europe	Many places like the Czech Republic has quality education, quality code, elegant solutions, but also some fairly high prices. I’ve seen on multiple occasions perfectionists that will unnecessarily rework items based on style preference rather than necessity and slow projects down. Top Choice: High end customers willing to pay more for perfection
Asia	In most of Asia you’ll find a well educated workforce with medium to excellent English skills. While the quality is on par with that of eastern europe, the price is significantly lower. Culture is often “avoid conflict” and “save face” which can cause communication issues. Top Choice: Most projects that don’t need client / dev interaction
India	This is hit or miss. Challenges have mainly been low quality code, language barriers, communication breakdowns. However, I’ve also found some really high quality folks that deliver strong products. Unfortunately, those types have been few and far between. Top Choice: Low priced, short term projects.
China	I would mostly avoid China. Challenges have been code quality and payment “renegotiation”. On more than one occasion using completely different outsourcing methods, I’ve had code held hostage with demands for more money than agreed in the contract. Top Choice: Small, rapid projects with lots of recruiting.

ACT V : RELATIONSHIP BUILDING

While this section is on recruiting and maintaining talent, most people think relationship building is between business and the client. It’s really much more than that. This business transaction of delivering a product isn’t just between the client and the vendor, but between the client, the vendor, the vendor’s suppliers (developers) and ultimately the end users (often the client’s customers). In many cases, the client and the vendor are both simply “middlemen”.

If I demand a top notch developer work all night to fix an issue, especially one caused by a client’s mistake, it’s fairly likely I’ll get the job done — just that once. Then the developer will be looking to take his skills elsewhere and I’ll soon be short a top notch developer. This type of situation needs to be balanced against the need to deliver and it often a tough choice.

It is critical that this choice be left to the developer during the interview process. Something has gone wrong and you’re now team management. Let’s assume we’re getting close to a deadline and it looks likely that we will miss the goal. We now have the following options:

We can increase the project cost by adding more developer or analyst resources.
We can increase the project timeline and reset the deadline back to meet the goal.
We can increase output by reducing quality checks, testing, and just pushing code out.
We can increase the workload on the devs and ask they work longer hours/weekends.

Basically, I’m proposing the “fast, cheap, or good – pick two” concept, except that we’ve added an option 4 — demand more from existing resources. Unfortunately, this option is the most common I’ve seen at large and small organizations alike and seems to only add stress and cut quality.

These are the only selections that will result in not being hired:

Any candidate that picks item 3 – reducing quality.
Any candidate that picks item 4 – demand more – and is up for a team lead or management role.

This seems to align to the culture aspect of offshoring as we tend to get similar results based on region. Here are the results of these questions based on interviewees and region.

Group	Increase Cost	Increase Timeline	Reduce Quality	Increase Workload	Unclear Answer	Total Interviewed
India	16%	15%	31%	29%	9%	212
Asia	29%	50%	5%	9%	7%	156
Eastern Europe	36%	51%	7%	5%	1%	121
Central / South America	21%	59%	9%	10%	1%	119
China	49%	14%	26%	10%	1%	108

It is worth noting that the “unclear answer” only means that they tried to pick something that was not one of the available options presented. Sometimes they would say “I’d ask my management.” and I’d try to force them to pick an option and they’d say “I wouldn’t pick. I’m a developer. That’s a management question.” Remember the “avoid conflict” culture referenced earlier? This is an area where that shows. As a matter of fact, most of the assumptions I made were based both on experience and these numbers.

ACT VI : THE PROJECT

How do we tie all of this information together and make sense of it? How do we build that rockstar team of offshore developers?

Provide the developers what they want:

Steady employment
Developers want to feed their families every night of the week. Unexpected long breaks in projects where they aren’t paid will cause them to look elsewhere.
Better than average wage
We’re looking for top tier devs. If an average dev makes $18/hr in that region. We’ll start at $21/hr. We’ll use pay as our main leverage to attract and retain talent.
New and interesting projects
I have yet to meet a developer that wants to solve the same problem over and over again. They all tend to want new challenges.

Provide the customers what they want:

Pre-screen recruits
Always have new recruits build an internal tool, busy work project, or something simple to test how they fit in without the exposure of putting them in front of a client.
Business hours overlap
Offer a “coordinator” who acts like a translator between the clients and developers. That person will also be available for client facing meetings.
Constant interaction
Progress reports should be available daily, charted, and noted by the developers directly.