Whenever the subject of managing remote teams arises, most leads and managers that I know would prefer that the work remain in their home office.
However, we know that it is nearly impossible given the high demand for qualified staff, quick ramp-up projects, or any other myriad of reasons. Being in the position of leading and managing, we must distribute the work, which intensifies our job. Be careful to do it right.
Distributing work is not as easy as others think it may be, but on the other hand, most organizations have at least a dozen years of experience in managing distributed resources, so we have learned a lot from the school of hard knocks. This article has three stories that stand out as prime examples of poor offshoring techniques.
When considering outsourced testing, what thoughts initially come to mind? Let’s clarify, offshored and outsourced testing. Do they have an understanding of the technology? Are they able to be trained on the product? What is the level of competency in English?
Here are three one-liner, real-world stories:
- In the first scenario, we have a test team of junior developers in Russia (not unique to Russia but that is where this story happened) that were timid about reporting bugs. They felt that reporting bugs would anger the developers, who had the power to promote them to a real developer position.
- There was a test team in India that was a merry-go-round of staffing; teams were staffed according to which project or client cried the loudest. The staffing was based on the reactions of clients and the needs of projects.
- The final example involves a US-based credit card product where the work was distributed to China. For this credit card product, neither the developers nor the testers had credit cards and only had a basic level of understanding of the users and uses for their product. They were completely clueless regarding alternative paths, error cases, and complicated workflows.
All three of these projects failed due to a culture of fear, secrets, and lack of information. A rapport to foster questioning and exploration was missing. To put the onus on the home office—all of these failures stemmed from a lack of trust.
So, now that we have recognized the problem, how can we move to a solution?
Communication is key
The simple answer is communication and a bunch of training. Training in product and tech. Training on culture: US business culture—for example, US understanding of urgency and honesty versus saving face. The infrastructure of communication. All of this is to achieve an easier communication rapport and build trust at every step.
First, the easiest parts of the training, that I’ve found, are the project process, the product, and technology. Although this gets
the lion’s share of time, in the end, there are equally substantial facets necessary to the training process.
The surface need always seems to be training in tech and— in particular—training on how the project work (sprints, phases, approvals, deadlines, docs/artifacts, etc.) or other normal project processes.
This is important—there is no denying that at this point, it is crucial for the home office to spend time with the distributed team—not sending over a user’s manual or tech spec to read. Training is not effectively implemented through a user’s manual or tech spec, but rather by granting people the time to discover and question the product and persona.
By investing in training on the product and technology, you give the team the opportunity to ask questions, read between the lines on company goals, ask about users and workflows, learn the names of other staff, and become familiar with team and team process. This is essential. Investing time at the beginning of the project is much more important than just tech training; that is, opening lines of communications, getting personal, beginning rapport, and building trust.
Recognize cultural differences
Second, is culture, it is more important to share with the teams: your company values, business culture (including US business culture), and work habits to build communication infrastructure.
Topics such as “time,” being on-time and the culture of time: urgency, prioritizing, and reprioritizing are virtues that are not universally understood. American business has different values on these topics. With globalization, some people think that these issues have gone away, but they have not.
Different cultures have vastly different perceptions of time and urgency. Why the focus on rapport and trust? To me, it’s obvious—you get all the communication and information you need when asked for.
When the pressure hits, what will save you? With little rapport and little trust, there will be secrets and over-formalized demeanor or “just the facts” being given as well as blaming and finger-pointing.
But, when you have a good rapport, and teams have the ability to speak honestly with one another—without fear, without losing face, the pressure can be minimized. This is done by putting project priorities first and personalities last (these are big parts of the American business culture that must be taught), this allows issues to be more easily resolved.
Having an open communication channel, communication infrastructure, and cultural understanding is a must for trust.
Take advantage of face-to-face interaction when you can
It is also necessary to develop a communication infrastructure. Luckily, technology has given us the tools to make the process of managing and leading easier. It was not too long ago when many organizations began outsourcing without access to these tools. Skype, Google Hangouts, FaceTime, and bigger tools like GoToMeeting and MS Lync; all of these tools make your life easier. Time differences will complicate communication. Depending on your locations, time differences can make your work miserable. Modern tech companies are famous for being flexible. I hope that if you have a vast time difference, your organization supports you with flexible hours to accommodate.
Hopefully, these three points are obvious, particularly the cross-cultural aspect.
Now, let’s take a step back. What is the goal of distributing the work? This goal impacts the time you spend building rapport, building trust, and will impact decisions made during an on-site visit.
How the length of an engagement will impact on communication
Let’s consider two extremes: a short-term project and a one-time engagement.
Events often proceed as follows: the home office will throw a bunch of hours into testing the
product, and perhaps a specific tech job for the distributed team to take on, such as pre-developed tests and running them across an array of browsers/devices/servers/etc. When completed, pass it back to the home office then release. When that job is done, the relationship follows suit, and they are both finished.
Clearly, the time invested in relationship-building will reflect this “one and done” goal.
On the other extreme is engaging a partner with your company’s captive staff at a different location or an outsourced team, who will be long-term and not only used for a single task or project. In this position, they are expected to act as regular team members—even if the scope of their work is narrow to start.
Wherever your work falls between these two extremes, it’s vital to gauge the time devoted to building relationships. Its importance cannot be under-valued.
Rapport and trust
Building rapport can be tough, especially when we consider different locations. One of the great benefits of a site visit is the time spent together—whether it is “downloading” all kinds of work details and training on project processes, or having lunch together every day. They are equally important.
I hope the following two stories illustrate outcomes for you to choose from.
I have one priceless story to share. The home office lead in the US called the offshore team lead in Asia every night. The home office lead in the US was a bit bothered by having to work at night during her free time—who wouldn’t be? As the project progressed, the calls occurred a few times a week, but the troubling part began on Sunday nights, US time/Monday morning in Asia, to focus on any new priorities and get the week started right. The conversations were short and crisp, with just the facts. When there were issues, as with all projects, things became tense. The offshore lead could not “read” the US lead’s body language, voice or tone well.
The US lead was often frustrated by silence on the other end of the line. As time passed, teams and people got into ruts. All in all, things were “fine”—okay at best.
One Sunday night, the US Lead sent an email to the offshore team lead: “My dog is sick. I am at the vet. We can’t talk tonight.” The response: “Don’t worry. I know what we have to do. Don’t worry about us.”
The offshore lead made sure that that day’s work was complete, everything was done and updated, and status sent on time. When they finally connected directly, the offshore lead asked about the dog and the home office lead filled her in. The offshore lead shared, “I have a dog also. I worry about her when I have to work late and she is alone too long,” They shared pictures of their dogs, and thus, after 9 months, broke the ice. They began to have more relaxed conversations. The commonality of having a dog had long-term effects on the communication between the leads, the offshore lead felt that she could “read” the home office lead’s tone much better than before.
The silence in the conversations disappeared and the two were able to discuss projects with ease. The home office lead began sending an email on Sunday evenings (US-time) asking, “Do you know the focus for Monday? All set? If yes, let’s skip our call, if you need anything—I am happy to talk.” Trust was building and the home office lead got her Sunday nights back.
We can’t forget software development is a human effort. Rapport is essential and cannot be incidental. When we are in the same office, we can communicate so much easier because we are able to read body language, tone, office culture, etc. When teams are not co-located, those communication mechanisms remain important but take longer to build.
Giving time and attention to relationship-building and cross-cultural understanding builds trust. So does a good work product, but a good work product does not happen in a vacuum. It also does not only happen from transmission of requirements and project process. It’s human.
With stories like this arising more than anyone would like to admit, we can easily draw these conclusions; invest in time with the distributed team. Sure, continue training on process and product, but don’t forget the human side. Build rapport and trust, and you will have a great success story.
On the opposite end, we have a story with a not-so-happy ending. A US company invested in opening a remote location office and hired a bunch of competent local staff members 12 time zones away. Training was done, site visits happened on both sides—staff from the home office went to the remote office, and staff from the distributed team went to the home office. Investments were made. They were off to a good start. There were only a couple of minor issues.
During the first year, there was some turnover in both of
fices: people being moved to different projects, one leaving the company, and one was on maternity leave. With the time difference, both teams did not attend the daily standup, which caused a gap in communication. Communication breakdown ensued. Some information was missed or simply not passed on to the other team. Established communication protocols were not followed because people were “busy.”
This resulted in a project problem and an important ship date was missed. There was finger-pointing and hurt feelings, followed by mistrust. The good feeling and good work product evaporated. The “mood” in the home office caused a reluctance to work with the remote office.
Moving forward, things got worse, the remote team received tedious, non-critical work. Their attitudes became unmotivated. In a hot tech market, within months, many engineers on the offshore team left for another company. After a very big investment in opening a new office, the company hired great staff, and after two years, lost all the trained staff.
The company was stuck with a shell of an office, infrastructure, servers, etc. because people ignored communication agreements, got lazy, and began blaming each other. The dynamics in the home office team never recovered and they were left with a bad reputation.
Summary
Don’t let this happen to you! When leading offshore teams, extensive and hands-on training is essential. Focusing only on tech or product training is a mistake as you will be left with a team without communication infrastructure. There will also be a large gap in trust and understanding between the home office and offshore office. Be sure that both teams comprehend the company culture and business culture. Balancing tech/product training with training focused on communication, communication infrastructure, as well as company and business culture is crucial to the long-term success of your company’s decision to offshore.
Invest time in site visits to open lines of communication and build trust. Site visits also help your offshore team associate a personality and face to the person (or people) that they’ve virtually corresponded with countless times. Instead of only being an email and name, you become a person that they know. Think more about building a partnership with the team that has shared goals and open communication, regardless of whether the engagement is short–term or long-term. Ensure the expectations of the offshore team are clear. Both teams, home and offshore, must know that the offshore team members are expected to act as regular members—even if the initial scope of their work is narrow. By setting a standard for offshore members, you establish their role within the company and with the home office. Not only does this result in a better quality work product, it’ll allow you to hit your pillow earlier.
