I have been freelancing as a remote developer for over ten years. I specialize in legacy systems and taking over abandoned and unfinished software projects. I see the problems customers have hiring and working with freelance developers. Here’s my advice for avoiding some of the potholes.
This article is about freelance software developers, programmers, and system administrators, because that’s where my experience is. Some of this applies to freelance designers, writers, marketing consultants, etc.
I work through 10X Management, a talent agency for developers and technology professionals. I am available to consult with customers to help them find, hire, and manage freelance developers, and to define and prioritize requirements and measure progress.
Interviewing, hiring, and managing
I’m not going to get into step-by-step instructions regarding the nuts-and-bolts of finding, hiring, negotiating with, and paying freelancers, writing contracts, tax laws, etc. If you aren’t confident that you can evaluate and manage a freelance developer you should use an agency or hire a consultant who has that experience. Software development is expensive and takes time, managing programmers is hard.
Personality conflicts will kill your project and stress your team. Over and over I get involved in situations where the customer and the freelancer clashed personally. If you don’t feel comfortable with the freelancer when you interview them, find someone else. Be aware of your own rough edges and prejudices. Get someone else involved interviewing and managing freelancers. If you won’t be the main person working with the freelancer, get the people in your organization who will be involved in the selection and hiring, and pay attention to any objections they raise. Hiring someone without getting buy-in from the rest of your team gets everyone off on the wrong foot.
Many contract programming shops outsource most of their projects. Be sure you are talking to the people who will be working with you and your staff, not just an account executive or project manager who closes the deal but doesn’t do the work.
Be clear about your expectations, but back off any you can’t justify. For example you may feel strongly that you need someone working on site every day. That requirement will greatly reduce the pool of available freelancers. Is that an absolute requirement (for example, security clearance required, systems that can’t be accessed remotely, specialized hardware, etc.), or is it worry about not having control? Here are some things you should be clear about before you start interviewing freelancers:
- Your budget, total or for the first set of defined tasks.
- Your schedule.
- On-site time required? How much/how often?
- Who will the freelancer report to and work most closely with?
- Is a security clearance or background check required?
- Availability – how fast do you expect phone calls and emails returned? What qualifies as an emergency?
- Who owns the completed product?
- Do you have existing systems that are part of the project?
Before you start interviewing freelancers you need to have some high-level requirements defined. You should be specific without getting into unnecessary detail, and that takes some practice and editing. “Web developer needed for golf equipment retailer fulfilling 10,000+ orders per month, must interface with existing back-end system” is a lot better than “PHP and MySQL programmers with 3+ years experience.” Try to be detailed enough to attract people who will be a good match for your needs, but not so specific that you eliminate too many candidates. Avoid listing technical requirements (languages, tools, years of experience) unless they are absolutely necessary for the job, and you are able to evaluate the freelancer’s competence.
Check references and reputation
When you find a freelancer you like ask for examples of similar projects and references you can contact. Almost no one is going to put you in touch with their unhappy customers, but you should be able to get an idea of the freelancer’s history and reputation by talking to their previous customers and checking them out online.
A nice online portfolio, blog, customer testimonials, and a github profile are all things that a professional developer should have, but those are not sufficient to base a hiring decision on. Has the freelancer worked on projects of similar scale and scope? Online study assignments and side projects indicate enthusiasm but not necessarily professional skills or ability to deliver, so set your expectations (and payment) accordingly.
Business domain experience is at least as important as technical skills
Look for experience in your business domain, or a similar domain, and value that experience as much as checklists of technical skills. You probably are not qualified to determine how proficient someone is with PHP or Ruby. You can judge how much they know about your business domain, or a related domain. For example if you are looking for someone to work on an e-commerce site talk about inventory management, shipping charges, sales tax, payment processing, customer management. If the freelancer doesn’t understand your business or doesn’t ask questions about how it works your requirements aren’t going to make sense to them. Technical skills alone do not solve business problems.
I have sat in on many interviews where the customer and the developer talk past each other. The customer is trying to describe what they need in terms of business requirements, and the developer is talking about languages, tools, scaling, programming process. This disconnect starts at the beginning of the relationship and will, at best, lead to a false start or two, and at worst to a failed project. If you aren’t communicating with the freelancer or you don’t get the impression that they care about and understand your business needs, address that problem early on or find someone else.
Be alert to signs that the developer is going to use your project as an opportunity to try new programming languages or tools. Unless you want to be on the bleeding edge beta testing open source software insist that the developer use stable, mature tools that everyone else is using. It will be a lot easier for you to find people to work on software that is built with mainstream tools.
Define the tasks and deliverables
After personality fit, the biggest determinant of success or failure is how well you describe the tasks and deliverables. This is actually the hardest part of any software development project, so take some time to get it right. Get professional help if necessary. You need to break your project down into small well-defined tasks with clear deliverables. “Set up e-commerce site for my business” is not a specific requirement. What you want to end up with is a list of measurable tasks, in order, so the freelancer always knows what is next and you always know what has been completed. Every task should have an associated deliverable that clearly describes what “done” means for that task.
Defining requirements and setting priorities is one of the hard problems of software development. There are several techniques for managing requirements. Some people prefer the so-called waterfall or BDUF (big design up front) approach, others advocate agile techniques, where software is development in small steps so gaps in requirements can be discovered early without causing a lot of disruption. It’s important to recognize that most customers and most programmers are not very good at gathering and defining requirements, so be realistic. (It’s also important to recognize that no development process guarantees success.
The best way to protect yourself from fights about missed and vague specifications and changing requirements during development is to start by describing the simplest possible thing that will work. Developers call this the minimum viable product, or MVP. You don’t have to define all your requirements in advance: you only need to define enough tasks to get started. With a list of small well-defined tasks and measurable deliverables you can quickly assess if the developer is working out as expected. You will discover misunderstandings and problems early on, and take action to get things on track or terminate the relationship. If you start with a big list of vague, incomplete requirements and let the developer work in isolation for months you won’t know for a long time if the project is is in the weeds, and the developer won’t know if they are not doing what you expect.
It’s hard to resist doing more than you originally planned when the programmer is telling you how easy it will be to add features, make your system into a platform with APIs, scale to Facebook-level traffic. Don’t go down the path of scope creep, it leads to unfinished projects. Insist that the developer do the simplest possible thing to meet requirements, and don’t let them expand requirements to account for things that aren’t likely to happen.
Communicate clearly and frequently, and don’t get caught up in process
Establish ground rules with the developer regarding communication, and be sure you follow those rules. If you expect the developer to answer phone calls and emails within an hour, you should do the same. I hear customers complain about developers who don’t respond to calls and emails for days or weeks. I also have experience with customers who don’t reply promptly, or at all, to questions I send, or who don’t deliver things they are responsible for on time. If you aren’t answering questions and giving the developer what they need your schedule will slip, and you will frustrate the developer. If you delegate day-to-day management or tasks like approving designs or producing graphics to someone else, make sure those things are getting done.
The developer may propose (or even demand) that you use their process and tools. If that makes sense to you, great. But be wary of developers who have a lot of process and make that your problem. As the customer you should be able to discuss requirements and report bugs in person, over the phone, or in an email – don’t agree to only communicate through online project management or bug reporting tools. Whatever process and tools the developer needs to use to deliver is their internal issue, it should not be forced on you, and you should not be paying for time spent on internal processes that don’t have a clear and measurable benefit to you.
Build incrementally
You should agree with the developer that you need to have something working all the time. Don’t allow for weeks or months of development with no visible results – insist on small steps that build the system up bit by bit. Even if you start with a single web page that shows your logo and some mocked-up functionality, that’s better than having nothing to look at. You should also insist that the developer use source code control from the beginning (Subversion or git), that you have separate development, staging, and production environments, and that you are not using real customer information or credit card numbers for development or testing.
Pay for results, not fixed-fee or hourly
Another reason to work from a prioritized list of small tasks is payment. I’m astonished that customers and freelance developers agree to fixed-fee proposals with significant money and time at stake, and the entire project is described in one or two pages of exhibits tacked on to the contract. Unless you have a history with the freelancer that gives you confidence that they will deliver on time and on budget, or you are buying a mostly off-the-shelf solution with very little integration and customizing, a big fixed-fee contract is probably not a good idea. If you go into a project with a fixed-fee arrangement there’s a good chance you won’t know about schedule or cost overruns until late in the project, and there’s also a good chance you will be presented with costly change orders for every small change. Even experienced professional software project managers can’t anticipate all requirements or estimate tasks reliably. Don’t expect that you or the freelance developer will be the exception.
Paying a freelancer by the hour seems like a better plan when you don’t have experience working together. The problem with paying hourly is that deliverables become by-products. The focus on hours spent and time tracking can consume a lot of energy on both sides and lead to arguments about how much time something took or should have taken. I advise against paying hourly, but if you do pay hourly make sure you put a cap on the number of hours you will pay for.
Ideally you should pay for results: finished tasks and working deliverables. That only works if you defined your tasks and deliverables well enough so the freelancer can estimate the work, and you can determine if the estimate is reasonable. As I mentioned earlier, you don’t have to define the entire project in advance and break all of it down into small measurable tasks before you start; you can do that incrementally as the project proceeds. It’s easier for a web developer to estimate “Home page with our logo, main navigation menu, and content areas blocked out, no functionality” than “Start on e-commerce site, show progress in two weeks.” And it’s easier for you to see if the developer is getting the work done as expected and following instructions.
When I start working with a new customer I ask them to list their top five or ten problems, in order, most painful first. If the list is vague I work with the customer to make it more specific: “Web site slow” becomes “Searches with more than 100 results slow to display.” The goal is to have a list of problems we both understand, so I can work from the list, estimate the time I need to fix the problems, and the customer can determine if I’ve delivered.
I prefer to establish long-term relationships with customers and negotiate a retainer agreement, where the customer pays every month for a block of my time they can use for consulting, new development, enhancements, or maintenance. Once you have established a good working relationship and trust with a freelancer working out a retainer is a good way to insure they are available when you need them, and to keep your software development and maintenance costs predictable.