So You Want to Hire a Freelance Developer

There’s an acute lack of digital talent out in the wild. Every business — worm farmers to art dealers — knows it’s critical to be online. That means building a web site, creating a marketing presence and being active in social media. If you’re an employer, implementing this digital infrastructure can be confusing territory. Odds are, you don’t need a fulltime developer / web marketing expert / community manager on your team. But acquiring a freelancer means hiring and evaluating a skillset in which you may have little expertise. The internet landscape shifts so quickly, it’s hard to track exactly what is effective NOW unless you live and breathe web.

From a freelancer’s perspective, even one prepared with skills in strong demand, new clients are shrouded in uncertainty and frustration. Working productively means understanding a new brand and business goals in short order, while gently educating the client: what tools are necessary? what features are cruft? what content is useful?

For those freelancers fighting the good fight, Godspeed. For employers in need of freelance talent, a few suggestions:

1). Come prepared with a tight, concise concept of what you’d like to build.

At the onset of a web project, every client has an idea of what they want to end up with — even if it’s only in their head. There’s nothing worse than vague directions from a client that send freelancers back to the drawing board when deliverables don’t match poorly articulated expectations.

It’s ok if you’re not a designer or information architect. Sit down and map out exactly what you want as the final project. Sketch concepts on paper, make note of similar websites doing something you like, and make sure you consider what folks in your organization need from a backend. A minute spent on detailed specifications saves an hour of back and forth or wasted development effort.

2). Beware feature creep.

Closely tied to number one – make sure you nail down ALL the required functionality before work starts. There are many good reasons to avoid feature creep. New features add to the scope, which will result in additional cost to the employer. It’s generally harder to integrate new features once half the code is prepared. Most importantly: the new features are almost uniformly bad ideas.

There’s a certain pressure that clients feel to squeeze everything in once work is underway. This can lead to an insistence on building spur-of-the-moment ideas. Tread cautiously. Generally, clients and developers remember the truly important features before getting started. See a project to completion and live with it for a bit before deciding to add on extra bells and whistles.

It really messes up freelancers to extend a project, because missed deadlines cascade over into work that’s lined up in the future. Planning work schedules and accounting for uncertain income is hard enough when projects wrap up as expected

3). Limit parties allowed to provide feedback.

What’s the best strategy to avoid feature creep? Limit feedback on prototypes to only the most essential staff. Additional eyeballs reviewing freelancer work make it harder to reach consensus. Even if you are lucky enough to have all reviewing parties on the same page, getting everyone to take a peek wastes time and keeps your freelancer idle. Identify who needs to sign off on work at the onset, and don’t introduce commentary from the peanut gallery mid-process.

4). How to understand delays:

Delays are justifiably frustrating to clients. When a freelancer promises a product in 30 days, and fails to keep his or her word, the likeliest explanation seems to be that the developer is a liar, or a dolt. Unfortunately, even the best managed projects often (if not always!) turn more complex than anticipated.

Michael Wolfe offers a brilliant analogy in to explain how this happens. When you consider a project in broad strokes, say, as one might look at a length of distance down the California coast along a map, there’s a clear path from A to B. Once you’re actually on the ground, it’s likely there are many obstacles that weren’t clear from the map. There’s no method to accurately predict every complication in most digital initiatives, other than rolling up your sleeves and starting work.

Some freelancers like to take a guess at delays that may arise and quote high. I prefer an initial quote based on the best information at hand, and an employer who appreciates that there is always a possibility that information may change.

5). Draw up a contract.

When I first began freelancing, I didn’t mind winging a project without a contract. You are correct: was that ever a bad idea. At face value, contracts are useful in resolving legal disputes, but I’ve never been so unfortunate as to experience that first hand.

The real value in a contract is codifying everyone’s expectations and laying out a framework for the project. Insist on a detailed contract outlining scope, milestones, communication expectations, and a process for missed deadlines or additional work requests. Clarity in terms of engagement go a long way toward working effectively once you’re close to the finish line.

It’s tempting to manage a freelancer on the fly — but the most effective, and satisfying process is always building a tight, precise framework at the onset. When you and your freelancer share a clear vision, your project will turn out great.

*PS: I’m very grateful for Derek Sivers’ excellent guide to hiring freelancers. Four years old and every bit as useful today. *