We talk about marketing for start-ups and tech companies but did you know that we are talking from experience? We drink our own champagne: Turbine is a software start-up and a subsidiary of my marketing company, Articulate.
Although Turbine is based in London, England, we built the application using outsourced, mostly offshore talent. The main development was done by a company in Ukraine called Anadea. We also used testers in Romania, web developers in Argentina and AdWords consultants in Austria, among others.
For the most part, it worked very well. But I learned a lot and this article outlines some of those lessons for anyone thinking of going down the same road.
Offshore is good
Fundamentally, there is no difference between a programmer (or a designer or a tester) based in an office in London and one in another part of the world. They’re either good or bad, talented or useless, collaborative or ego-centric.
What does change is that they are often cheaper and you get access to a much wider pool of talent. This is why I’ve said before that Turbine wouldn’t have been possible without it. Going offshore is nothing to be embarrassed about. In fact, most of the applications you use every day were built ‘offshore’.
Your job is the same whether you work with people in the same building or people on the same planet: find the right developers, brief them properly and manage the project well.
In my time, I’ve interviewed hundreds of programmers. There are three secrets to hiring a great developer every time but nobody knows what they are. However, there is already some good advice on the web that will help you reduce the risk of hiring a terrible one:
- Basecamp’s advice on How to hire a programmer when you’re not a programmer.
- Laurie Voss’s advice about why you never end up hiring good developers.
- Jeff Atwood’s How to Hire a Programmer.
- Elance’s guide to hiring a developer.
My experience suggests that when working with offshore developers (and programmers in general), there are a few traits to look out for:
- Communication. An ability to communicate clearly about technical issues in a language you understand. For example, they explain the pros and cons of different approaches.
- Context. They see the project as a whole instead of focusing on some obscure technical detail or vanity project or intellectual obsession. For example, they talk about pieces of programming in terms of the improvements they deliver to users.
- Methodology. The right approach to programming is critical. When I was interviewing for Turbine initially, most developers wanted a very detailed specification and approached projects in a ‘you-asked-for-it, you-got-it’ way. I preferred a more agile approach.
- Prototype. You should plan on building a prototype with them – a minimum viable product that takes less than a month to build – before committing to a long term relationship. They should welcome this. Plan on throwing it away and starting again, with them or with someone else.
- Pricing. They may not be able to give you a fixed price but they should give you a very clear idea of what their prices are, how they will charge and how you will pay them. If they quote a price per hour or per day, find out how long that price will be in effect. It’s no point signing up at $40 an hour and then they double the prices on you three months later.
- Team. If you’re working with an outsourcing provider rather than hiring individuals, you should aim for a certain amount of team stability. Who is working on your project? For how long? Can you meet them (virtually or otherwise) before you commit?
- Project management. They should have a good story to tell about how they will track and manage the implementation. What tools do they use? What methodology do they follow? What do they expect from you?
Getting the brief right
The initial specification for your product is the constitution and foundation of your relationship with software developers. It’s important for what it says but it is also important because of the way you say it.
Looking back, I think the original Turbine specific was too detailed and too comprehensive. It was 22 pages and should have been five pages. We could have easily launched the application with a quarter of the functionality we had at launch. That would have allowed us to launch sooner, get feedback faster and focus our work on features that mattered to users.
As I’ve said before, non-existent code doesn’t crash. It also doesn’t cost anything to write.
My top tip: once you’ve written a specification or brief for a developer, go through it line by line and delete everything that is not absolutely necessary. Less is definitely more.
It’s better to work collaboratively with your developers to figure out the best way to implement and design functionality. Your job is to be the champion of the compelling, unique features of your app and the guardian against gold-plating.
37 Signals’ Getting Real is essential reading before you start this process. As is Eric Ries’s Lean Startup. I read them both but, looking back, I don’t think I really paid enough attention. So, my advice is to read them twice!
Managing remote developers
I’ve written before about project management in general but here are some of the things that worked for us doing offshore development on Turbine:
- Seeing is believing. After a rough patch in the relationship, we started doing video conferences using Skype and then Google Hangouts. This made a huge improvement in the quality of the relationship – we were more communicative and trusting once we started using video. Aim to have at least one video conference a week.
- Talk about the weather. Seriously. Make a bit of small talk. Treat one another as human beings. It builds up a reservoir of mutual understanding.
- Emails. Have the developers send you a daily wrap-up email. What were they working on, what problems did they have, what do they need etc. It shouldn’t be a formal report. A short, friendly email is very helpful for keeping the channels open.
- Address problems early. Distance amplifies stress. If you feel like there’s a problem, address it as soon as possible, preferably on the phone or via video conference not via email.
- Use export English. You should be working with developers who can speak and write English to a reasonable standard but remember to speak slowly, use simple words and avoid idiomatic language if you want to be clearly understood.
- Put it in writing. Verbal communications should also be captured in writing, ideally using a project management tool like Basecamp or Pivotal Tracker or a bug tracking tool like Lighthouse.
- Don’t interrupt. Programmers need to concentrate so avoid interrupting them. Use the tools they prefer for communication. Generally, IM and email are better than an unscheduled phone or video call.
Let’s compare notes. Comment here or contact us with your feedback. If you’re working on an app, drop me a line and let me know how you’re getting on.