Last Updated Aug 10, 2015 — App Management expert
When Offshore Works
In the last dozen years, I have been involved in several offshore development relationships, and most of them have been failures. Working in small companies, it is inevitable that at some point a board member will insist that an offshore team be engaged “to save cost.” At a few different companies where I worked, this resulted in half-hearted attempts at outsourcing, where a team was hired, some work was given, and the results were less than ideal. Cost savings were perhaps there on paper, but in terms of the cost of real output, nothing was saved.
When Apperian decided to engage an offshore team, it started the same way, as an effort to save costs since engineers in Boston are expensive. This time I decided to see if it would be possible to actually make the relationship be effective, with a productive team and real savings. There were three areas that I thought required careful focus: time zone, culture, and communication.
Time Zone Overlap
For the time zone, I wanted to have a team whose workday overlapped with ours. We considered anything in North or South America, and Europe. Having worked with several teams that had no natural overlap, it doesn’t work well. There is always a delay in getting questions answered, so work often progresses too slowly. Also, it frequently results in someone having to work at night, often on both sides.
I thought culture was an important consideration, because of some previous experiences that hadn’t worked well. One of them involved hiring an offshore team to develop a specific piece of software. We had a strong idea of what we wanted, and worked with an onshore/offshore company so that we had a local architect to work with. We did what seemed like a good design, and they built it. The problems came when the software was delivered. There had been some poor assumptions on our part, and while the team figured out that some things made no sense, they followed the original instructions instead of pushing back. The final software met the original requirements, but wasn’t exactly what we needed, and the code quality was poor. It did exactly what the spec said, but was not built to be extensible. For Apperian, I wanted a team with a culture of close cooperation. I wanted people who would question us, push back, and suggest better solutions.
After evaluating several options, we chose a team in Europe. Our time overlap includes most of our morning, which gives us enough time for online collaboration and some shared meetings. They have a culture of smart, opinionated people who have no problem telling us what they think. I felt like the chances of making this work were pretty good.
The last issue to be dealt with was communication. This proved to be harder than I thought. First, we budgeted for travel so that we could send people there, and bring some of their people here, a few times each year. We also carefully crafted a meeting schedule that allowed us to meet pretty frequently. It started off well, but for a while there was a lot of grumbling in the Boston team about the work being done remotely. People thought that the quality wasn’t good enough, and that some of their decisions didn’t make sense. I was frequently asked why we were using offshore instead of just hiring local people.
The problem turned out to be the frequency and type of communication. Smart people given a task will make decisions, and with a lack of full information, they will make decisions that don’t necessarily align with your goals. We had to adapt a bit to create the right type of culture. The key was to introduce things like online collaboration tools and more frequent small meetings to make sure that requirements are clear and questions are answered promptly. The other piece was getting some familiarity between the people on both sides. Even with smart, outgoing people on the remote team, until they had some personal relationship with the people here, they were reluctant to reach out via online collaboration tools. We’ve had to work to build those relationships, through on-site visits, and collaborative meetings.
An Effective Offshore Relationship
The other thing we did that I think made a huge difference was to treat the offshore team as a team of equals, not as a team of subordinates. We didn’t give them the crap work, we tried to share work more equally. Both teams get interesting things to work on, and both teams do some of the less fun things. The benefits to this approach include greater satisfaction and deeper product knowledge on the remote team, and a local team that treats the remote guys with respect.
The result has been the first effective offshore relationship that I’ve been involved with. It requires constant effort, but the results are worth it. The quality of the work is good, the cost makes sense for the company, and the effort we put into it is much less than the benefit we receive. It is also fun to be a part of the exchange of cultures that happens on the personal side. I don’t believe that offshore always makes sense, and I think that startups often take it on for the wrong reasons. But I do think it can be made to be effective.