Play to Their Strengths: Effectively Utilizing Offshore Resources in the Face of Deep-Rooted Prejudice

Problem

Many years ago now I was working on a team for a company which had an office in Hyderabad. The FTE resources there were utilized in the way one would leverage an outsourcing firm. Unfortunately, their output had been less than ideal. Code quality was an issue. Not being embedded in the “core” business, team members would often encounter “blockers” - mostly needs for clarity in requirements, or additional business context - which would not be cleared for a full business day due to the time zone offset. In the meantime, their only options were to either pull stories from the backlog (which themselves would become blocked by questions), or to sit idle. Our resources even had trouble unblocking those team members.

Our engineering leadership was reaching the end of its rope. They held the offshore resources themselves responsible for the poor output and utilization, citing lack of experience, less-that-satisfactory coding skills, poor work ethic and attitudes, and so on. Thinly-veiled racial prejudice was lurking under the surface (sometimes even spoken outright), and I suspected this was a large component of the problem. Management was on the cusp of dropping these resources entirely, in favor of taking the local contractor route. I had a completely different set of theories about why these resources were not effective, and decided to go out on a limb to see if I could salvage the situation.

Actions taken

Though at the time I was just one developer on a large team, I asked to be given the opportunity to lead this team in one last trial-run before they were dropped for good. To say that my supervisors were skeptical and unsupportive would be a gross understatement; but considering the expense of switching to onshore resources, they reluctantly agreed to give it a shot, on condition that the relationship be severed after one sprint if there was no marked improvement.

 

The obvious culprit would have been the stories/tickets, but while they weren’t great, they weren’t terrible either - this couldn’t be the root cause of the problem. The communication gap was no doubt a challenge, but I had led teams to success in the face of greater language barriers. Work schedule differences were also a challenge, but again, I had seen that overcome before. There had to be something else at play!

After pondering the problem I began to see that the core of this problem was neither unique to this team, nor these resources. Having had prior experience with technically managing offshore teams, I had noticed a disturbing trend in the industry. All too often, onshore individual contributors, technical leadership, and management alike - through a combination of poor communication, seeing excessive “blockers”, and an undercurrent of racial bias - seemed to unanimously reach the conclusion that these offshore resources were incapable of thinking for themselves. The fact that these resources seemed to flounder every time they encountered a problem that required some element of design further reinforced this unfair stereotype, leading to the conclusion that they were just “green”, inept, and incapable of design work or independent thinking.

I believed otherwise. My wild hunch was that after long-term utilization as offshore burst resources, after being treated the same way for so long, they became fearful of stepping outside the bounds of a clearly defined, comprehensive technical specification. Perhaps they even believed themselves incapable?

I identified some concrete steps I would take.

The first challenge to overcome was the time zone difference. The few times I had seen managers try to solve this, their approach was to force the offshore resources to work night shifts in order to match US schedules. I believed that sent the wrong message, so I scheduled daily standups at 1 am my time, and made sure to always attend. In this way, I was able to address any questions or blockers before they got started for the day, in order to keep them productive. This also allowed me an opportunity to get to know these guys on a personal level, infer their strengths and weaknesses.

In doing so I was able to quickly identify one team member who was exceptionally intelligent, but more importantly was slightly more assertive, confident, and authoritative. While for a time I kept leading the team in the same way they had been used to date - providing clear, explicit, direct technical designs and leaving the team to code - I spent more and more time with this particular individual. I showed him how I worked, asked him questions and proposed solutions, and I incorporated more and more of his designs into our code. I began relying on him to proxy more and more of my guidance directly to the team and made it clear that if questions arose from them, I trusted him to make decisions. Output and quality were steadily increasing, and the one sprint “trial run” was extended to two, then three, then dropped altogether.

Ultimately I made this individual the effective technical lead on the project. I remained responsible for the architecture, mentored and supported the team; but I entrusted him with work assignments, setting technical direction, and managing the rest of the team.

The impact was remarkable. The team members became more and more confident. They started trusting their own judgment, and found that their intuition served the company well! The code quality and designs became better and better. And what I found more encouraging than anything else…they seemed to really start enjoying their jobs! What had been chalked up as a lost cause, became the exact opposite.

Lessons learned

• Be on the lookout for the impact of entrenched racial bias in the workplace. Obviously, overt racism should be addressed in an if-you-see-something-say-something fashion, but often institutionalized racism impacts decisions without anyone recognizing it. In these cases, the best path forward may be to work - HARD - to find ways to showcase the exceptional strengths of these victims in such a way that they entirely contradict the biases. The best way to help people realize they were wrong, is often to show them they are wrong...and this takes being an advocate and a champion!
• If you find yourself presented with an apparently dysfunctional team dynamic, don’t throw in the towel. Carefully evaluate the situation, look for the breakdowns, and find targeted solutions to those problems...even if they seem extreme or revolutionary!
• Make yourself part of the solution! In a leadership role, people often fall into the trap of setting expectations that their direct reports change their behaviors and styles of working in order to gain efficiencies. It can often be more effective if you carefully evaluate whether certain problems may be solved just as well by you making changes. If you do that, you demonstrate that you’re committed to the greater solution, that you do not consider your team members “lesser”, and that you hold yourself to the exact same standards as you expect of your team. The impact of this one small change can be dramatic, inspiring, and extremely effective!
• If you allow preconceived notions to affect how you treat your employees, you risk creating a self-fulfilled prophecy. Rather, encourage them, value them, and treat them like the intelligent, insightful people they are - even if those attributes aren’t quite obvious yet - and you'll reap what you sow.