Best Practices for Remote Dev Offices

As I mentioned in my last post, there's no doubt that managing developers in remote offices is tough. Here are some things that I try to do, which have helped:

1. Build trust. It's astonishing how much more gets done when teams trust each other. Two tactical recommendations along these lines:
   
   1. Travel. There's no substitute for butts on airplane seats. Debating database architecture long distance has an entirely different tone if the person at the far end of the call took twenty bucks off you at poker two weeks ago.
      
   2. Use video-conferencing. A person's face takes up more room in your brain than their voice. Plus, you're less tempted to check email while they're talking. We use the Polycom VSX system for our conference rooms and Polycom PVX for our desktops; the UI is annoying and buggy on both, and I have ongoing problems with the desktop audio, so I can't really recommend it, but it works better than just a phone call.
      
2. Communicate. Schedule regular 1:1 meetings with as many people at the remote office as possible. If folks at our Tel Aviv office stay late, and folks at our Bellevue office come in early, we can get maybe 8 hours of overlap a week. I try to have all 8 of those hours filled with meetings; usually, I'm about half successful.
   
3. Adopt the same processes, and fairly quickly. Two keys to doing this:
   
   1. Pick one set of processes and have the other office/company adopt it. Normally the dev process that will be chosen is, naturally enough, the acquiring company's. But don't just have an argument about processes in the abstract, or try to merge the two. Pick one, and move on it. If you're the acquiring company, be open to adjusting your own processes based on the other company's best practices – but everyone should expect that one set of processes will provide the framework for the discussion.
      
   2. Structure the organization at the remote office to support the process changes. You need to have people on the ground who have bought into the new processes wholeheartedly, and are willing to fight for them. Sometimes the only way this can happen is to bring in new people (e.g., product or project managers), who aren't wedded to the old way of doing things.
      
4. Choose the right managers. Managing remote team members is a difficult skill, and it needs to be learned. Just because a manager has been a success with local team members doesn't mean they'll be successful with remote employees. (I'm a great example of this.) If someone hasn't managed remote employees successfully before, keep a close eye out for problems, and step in quickly. This is a good opportunity for mentoring.
   
5. Be very patient. To a much greater extent than you can know, you don't understand the context for decisions made in remote offices. Always give them the benefit of the doubt. Sometimes that benefit isn't deserved, but in the end you'll get further (and be right more often) if your assumption is, "There must be something I don't understand," and not, "That was stupid."