Your company needs a Web product or application built--but you don't know the first thing about technology. It's time to hire a developer to turn your great business idea into reality, but how can someone like you with limited-to-non-existent technical abilities make sure your project is managed well and comes in on budget and on time?
Manuel Medina can help. He's a TechStars alum and the current CEO of GroupTalent, a site that matches top tier U.S. tech talent with time to spare with owners of projects in need of freelance coders. From his perch atop the company, Medina has had plenty of opportunity to observe what works when it comes to hiring and managing tech talent--and what doesn't. He offered Inc.com a few tips.
Do go local.
Debate rages over whether remote set-ups are good for early stage start-ups, but Medina comes down firmly in the co-located-is-better camp, at least for developers and particularly for designers.
"Ninety percent of our work is done with start-ups or small business. A lot of them have very little experience with freelancers, so we highly, highly encourage them to find somebody in their city, especially if there is design work involved," says Medina. Why? "There is drawing on papers and backs of napkins and waving of hands and 'let me explain it to you by like acting it out,' and that is really hard to translate over Skype or any other method."
Don't dictate the technology.
Even if you know a smattering about programming, it's better to let your freelance pro choose what tools he wants to use to get the job done, if for no other reason than you're more likely to attract a great developer to your project with this type of approach.
"The most annoying thing for a developer is when a customer knows a little bit about tech but not enough to actually be helpful and they try to impose that opinion on the developer. The best gig for a developer is when someone comes to them with an idea and says: Walk me though how are you going to solve it. Blank slates are usually the best choices for developers, and those projects get snapped up right away because the developer has the freedom to pick the stack and they can pick something that they're good at," says Medina.
Do obsess about user experience.
You may want to lay off when it comes to nitty gritty, backend tech decisions and trust your freelancer, but that doesn't mean you can lay back and lounge while they complete the project. Channel your need to manage your business baby into getting incredibly specific about the customer experience you want to achieve, advises Medina.
"The business owner is far better off thinking about the user experience and creating wire frames as to what exactly he wants to get done as opposed to thinking about the tech," says Medina. "The majority of developers on our marketplace love the projects that are the owner coming in with his own designer and a bunch of mock ups. In absence of that, the owner is better served to think about every single user iteration. Answer this question: when the user comes to the site, what does he see when what does he do?"
"Give the developer freedom to pick the tech stack, pick the deployment, pick Heroku versus Rackspace versus AWS, versus etc. Then let the project owner be the real owner of the user experience," he concludes.
Don't be afraid to micromanage.
Your tech pro may prefer to be reclusive but, as the project owner, you have the right to set firm policies on communication and updates, and things will probably go smoother in the long run if you're detailed and firm about setting up expectations for your work process, according to Medina.
"The project owner should really try to figure out what is he comfortable with in terms of process. How often does he want to check in with a developer? What kind of status reports does he want to see? Is he more of a visual person or does he want to hear something like a story?" suggests Medina.
"Developers by their own accord will not do any check-ins," he explains. "It is up to the project owner to put frameworks: How often do you want to check in? What are the things that you want to use for checking in? Is it e-mail? Is it Skype? The project owner should come in with a really strong opinion, and the developers happily will adapt to it. It cannot be wishy washy or both parties will lose."
This is particularly true for junior developers who are often great at coding but terrible at estimating how long they will take to complete a task. If your junior developer is missing deadlines, forget inspiration speeches. Instead, " sit down with the developer and, like a mother would do with her child, figure out all the tasks that he's working on that day or in general and figure out his REAL availability. Based on that break down each of the features that he's going to do for you and try to get a level of difficulty for each of those. Put on your micromanaging hat," says Medina. Tools like Pivotal Tracker can also help in these situations.
Do show some leg.
"Finding a freelance developer is really, really difficult," says Medina. This creates a somewhat perverse reality that you have to sell freelancers on paying them. So, spend some time on creating a tempting pitch for your project before you try to hire someone.
"If you tell the developer: I just want to create a copy of LinkedIn and Pinterest and put them together,' no developer will want to do that. But if you tell them that you're changing the way that people are communicating by creating this piece of software, developers will get excited about that because everybody has that little entrepreneur bug in them and everybody wants to try something new," says Medina.
"At the end of the day, the developer is going to be your partner in crime in whatever you're building, and you want to entice him. If you want to attract the best, you have to show some leg," he concludes.
Don't be afraid to cut your losses early.
If early on in a project your tech person is failing to communicate and you're getting the sense you might have made a mistake, Medina advocates taking quick, decisive action.
"If a project owner specifies that he wants his developer to check in every so many days, and the developer doesn't do it, that's a huge red flag. That is the first indicator that something is not going to work out throughout the rest of the project. We have never seen a project in which bad fit is going to get better over time," he says.
"The easiest thing to do is just switch developers," he says, stressing that doing so early, even if it feels drastic, will save you money and headaches. "If you don't, the developer will create a body of work--and no developer likes to work on somebody else's code. So at that point it actually gets worse for you because then you're stuck with a bunch of code and you have no idea if you can migrate it somebody else and somebody else is going to say, 'this is crap' or 'this is good,' so make sure that you address these issues early and you address them forcefully."