I think we need a new show on YouTube: “So you think you can code?”. That would be great, right? get some insight into the mystical art of code engineering / development. What I would hope founders would learn, is how to spot the superstars and how to spot the chumps.
When you’re a non-technical founder, it’s a treacherous path to plot (disclaimer: I’m a product, design, and peoples guy – not a technical founder). I have personally had some limited success to date with outsourcing developers in a startup, but more horror stories than success.
This post will be in a few parts as there is much to cover and I want to stay focused.
So what do you do when you can’t look at the outsourced code and tell if it’s any good?
Here’s a few simple tips:
1. Hire based on PEOPLE. Investments are made more on the team culture and personality these days… An “A” team can take “B” projects to huge success, but a “B” team can totally trash an “A”-class product. Especially when outsourcing developers, when your gut tells you no. SAY NO. I have had very few experiences where I didn’t listen to my first instinct and they all came back to bite me on the proverbial butt. Trust your instinct.
2. Get someone to help you vet the workmanship. See if you can hire a highly skilled developer to take a quick gander at the project as it evolves.
3. DEADLINES. PENALTIES. Mitigate your risk. Set hard deadlines which the developers need to adhere to and agree to in writing. Create a penalty system in the event that work is not delivered. Don’t believe people who say they will charge you per hr and the “figure it out” or “try our best”. If they’re confident and competent – after looking at the existing code (if there is any) they should be able to commit to timings.
4. Educate yourself. Know when you are having the wool being fulled over your eyes. The best way to do that is by knowing what systems there are, what yours is built on, what’s right about the code and what’s wrong. Can’t do this? See item no.2 above. Get someone you trust to assist and vet.
5. Research references. Call the people they did work for and drill down not only on the quality of the code delivered, but on the timings, communication and delivery. If the latter are poor – the frustration will drive you to distraction. (usually that distraction is rather painful – say, tearing your hear out in clumps)
6. Dive! Dive, into the details – therein all devils shall be revealed. No matter if it’s UX/UI experts or developers – on any example of work they show you, get them to tell you exactly what the problem was, when it was, what they did to resolve that problem, if they were successful and how that success was measured. Ï think i did a really great job”is a line for saps. Don’t drink the koolaid, it’s usually spiked with heavy doses of ego and narcissism.
7. Transparency and communication. Preferably work with people you are close to and speak your language. You don’t want to have to cross a language barrier and a code competence barrier. If something is wrong, you want to be able to meet, discuss and resolve face-to-face.
8. Keep it close. Preferably work with people you are close to and speak your language. You don’t want to have to cross a language barrier and a code competence barrier.
9. Phone a friend. Before you place ads and go to oDesk – ask friends who are coders and use your social channels. You never know what gems will shine through. Always exhaust your network before stepping outside of the comfort zone.
Not having the skills to vet code or to create code is no excuse to become desperate. Be calm, make decisions for a sure and secure space.