US-based technology companies are working at a fever pitch to recruit the best talent available. I live in Seattle where many Silicon Valley-based firms, including Google and Facebook, have opened offices to tap into the wealth of local talent that companies like Microsoft and Amazon enjoy here. Another growing trend is to hire offshore talent to fill those critical engineering roles which cannot be filled quickly enough here and, perhaps more importantly, is significantly cheaper. In the latter case, firms are faced with blending onshore and offshore resources together to work as seamlessly and as efficiently as possible.
As a product manager who has managed offshore development teams, I’ve learned that it’s not easy, and that having engineering teams on the other side of the world is not always congruent with delivering great products.
What are the Positives?
One of the biggest challenges of offshore development is of course is the time difference, but this can also be a positive factor. When I was a product manager at CDK Global here in Seattle, the majority of the engineering team was based in Bangalore and Pune, India. This is a 12-and-a-half-hour time difference between the local office and these teams. The biggest benefit arising from this time difference is that you can have around-the-clock development. I loved the fact thatI could fire off inquiries to my India team before I left work in the evening and have responses or testable code waiting for me when I logged in the next morning. More than once this resulted in critical issues being resolved while I was sleeping.
Other positives are that offshore teams bring in a different set of personalities, experiences and skill sets to the table, which often contrast with your local team. This results in new ideas and differing viewpoints about how to solve complex problems. Equally positive for me is gaining experience working with an entirely different group of people, and learning a bit about their culture and lives compared to your own.
What are the Downsides?
Well, they are not local and it’s hard to put a face to a name. There is also the time difference. You cannot work through JIRA and email alone. At some point, you have to speak with the offshore team on the phone, which means your work day gets extended. If you are working long days, the last thing you want to do is get on the phone at 10pm at night or early in the morning. It’s mentally taxing and you won’t always think clearly and be as focused as you should be.
Another potential downside is culture. The hard part here is that it takes time to learn and understand who your team is, what makes them tick and how you can best leverage this for team success. Language and accents are a prime example. It can be frustrating when someone is trying to explain something important over a bad telephone or IP connection, and they are speaking with a strong accent and speaking faster than you are used to.
Another obstacle tied to culture which I’ve encountered is the pace of work. What’s acceptable or expected in your own country or local office in terms of expected time to complete work stories can be widely different in the remote country. I’ve had remote engineers take twice as long to complete similarly estimated stories than my local devs. Most often this is because they approach it differently – for example they may take more time upfront to do initial research on approaches before committing to writing code. This is not necessarily a bad thing. You just have to account for it and set expectations accordingly.
Remote teams may also feel they come second just based on the fact that they are “the other team”. They do not see and hear the same things your onshore team does in the office, typically where upper management resides and makes key decisions. In the worst cases this can lead to disengagement and indifference which leads to inefficiency and not working smartly.
To make sure you are best situated to handle working with an offshore team, consider the following:
A Recipe for Offshore Development Success
Get to know them and make sure they know you. Initially, my approach was to establish relationships with the lead devs only, and rely on them to communicate with the others, but this leads to hierarchy and gives people the impression you cannot be engaged directly, which is silly. Knowing each developer reaps benefits when a critical release or issue is on the line. One easy way to do this is to engage people over services like HipChat or Jabber on a regular basis for routine questions or ideas you’d like to discuss.
Keep them informed. Not just about the team, but about the company as well. Remote teams appreciate hearing news they might normally not hear or might only read about in a company-wide email. My remote teams appreciated hearing about the larger aspects of our current project, like customer roll-outs and milestones.
Establish routines and make sure you meet regularly. It’s difficult to have daily stand-ups with both your remote team and your local team at the same time. To compensate, create separate stand-ups for your remote team and, if necessary, bring your local lead into these. This can be time consuming if you do it daily, but even two or three times a week is greatly beneficial, and outside of meeting face-to-face, ‘meeting’ on the phone, through Skype or other meeting tools is your next best option.
Leverage your tools. If you use Confluence, JIRA or other similar tools for requirements and status, make sure your remote teams have full access to these and use them as the basis for each meeting to go through story details, status and roadmap items. This also holds each team member accountable for stories assigned to them, no matter where they reside.
Make sure you are fully aligned with your remote team lead. There have been a number of times when a good relationship with my remote dev lead really helped in solving priority changes or emergencies, which both crop up from time to time. I made a point to meet with him separately each week to discuss issues and priorities for the next upcoming sprint or two. If your remote dev manager is not responsive or otherwise seems uninterested in regular communicating and building a relationship, let your manager know about this immediately. It’s that important.
Make sure your local dev team is engaged. More often than not, your local dev manager will have a direct relationship with the remote manager. This is important because it gives your remote team a conduit to discuss issues and options which are better resolved directly with other developers, not product people.
Hold semi-frequent all-team meetings. Bring your local and remote teams together once a quarter to have open-ended discussions about what’s working, what’s not and what’s coming down the pipe.
While my experience comes from working in the US, I think these guidelines are relevant no matter where in the world you and your remote team are based. Every organization and team will have different strategies for keeping remote teams engaged. Work with your manager and co-product managers to get their input on what’s worked best for them. At the end of the day, it’s about getting the right work done and keeping your customers happy. This is difficult to do if your not in sync with the people who write the code and bring your products to life.
Comments 0