Spending time on various projects, from social games to B2B services, I work with a lot of offshore developers. Many people have heard about services like ODesk and Rent A Coder and ask me how to get started. The short answer is: carefully. The long answer is below.
Bad engineering is a mess that can take forever to clean up, if it can ever be cleaned up. Bad development practices mean everything from bad naming in database tables and code variables, to lack of scalability, to, generally speaking, code that can’t be read or maintained.
Conversely, a world-class developer can practically read your mind, seems to be always one step ahead of you, and has suggestions for both design and architecture. When it comes to offshore development, great developers treat the code and your project overall as if it were their own. They think about maintainability, scalability, and design.
Are You Technical?
This is the first and key question for many people thinking about using Odesk, Rent A Coder, or other services. If you are, you can write detailed technical specs, review code that gets written, and provide detailed feedback to developers. If you’re not, you must find someone technical you can trust to fill that role. That trusted technical peer can be an engineer you hire, or a local colleague or friend.
Have you managed a software development project? It is one thing to have someone knock out a prototype. It is another to build something scalable and maintainable.
A Clear Vision
If you have already done market or user research to confirm people want what you intend to build (see: Lean Startup!) – that is a big if – you need a clear vision of what you want to build. By clear, I mean you can write down in a sentence or two what the goal of your product is and why people will want it.
Design First, Implement Second
A clear vision also means you can draw, in pictures, the screens for your product. If you’re building a game, for example, you have clear views on the game elements, goals for the players to achieve, and specific graphics. For a web site, you have a view on everything from the overall goal, to the messages that will appear on the home page, to the flow of the site, to the individual pages and the look and feel of the buttons. Yes – all the way from the big vision down to the size, shape, and color of the Pay button. When you think product design, channel your inner Steve Jobs.
Odds are, you will not have good success with the first developer you choose. Don’t hang on. Don’t hope it will get better. Look at the data, then act on it.
Ratings matter. Rarely should you expect to have success with an engineer who has multiple failed projects, negative reviews, or arbitrations. When choosing developers, look for those who have clocked multiple successful projects on Rent A Coder or hundreds if not thousands of positive hours on oDesk. Tempting as it may be to hire the first developer or development team that responds to your project, it’s better to wait and find greatness than settle and ultimately have to restart the project.
If you send a message to a developer and don’t hear back for days, don’t hope it’s going to get better. It’s not. If the UI of the prototype you get looks terrible, don’t assume the developer knows that and is going to tune it up. If your developer fails to pay attention to details, despite your enumerating what those details are, that developer is clearly not into the details. Again, look at the data.
If you have specific ideas – and you should – on what the UI should look like, mock up the individual screens down to the very last detail. If you don’t do this, don’t be surprised when the design you get back is not anything like what you had in mind!
Of course, the best place to find great engineers is other great engineers. Don’t settle until you find a great engineer. You will know the developer is great because the work you get back shines. It puts a smile on your face. The developer clearly takes pride in his or her work. It’s obvious. Now, ask that developer if they have friends or colleagues who are looking for work. Hire them. Some will work out, some will not. Hold onto the good ones.
A note on large development shops: although people do have success with these, you really have to get lucky. What’s more, these developers are much more likely to work a fixed schedule and not have the flexibility you need to make a project successful when you go from prototype to product. Likely you will have better success with individual developers, smaller shops, or loosely associated smaller groups of developers.
Managing The Project
To manage a real project, large or small, you must have tools: tools for communicating, collaborating, tracking, and reporting. Assembla, Basecamp, Unfuddle… there are many tools to choose from. Upload mockups to your wiki. As items are completed, test and ticket. Stay on top of completed work, don’t let it linger. Spec out big features, but break them down into smaller pieces to get them done.
No matter what you do, you are sure to encounter The Case of The Missing Developer! No – this is not some modern day Sherlock Holmes story. This is when a developer that seems to have been making great progress disappears. No email, no code check-in, simply poof. This is because many developers on Odesk and Rent A Coder are working multiple jobs, are in school, simply lose interest, or have things happen that get in the way.
A significant challenge for developers is that they don’t know if your project is going to be around long-term so it’s hard to commit to your project full time. Once they’ve spent time working with you, and you’ve proven to be a reliable and consistent source of income and someone they enjoy working with, they’re more likely to dedicate themselves to your project 100%.
This leads to the other key aspect of project management – it’s a two-way street. Treat developers well, take the time to explain the rationale for your designs or approach, and you’re far more likely to get great results in return.
There are multiple approaches to resource management. You can do the whole project offshore. This is very hard to do unless you have worked with the team before. An excellent approach is to build the core with a local engineering team, with modules built by offshore resources. It depends on the size and scale of what you’re trying to accomplish. All that said, be clear with your expectations and then look and act on the data. If the project is not going well, it’s time to reevaluate the team, the project, or both. If it is, then scale, scale, scale!
One of the biggest challenges every startup faces is switching from startup phase to scale phase. In the true startup phase, you’re throwing a ton of stuff at the wall all the time and seeing what sticks. Before you have users or customers in volume, you have to think about repeatability and scalability.
To think about and implement things like test and production environments, scaling, redundancy and the like, you need multiple engineers and engineers with different primary skillsets. You cannot scale on one outsourced developer and probably not even on one outsourced development team. The challenge with relying on a single outsourced team is much like the challenge of relying on a single outsourced developer: you have a single point of failure.
This is where many people who start out with ODesk, Rent A Coder, or other services run into challenges. Simply put, more scale requires more resources. It is by no means linear (Facebook: 2,000 people, 600M users), but scale requires people.
If things seem to be taking too long, you need different engineers, more engineers, or, it’s time to face the reality that your project is too complex. Go back to the KISS rule, that is: Keep It Simple, Stupid!
Complex projects stay “in the garage” for a long time. They don’t see the light of day and they fail to get user feedback. Then, when they’re put out on the market, they flop. What’s more, they’re hard to maintain and iterate. Focus on core features. Get users. Get feedback. Repeat.
Great projects, like great entrepreneurs, get feedback early and often. There is significant feature failure as they iterate and determine what works and what doesn’t.
The Timezone Challenge
Many people ask how they can communicate with engineers who are twelve hours off from them. The answer is get up early, stay up late, or do both. Document what you want done. Schedule a regular Skype call or IM catch up one to two times every week. Reliability and consistency on your end will produce the same in the developers with whom you work.
One tradeoff with offshore development is that it is that much harder to whiteboard out an idea or make a quick change. It requires more management overhead. You are dealing with different timezones and must have clarity on what you have in mind in significant detail. That does not mean writing age-old 100 page specs. It does mean, however, that a quick spec – a brief writeup in a wiki page plus a drawing, by hand or on the computer – goes a very long way.
Much has been written about the pro’s and con’s of using offshore development resources. Whether to use these development resources is up to you, but should you decide to, you now have one more resource to help you get started.
Services like Rent-A-Coder, eLance, and oDesk have long held the promise of distributed and efficient work resources. With communication and collaboration tools easily accessible and hosted, just like the products they’re helping to build, such promise is fast becoming a reality. Of course, building a product is only half the battle. Getting people to use it is another story!
A great pitch is all about telling a great story well. Recently, a number of entrepreneurs have asked me to help them with their pitch, business strategy, and market positioning. An avid short story writer since a young age, there are few things I enjoy more than helping technology entrepreneurs tell their stories. It’s even more fun when that coincides with a financing or liquidity event.
As an investor, I’ve seen hundreds of pitches. As an entrepreneur, I’ve put together more than a few myself. I never thought that might be an avocation, however, until I was reminded by an entrepreneur friend of mine, “You basically wrote our Series B pitch in 15 minutes on the whiteboard.” He raised eight figures the next week. Then, I was meeting with the founder of a highly in-demand company several weeks ago. “Help me build my pitch. It’s what you do.”
Tech, as I wrote in response to a WSJ article in January, is hot again, and it’s likely that we have about three more good years ahead of us. What happens after that is anyone’s guess. That means raise big now with the implied goal of getting public, position to get bought, or plan on digging in for seven to 10 years through another cycle.
Raise big. To raise big dollars on a big valuation, you have to be hot. In a momentum market like the one we’re in, hot comes down to massive reach, massive revenue, or massive disruption.
You can also, of course, raise money on the promise of massive disruption. If you’re doing that, you need a catalyst. Something that wasn’t here a few years ago, that enables you to disrupt massively and quickly. iPads, location-aware smart phones, and pervasive social graphs are all good examples.
Get bought. To get bought, you have to be visible. As Steve Blank said, in the new bubble, “you need to be everywhere and look larger than life.” Of course, you also need to be in an area buyers care about. Corp dev execs flush with cash or high valuations are making two kinds of buys right now: talent and traction.
It’s not enough to have a great story alone or to be a great story teller. You have to have a great story and tell it well. Do that, and whether you want to raise big or get bought, you’ll accomplish your goal.
- April 2013
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- November 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- November 2010
- September 2010
- August 2010
- July 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- March 2009
- December 2008
- November 2008
- October 2008
- August 2008
- July 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- March 2006
- December 2005
- October 2005
- July 2005
- May 2005
- April 2005
- February 2005
- November 2004
- October 2004
- September 2004
- August 2004