7 Tips for Hiring and Managing Freelancers

Rules are the Scar Tissue of Past Mistakes

I was talking to a few new entrepreneurs about how to manage the process of employing freelancers to run their projects and startups and thought I would list down the mistakes I have made and the methods and tools I use to try to make this a tighter process as it is very easy to have this come off the rails.

I always preferred to have my own team members on staff as employees, but when it comes to software development it’s very difficult to bootstrap an application or business using software developers based in Sydney or other western cities, its especially impossible if you are self funded using your wages.

And so there are hundreds of thousands of would be entrepreneurs hiring freelancers via Freelancer.com to code up projects in the hope that one of the experiments might turn into a real startup.

This makes an already difficult process (software development) extremely difficult. Add to that cultural, language and time zone differences and the opportunity for mischief and misadventure is especially high.

I have been hiring remote freelancers for various projects for myself and other companies since before Freelancer.com existed, must be close to 12 years now.

Over the years I have had probably 20 from India, Nepal, Pakistan, Russia, Philippines, USA and the UK.

It’s tempting to think that they require less due diligence than an employee, but nothing could be further from the truth.

Given your time in both the interview and daily face to face conversation is likely to be short compared to a normal employee it makes it critical to carefully manage the relationship, the description and delegation and completion of tasks.

Often a lot of this work is done via chat sessions, especially if you are working a day job, you won’t get to talk to the freelancer very often, this makes it very difficult to get work done.

Im still learning and still making mistakes but here is a few tips that have worked well for me.

Treat it like a Real Employment Process

Initial Chat sessions to shortlist a few candidates and follow it up with proper Skype interviews, use the same sort of time and effort you would for a real employee, its easy to think that you don’t have to but trust me you will waste a lot of time and rehire numerous times unless you do.

Hire Individuals

I hire individuals or teams of two only, in my opinion hiring an outsourcing firm is a recipe for disaster.

If you think its hard to get what you want dealing with a freelancer of a different nationality, culture and time zone that speaks English as a second language, try getting what you want done with 1-2 layers of project manager and sales people in between.

Not only will be it much more expensive to carry this overhead but its very likely your personal work overhead is likely to be much higher as well. Typically these firms want you to create a detailed specification much like a traditional waterfall life-cycle and then will lock you down to the specification and then when you have to change it (which you will) they end up billing you hourly anyway.

The truth of the matter is that you have a vision about what you want, but in the style of the Lean Startup there is a lot to be learnt.

In some cases you may be trying to create a technical solution which might use known parts but is doing some technically difficult. 

Mistakes will be made, lessons will be learnt, its best to find individuals who are flexible and happy to work on an hourly basis because any fixed plan will not survive contact with either a customer or testing.

Ground Rules

Start with a set of non negotiable ground rules. Explain that you cannot employ contractors who do not continuously apply these and sack anyone who doesn’t. My rules are as follows

• Contractors will load Slack to their desktop and mobile device and will update the team daily and ask/answer questions as required
• Contractors will commit their work to Github on a regular basis. New feature or bug fix requires a commit
• Branches should be merged regularly
• Commit messages should be detailed and cover all changes to the code for that commit
• Contractors will use Trello to pick up their tasks and update them, ask any questions or make notes on the card
• Code should be deployable, meaning that you should be able to clone the code from Github master and have it run on your server (this is hard to get right but its essential if you are going to build a functional development team).
• Try to be in a similar time zone +/- 6 hrs, anything more means you will never be able to chat with them during your waking hours which will throw your development back days everytime they have a question and you are asleep.

Start with a Small Test

Don’t take your contractor on full time or make them a member of the team without a test. 

Its a pain the in ass but you need to try to find a discrete task that is large enough to give you an idea of their work ethic and quality and how well they will communicate and follow your rules.

On-boarding

You need to get together a set of documents and a checklist of things to be done to get a new developer on board. At a minimum you need the following

• A diagram which describes your tech stack
• A description of key processes and the resources required to deliver them
• A checklist of systems you need to give them access to (and revoke when they leave)
• A Skype call to describe your vision and why you want to solve the problem and how they are going to help you deliver that (you want to get them excited about the project, its not enough that they are simply filling in time, they need to be engaged).

Systems

You can use what you prefer, a lot of freelancers are resistant to using systems, they are often don’t see the need, if they won’t play the game sack them immediately, it never gets better.

We use Trello for task management and assignment, Slack for Comms and Github for code version control.

Trello is pretty easy to use, we usually have 4 columns 

• Ideas (not in Roadmap) to capture all the good ideas that you are not ready to work on yet,
• Roadmap what you are committed to building
• MVP the tasks required to build the Minimal Viable Product
• Doing
• Done

A note about Github, so many developers will tell you they can use Git and Github but they have no idea. You need to work this out asap as they will screw your development process if they don’t have a clue.

You can’t just pick Git up in an hour, its a steep learning curve, they shouldn’t be learning on your time if this is your requirement. Ask them to branch your repo and make some changes, commit them and make a pull request and see what happens, you either get a blank look or you get some messages from Github saying its happened.

I use Jira for tasks in my day job and its good for a large team with a complex development environment but its a lot of overhead for a small team and I find it a bit convoluted and the flow is not as easy as Trello, also have used Asana which is ok, again just prefer Trello’s boards and flow.

Slack is fantastic but you need to know when to pick up the phone or video conference and call someone, if you find yourself labouring and starting to get the shits with the person on the other end its time to call.

Daily Habits

You need to establish a time to chat via slack or Skype

You need to chase daily

You need to make them commit to Github regular

You need to make them show you the working product regularly because what happens is they don’t commit, they build whatever they think you wanted or whatever they think they can get away with, but its not what you actually wanted, weeks have gone by and you are pissed off, your money is gone, they are tired and you need to reboot the project. You need to see working code regularly and change course as required.

Hope this is helpful, if you have any great suggestions I would be happy to share them with the readers.