Ronin helps you build high quality remote engineering teams. We personally interview and train each engineer we work with to ensure that you’re getting the best engineers from around the world. Send me a note and I’ll try to help you out: weston at roninrecruiting dot com.
Below is a blog post I wrote about my experience working with remote engineers:
How to work with a remote team – 5 Rules
I’ve worked with an development team of 8 in Argentina since 2011, and I’ve learned a whole heck of a lot in the process. Here are my 5 most important rules:
Rule 1: Don’t call it outsourcing.
Frame the relationship as a “remote” team joining your local team, not an outsourced group doing mercenary work. The difference is immense, for both the local and the remote team.
Do: treat your people the same, no matter where they work.
Rule 2: Over-communicate.
Communication is key in any relationship, but it’s especially key when you don’t see each other face to face every day. Make an effort to get to know the people you work with, in the same way you’d do with your local coworkers.
On top of that, most issues with remote teams stem from a violation of trust. Communicate early and often to establish and grow that trust.
Do: 15 minute daily engineering stand ups and incorporate an Agile system with week-long sprints.
Rule 3: Define the culture – the best management is self-management
Establish and encourage a culture of responsibility. Set up the system correctly, and trust in your people, and you’ll be amazed at what gets accomplished above and beyond your expectations.
Do: make people own their work.
Rule 4: Invest in people
Why do people like to work at google? Because google invests heavily in its most valuable asset – the employees. Do the same, whether it means professional development, english lessons, or one-on-one feedback.
Do: make people want to continue doing good work for you.
Rule 5: Choose the least-bad tools
There isn’t (to the best of my knowledge) a great all-in-one tool for managing small teams, let alone remote teams, so until someone makes that, you’ll have to do with a few good stand-ins.
Scrum – I highly recommend some form of agile product development system in place. We used a weekly sprint, combined with daily 15min scrum calls, and did monthly product development cycles. Key takeaway: there is no perfect system, so run with what works. Always be shipping.
Do: not reinvent the wheel, use existing tools that get you 80% of what you want without much additional investment.