“All I Need Is Engineers”: Why This Approach Fails For Offshore Software Development

I’ve been working in the offshore software development industry for about 15 years, dealing with our current and potential clients and the proposals we create for them on a daily basis. Every week or so, I face some prospective client who says, “I want to put together an offshore engineering team. But don’t put a manager on your side; I will not pay for that. All I need is engineers. My team leaders will manage them directly.”

Well, I’m all for good cost savings. After all, the primary reason for outsourcing software development is still cost optimization, though the industry has significantly matured over the last dozen years, and people nowadays also think about such things as performance or access to global talent and don’t forget to look beyond the rate-per-hour figures and consider other important factors. For example, the KPMG study of large UK outsourcing contracts found that the importance of the cost factor for outsourcing decisions has decreased from 83% in 2010 to 70% in 2012. Not revolutionary, but a clear trend.

From the success factor perspective, I also wrote about the importance of communications skills recently, and that’s obviously not the only factor there that is at least as important as cost. Still, nobody can deny that the cost factor is and will continue to be important.

But creating a headless remote team is not the right way to optimize costs. As a service provider, we love new business, so in several cases in our history, we just gave up and did as our clients asked us to do: started a team without a team manager on our side, relying on the client to control the engineers remotely. It never worked out well, and we had to put those managers on our side eventually. I can tell you stories about the engineers disappearing on the day of an important milestone, or tension between subgroups inside the engineering team growing for months before suddenly becoming very visible and ugly, or clients’ complaints about the “mocking and ridiculous” individual status reports. In short, I hope we’ll not have to repeat that process again with a new client. And here is why.

When you deal with a provider of software R&D services like Auriga, even if all you need is a very basic dedicated center (or a center of excellence, as some prefer to call it, while having the same approach in mind), you expect more than when you deal with a recruiting agency.

You may merely want to put together a group of engineers in some remote location (to save on costs or grow faster by utilizing a new labor market). And you plan to integrate them completely in your engineering organization and give small groups of two to three engineers to your seasoned team leaders (this remote-TL-based approach deserves a separate blog post with caveats and best practices, which I’ll probably write at some point, but I’ll let it pass for now). However, in addition to recruiting capabilities and providing the infrastructure for your team at the remote location, you also—explicitly or implicitly—expect the following from your provider and your new team:

1. Motivation. Team members should be motivated to work with maximum efficiency: look for optimal solutions, stay extra hours for critical tasks, etc.
2. People management. All interpersonal problems inside the team must be promptly identified and quickly resolved.
3. Stability. You need a stable team with minimal attrition to save time and money.
4. Ability to grow. The new team members must be quickly brought up to speed in the project-specific areas with the help of knowledge bases, training programs, and mentoring from other team members.
5. Growing performance. The team efficiency should increase with time through knowledge/skills development and management.
6. Presence control. You expect the provider to ensure that all team members are in the office and working on their tasks. Besides, you are aware in advance of all planned paid time off (personal days, vacations, etc.). And in case of unplanned paid time off (illness, personal emergencies, etc.), you are informed and the tasks are reassigned to minimize the negative effects.
7. Process control. You expect the team members to use the processes and procedures required in your organization; respect your security policy and code of ethics; and update the joint task/defect/requirements tracking systems, sprint backlogs, or similar repositories and systems in a timely manner.
8. Daily operation. You need to get support for the infrastructure used by the team, including communication channels, common services, etc. You expect the provider to ensure that the infrastructure problems are rare and are dealt with quickly. You need the provider to deal with salary raise requests, local tax/job-related forms, burnt LCDs, replacement keyboards and USB sticks, and other minor and not-so-minor daily issues.
9. Contingency recovery. You expect the team to continue the work despite contingencies, using reserve and backup communication channels to provide work results to your side.
10. Reporting. You need true, concise, and clear information about the operation of the team. You expect your weekly/monthly timesheets, status reports, and invoices.

These ten bullet points are exactly why you talk to a software R&D provider and not a recruiting agency. You need the provider to not only hire the individuals but also operate the team. In the BOT (Build-Operate-Transfer) model, that’s what the middle “O” stands for. You may not use or need a BOT approach in your case (again, BOT warrants a separate set of posts later), but this requirement of somebody doing the “O” part doesn’t go anywhere.

The team manager co-located with the team is not the ultimate silver bullet for addressing all these requirements. However, s/he is a major factor in dealing with the following:

• [1] Motivation, [2] People management, and [3] Stability. Only direct personal communication enables you to discover situations such as team members who are experiencing interpersonal problems, are dissatisfied with something, or are looking for a new job. Working side-by-side with the people, meeting them every day, and helping with their small issues can help you identify those problems and fix them.
• [4] Ability to grow. Direct contact with the team members allows you to identify when team members (especially new members) lack knowledge or skills and help them acquire the information or involve other team members.
• [8] Daily operation and [9] Contingency recovery. The team manager is the main point of contact for most daily issues and the main escalation point for the problems experienced by the team and the client. The team manager ensures the involvement of the required provider’s resources from other departments with the priority adequate to the emergency situation.

Having the team manager is also a major success factor for [5] Growing performance, [6] Presence control, [7] Process control, and [10] Reporting. I won’t even go into details here, as I believe the benefits are obvious.

Plus, there is one more thing you need to keep in mind. Just as you care about the success of your business, the service provider cares about its business. The provider is interested in motivating the team and keeping the attrition low. Unmotivated teams result in low satisfaction on the client side and frequent requests to replace underperforming engineers. High attrition—in having an understaffed team (read: lost money for the provider)—also leads to increased hiring expenses. I’m sure I don’t need to explain further how that is bad for the provider’s business. Besides, somebody still needs to be that escalation point and do all the administrative work (reports, etc.).

So what happens is the provider puts that manager for the team on its side regardless, even if you say that all you need is engineers and you don’t plan to pay for a manager. And obviously, the cost of that manager is included in the cost of the team by increasing the hourly/monthly rates for the engineers. So you don’t win anything in terms of the team cost. But what you lose is the ability to utilize that “shadow manager” from your side. If you don’t want him/her and don’t pay for him/her, you’ll not have that convenient emergency or escalation contact, that extra pair of people-management hands, and that ally on the remote team side to handle complex situations. Besides, you end up duplicating the functions of that manager on your side (only with lower efficiency), so eventually, you end up paying an even higher cost.

The bottom line is simple: Even if all you need is engineers, and you have good team leaders to provide technical control and guidance, still put a team manager on the provider side. You’ll save some nerves and money by explicitly paying for that guy.