Succeeding With Remote Development
One of the most common situations today is where the product manager is in one location, and the engineering team is somewhere else. I don’t only mean outsourcing to India either – the remote development team might be a consequence of an acquisition or merger, or possibly your organization is large enough where the developers are centrally located in a facility somewhere you aren’t.
When the developers are not sitting right next to you, then all of the normal challenges of communication and execution are magnified, often to the point where many teams get extremely frustrated with remote development, and some challenge the benefits of the perceived cost savings.
I have written earlier about some of the problems that come with outsourcing for the wrong reasons, but whatever the cause, if you find yourself with a remote development team, there are three critical things you can do to dramatically improve your odds of success:
1) The further away the team is from you, and the more the communication challenges of language, culture and time zones, the more pressure there is to ensure that you have done a very good job on the product spec. The nightmare project is where the product manager isn’t sure what he wants built (or keeps changing his mind) and the remote engineering team is thrashing. It’s like being on the wrong end of a whip. In the last article I wrote about the importance of a high-fidelity prototype as the basis of the product spec. I won’t repeat all the reasons for that here, but suffice it to say that if your team is remote, you absolutely positively want to make sure you use the high-fidelity prototype as your main communication mechanism. Both for communicating the actual spec, and for communicating changes. Written documents are hard enough to get people to read, but if it’s written in a language that isn’t native, and if you don’t have the author in the cube down the hall to interpret it to you, you’re just asking for big trouble.
2) When a development team is local, if there are resource conflicts (for example, two different managers give conflicting instructions) then this is typically caught quickly and resolved. With remote teams, you end up getting lots of unpleasant surprises, and literally months can pass before the disconnects are identified. This is usually because the remote developers are forced to make assumptions about who wanted what and how to interpret the various instructions, and the assumptions are rarely correct. It is critical to have someone local manage all coordination with the remote team. This doesn’t mean that all communication should be funneled through this person, but there should be no question as to who the engineering team is accountable to. Sometimes this is a project manager (aka program manager) and sometimes this is a director or VP of engineering that is based locally (near the product manager).
3) There are so many good communication mechanisms now. In addition to e-mail and instant messaging, video conferencing is much better, and VoIP has brought the costs way down for international calls. That said, there still is no substitute for establishing the personal relationships. At least once a quarter, the product manager should get out to the engineering team, meet with the key architects and managers, and spend some quality face time. This will improve all the other forms of communication. Another great technique here is to have an exchange program where key developers come stay with you for a while, and you go there for a while.
If you have a talented remote team, and if you are managing the relationship as I’ve described, you can actually come to enjoy this arrangement. Especially with engineers based in India, the time difference can make it such that every morning when you come in you see progress waiting for you, and you can spend your day (and their night) reviewing and testing and providing feedback. The result can actually be extremely fast cycle times.
Note that you can also have your prototyping resources remote as well, but you’ll have to work a little harder on the communication and be more flexible on your hours, because of the very quick cycle times (several iterations a day).
Yet another solution to the problems of dealing with a remote development team involves locating the entire product team together in the remote location. I see this trend just starting, but I think it will be profound. That said, you don’t have have to worry about this just yet. It has taken 10 years to develop the engineering and QA capabilities in these remote locations, and it’ll likely take another 10 before these locations have skilled product managers and designers as well. But that’s a topic for a future article.
