Why Programmers Are Like Pirates: An 8 Step Process For Managing Your First Development Project

For the first few posts on this site, I’ve definitely tried to walk you through the process of getting your site or program built (starting from zero). So far, we’ve talked about what types of different developers exist, and how to get them hired on Odesk.

Today, I’d like to address the actual process of getting your development project done. So, once you’ve got your programmer picked out, and you’ve decided you’re ready to move forward, this is the process I recommend you use to get things running.

This article is for people who are managing one (or a few) programmers for the creation of a website or software tool. It is especially for those of you who have never done this before, or, for those who have struggled with it in the past.

Quick Overview of The Process

Ok, here’s a rough outline of my development process:
1. Break it down.
2. Explain your business.
3. Explain your idea.
4. Give a simple job.
5. Feedback
6. Start your first stage of work
7. Feedback
8. Repeat

Unfortunately, most people hire a programmer and then jump directly to step 6. In other words, they want to get their project started, so they just give their new programmer a job and set them loose.

This is a bad idea. But, I’m getting ahead of myself. So, let’s start with Step 1.

Step 1: Break it Down

Before you even have a conversation with your programmer or team of developers (aside from the interview), you need to go through your project and break it down into very small chunks and stages.

This is extremely important, and underlines my development philosophy – don’t skip this. The best way I can explain why, is by using an analogy. Stick with me here.

Treasure Map Analogy

Imagine for a moment that you’re a pirate, and not just any pirate. You’re the Captain. The head honcho. The guy with the eye patch and the talking bird, etc…

On this beatiful pirate day, you’ve arrived at an island where you know there is buried treasure. You used to have a map, but you lost it. To make matters worse, you also recently lost your leg to a stray cannon ball. Not cool.

So, your pirate hearties are looking to you to tell them where the treasure is (and how they can find it).


You’re going to have to explain to your pirates how to find the treasure (since you can’t walk the route and do the digging yourself).

Now, imagine gathering all your hearties around you on deck and simply saying to them…

“Go find ye buried treasure. It’s on the other side of that thar mountain.”

Now listen, your mateys are pretty bright. And, they can probably work their way to the other side of the mountain without the map. But you haven’t really given them enough details to put them right on top of the treasure location.

In fact, you haven’t really explained what they’ve even looking for.

But, what if you said the following?

“Arrr, we be searching for some buried treasure. It be a large case with a black skull on the chest, full of gold and buried deep in the earth.

First, you’ll need to find the seaside rock that looks like a elephant. She be at rest on the west side of the island.

Then, ye should travel due South till ye reach a small stream…”

Ok, I think you get the point – enough priate speak.

Listen, you’re the guy with the mental map of your software project. You know what you want to build, and you have the outline.

Your programmer, no matter how smart, cannot know what the treasure map (your project) looks like unless you explain it to them.

And, if you don’t explain the map to them in a way that they can understand, there’s gonig to be a lot of misscommunication and wasted time/money.

Don’t be that guy.

Thus, you need to break your project down into steps that require no more than week or two of development – MAX. If you’ve never done this before, you may not have a great grasp on how much work that is or isn’t. Don’t worry, you’ll get the hang of it.

Sit down with a piece of paper and outline what the very first stage of your project will look like. Usually, I like this to be pure functionality only. You want your programmer to start by buiding a tool or site that simply functions and implements the CORE of your idea. No bells, no whistles, no extras – none. Nix. NADA.

This is important for two reasons.

First, the simplicity will save you time and money, allowing you see if you have proof of concept (before you spend all the cash needed to make it fancy).

Second, you will allow your programmer to focus on only the most important aspects of your program, reducing the amount of code he or she has to write (making their job simpler.)

Oh, and one more reason. If they get it wrong, it’s easy to adjust on the fly because no one has done that much work yet.

Coding is like writing a novel, it’s easy to change the storyline 5 pages in. It’s pretty tough in chapter 24.


Ok, I’ll try to give you a few examples that we’re all probably familiar with.

If I was building Twitter, my first step would be to create a dashboard where I can post updates. This also becomes my ‘profile’ later on. That’s stage 1.

After that I might make it so there are multiple people, with multiple dashboards. That might be stage 2.

Then, I might make it so they can choose to link to each other by ‘following’, etc…

Each step builds on the one before. But, the core of Twitter is posting Tweets. So, that comes first.

Keep it simple.

Or, let’s say your having a lead generation form built. Step one is creation of the form. Information can be entered in the fields, and when someone hits the submit button – it sends.

It doesn’t tell you that you mistyped something. It doesn’t let you know you ignored a field. It doesn’t check for valid phone numbers, etc…


Right now I’m working with the AdSense Flippers to create a theme that improves Ad click-through-rates. Stage 1 was to ensure that we could record clicks.

That’s the heart of the program. If we can’t record clicks, then we can’t track them. And, if we can’t track them, we can’t optimize them.

Making sense?

Every project is different, so I can’t realistically cover ever scenario. You need to think about this in terms of bare bones. What is it that is most important for your tool or site to do? Get that built first.

Then, it’s time to create the next stage, where small bits and pieces start to come together. You add some complexity, make the tool more useful, etc…

But each stage is small and builds only slightly on the one before it.

Once you’ve got a relatively clear idea of what the different stages of your project look like, you need to write each of them down and post them where everyone involved with the project can view them.

Why do it this way?

This gives your programmer a starting point, an ending point, and an idea of where the future is headed. And, it will allow them to make small decisions (programming choices) that make sense (without having to consult with you). You’ve taken the treasure map out of your head, explained the route and the final destination to them, and given them the tools to get the job done.

If you start by simply explaining the end result and setting them loose, they’ll find their own way there (you are paying them after all), and it might not be pretty.

Ok, let’s move on.

Step 2: Explain Your Business

Ok, now you’ve got your whole project outlined. It’s time to get started, right?


You still haven’t laid enough groundwork for success.

You need your programmer to understand your business. You need them to get what you do.


Back to the pirates.

If, in search of the buried treasure, your pirate friends come across a pool of Crocodiles, a bandit of theives, or the British Navy, they are going to have to make decisiosn on the fly… without you.

You’re back on the ship drinking rum and carving a new leg. (I.E., you’re a busy person. You’ve got other things to do than manage your programmer.)

So, in order for your programmers (pirates) to make intelligent choices (without you) they need to understand how you operate, why you operate, and what your business is about.

Otherwise, they’re in the dark. And they won’t know how to make proper decisions when things come up.

What would the Captain do? Would he kill the theives? Would he go around the Crock infested pond?

You can’t plan for every possible contingency. But if your programmer understands what you do in your business, they’re more likely to get your software built the way you want it.

If you give your programmer a task, and a week later a bunch of work has been done that you hate, it’s your fault – not theirs. Either you hired the wrong guy/girl, or you didn’t give them a good enough map.

You have only yourself to blame.

Explaining your business is part of making sure that doesn’t happen.

Step 3: Explain Your Idea

Ok, now your programmer has an outline for the job, and understands what you do. Believe it or not, you’re still not ready to start the development process. But, you’re really close.

You need to explain exactly what this project is.

Naturally, you should have done a fair amount of this in the interview (to help ensure fit), but now it’s time to get into more details.

Explain exactly what you’ve got in mind, and allow your programmer to give you feedback.

They know things you don’t, and understand the technology and its capabilities in a way that you do not. So, listen up.

If they have questions, talk it through. Get everything out on the table to the best of your ability. And, get that outline you created published online somewhere.

It doesn’t matter if their are three stages or twenty. It’s best if you both have access to it.

Step 4: Give Them a Simple Job

Ok, you’re getting really close to actually starting your project. But you’re still not quite there.

First, you need to give your programmer a 2 – 4 hour job (which may or may not be directly related to the project at hand).

This does a number of things.

First, it tests out your communication. Did they get it? Did you explain yourself well? Was their confusion about the price, timetable, deadline?

Did they do it correctly?

You want to get this stuff sorted out, so that when you release them on your project, you can trust things are moving in the right direction.

Again, this is project specific, but I like to have my programmers do simple things, like build contact forms, setup automatic emailing scripts, build a simple interface, etc…

Anything that will likely be useful to the project later on, but which will allow you to test out the process.

Step 5: Feedback

This probably goes without saying, but once they have completed that first bit of work, you need to make sure you give them proper feedback.

Let them know what they did right and what wasn’t so good.

Be nice, but be honest. Remember, this will dictate how communication works in the future (when it matters most).

Step 6: Give The Stage 1 Work

Ok, now you’ve laid some decent groundwork. You’ve built a solid foundation with a reliable and trustworthy programmer. They understand you, your project, your business, your communication style and your timetable. They are ready to begin, and so are you.

Give your programmer the first task related to your project.

Ask them how long it will take, and keep an eye on their work with Odesk’s built in tool or a seperate time tracker like HiveDesk.

Tracking their time with a tool is important for the following reasons:

  • It shows you they are trustworthy.
  • It allows you to see exactly how long certain tasks take them.
  • It gives you a clear way to pay them
  • It gives you a way to cut in and stop work if you see something wrong.

Step 7: Feedback, Round 2

Ok, once your programmer has built the skeleton of your tool, you should again, give them feedback. Let them know what you thought of the work. Test it out yourself and see if there are any bugs.

At this point, things should be pretty straightforward because you’ve spent the time up front to get it right.

Step 8: Repeat

That’s really it.

The rest of your development project will be a series of meetings, work, tracking, payment and feedback. Keep looping over that process until you have something to use, sell, etc…

Remember, the key to a successful software development process (or treasure hunt) is to make sure your programmers (pirates) know what to do when they start working (leave the ship). Do that, and you’ll be happy with the results.

Web Developer vs. Web Designer: It’s All Greek to Me

Front-end Coder, Back-end programmer Front-End Designer, Graphic Designer, Webmaster, PHP developer, Ruby Developer, UI Designer, UX Designer, Web Applications Developer, Database Engineer, Database Administrator…

Ok, I think you get the point.

Let’s be honest, if you’re not a programmer, coder, or engineer, it’s pretty tough to figure out what exactly all of these different people do. If you’re trying to get a website, application, or software tool into production, you know you need at least one of these people working for you, but which one(s)?

In this article, I’m going to breakdown what these types of people do, what languages they work in, and what they can and cannot build fo you. (In the simplist way possible. We’ll probably explore this in more depth in other posts.)

But, let me just say this up front. Most people will be able to get by with one or two of the above individuals to build their app or site.

Appropriately managed, it’s amazing what a few people can build in a relatively short amount of time.

First, Understand This

Developers and designers come in a lot of different flavors. So, it’s really about finding the right individual with the right combination of skills.

You may not realize it, but 99% of the development jobs you hire people for will have a pretty significant amount of overlap. So, even though each of the titles listed above suggests a specialization, they are all interrelated and connected.

Simple Definitions

So let’s get right into it. We’re basically talking about two different types of fields here – Web Development and Web Design.

First, let’s go over what Web Developers are and do.

Web Developers

Synonyms: Web programmers, developer, web coder, programmer

A developer is someone that deals with the creation of programs and software. People will commonly also refer to these individuals as ‘programmers’, but there are distinctions to be made here amoung the two main varieties of Web Developers.

Let’s take a look at those distinctions:

Front-end Developers

‘Front-end’ has to do with what the users of your tool or website will end up seeing. Here are a few examples of things front-end developers might work on:

  • The functions of buttons
  • The layout of pages
  • The menus and structures of your application or site
  • Error and confirmation messages
  • The organization and user experience within a shopping cart

These are called ‘client side’ actions, because they are things that actual users will experience when they use your site or appplication.

Common Languages: HTML, CSS, jQUery, Javascript, XML, XHTML, HTML5

The second type of developer is called a…

Back-end Developers

These people work on the ‘back-end’ (which is your server) to make sure everything works correctly. They aren’t generally conscerned with what a site or program looks like, only that it performs correctly.

This is called ‘server-side’ programming. Here are things that a back-end developer might be responsible for:

  • Ensuring that your customer data is saved and organized correctly
  • Keeping your site secure
  • Having Shipping costs calculate automatically in your shopping cart
  • Scraping search engines for data
  • Sending out emails automatically from your server

Common Languages: Perl, C, C++, Python, PHP, Ruby, SQL, Candle, ASP.Net

Why The Distinction?

You might be wondering why these two fields even exist. After all, doesn’t every program and website have to work (on the back-end) and be user friendly (on the front-end).

The answer is – yes. But learning programming languages takes a great deal of time. And, it’s not very common for someone to master both the front-end and the back-end languages. Thus, most people specialize.

I would liken this to how many surgeons pick a specialty. You probably aren’t going to be a world-class orthopedic surgeon and an expert neurosurgeon. That would require a pretty crazy amount of skooln’. And, just as how some surgeons become ‘general surgeons’, some web developers know a fair amount about both front and back-end development. The lines are blurry.

Generally, though, a developer chooses one or the other (front-end or back-end) simply because they like one technology or language better than the other.

Make sense?

Web Designers

Our last category is that of ‘Designer’. Generally, these are people that are responsible for the colors, images, layout and general feel of a website or application.

Most designers will be familiar with tools like Adobe Illustrator, Photoshop, GIMP, etc…

  • Designers are responsible for:
  • Typography (layout, size, spacing of text)
  • Color schemes
  • Site layout
  • User interface
  • Logos


Ok, here’s where things get confusing. Almost every person in the Web Development and Design industry, has some crossover skills in another arena. For example, most back-end developers are able to make web pages and applications function for users, and thus, have some ‘front-end’ skills.

Some front-end developers only take designs from designers and code them to look correct on the web – they are not designers. Yet, other front-end developers are designers.

Some designers can front-end code.

And, some people can do a fair amount of all those things.

So, if you’re looking to hire someone to build your site or program, here’s what it ultimately comes down to:

What Are You Trying To Build?

The information above should provide you with a starting point, but, to make things a little simpler I’ve provided a list of common tasks, along with what types of skills you’ll need from a developer or designer.

Search Engine Scraper Tool

  • Back-end Developer
  • Maybe a Front-End, designer-type if you’re going to release to the public.

Custom WordPress Theme

  • Front-end developer with some back-end skills in PHP
  • Possibly a designer if you want things to look special and pretty

Customer Database

  • Back-end Developer

Social Media Tool

  • Front-end, Back-end, and Designer

Ecommerce Store

  • Back-end, some Front-end
  • You might be able to use only a Front-end developer if they are implementing a packaged script, program, or plugin of some kind.

Inventory System

  • Back-end
  • Maybe a little Front-end, depending on your internal needs


  • Front-end and/or designer

Membership site

  • Back-end and front-end, maybe a designer

Keep in mind that the above list is an intentional over-simplification. But, that should give you a decent starting point.


Well, that pretty much wraps it up. If you have any questions about what I’ve covered here, feel free to contact me or ask them in the comments. I’m more than happy to try and help you figure out what kind of web developer / designer you need to get started on your next project.

Good luck! And happy hiring!

Using Google Docs For Project Management

  • Where will I store these mock-ups so that everyone on the team can see them?
  • How will we collaborate on this?
  • How will I assign everyone tasks to make sure things move forward?
  • Is there one tool for this?
  • What if we lose a piece of information?
  • What if the process of building this isn’t straightforward and people get confused?
  • How much money will I waste if my project isn’t organized?

I remember back when I first began bringing people on board to work on IntelliTheme, I was concerned about all these things. Lucky for me, I had a great example to follow. My mentors, Joe and Justin of AdSense Flippers run a +20k a month business (with 30 employees) on Google Docs.

No task software. No Basecamp. No collaboration software. Just Google Docs.

And, Justin and Joe build 60 websites a week. So, trust me on this – if you’re just building one site (especially if this is your first go-around), using Google Docs for your project management needs will probably be more than adequate. 

What You’ll Need

While the heart of your project management process will exist on Google Docs, you’ll need a few other tools to keep things running smoothly. Here’s my personal list.

  • Camtasia – Most of my communication with my developers happens over email and Skype. However, if I want to deliver a new task that is a little complicated (and I don’t want to bother setting up a meeting), I use Camtasia. It’s super simple to load up the program and record a quick 5 minute video explaining what I want. And, I find it’s often more effective and efficient than having a meeting.
  • Dropbox – File sharing. It’s free and easy to use. Nuff said.
  • Odesk / Hivedesk – Not mandatory, but it makes tracking your programmers’ hours painless and hands-free. You don’t really want to add invoicing and time tracking to your project management process do you? Of course not. Let these tools do it for you so you can focus on getting stuff done.
  • A Google Apps Account – I suppose this part is obvious, but I figured I might as well state it. You need a Google Account in order to setup and use Google Docs. You’ll also  need to make sure everyone you’re collaborating with has a Google account. Most people do now, so It’s rarely a problem.

Actually Using Google Docs For Project Management

This is actually extremely straightforward. Basically I just create a spreadsheet or regular doc and then create sub headings for the different people who are working for me.

Honestly, this couldn’t be more simple. Each heading represents a person. The tasks underneath their name are the things they need to complete. The items in red are priority. This document is shared among all of the people involved in the project. As each person completes tasks assigned to them, they cross them off.


Honestly, if you’re the leader of a large software team this solution probably isn’t for you. However, most of my readers are just getting into software development, and, this system will be more than adequate for them. It’s strikingly similar to my own personal productivity system. I have a simple text file that I update regularly with all the things I need to get done. Each day I visit that document and pick the most important 3 – 6 items and do them. It’s as easy as that.

Is It Really That Simple?

Yes… and no.

Keeping track of who is doing what really IS that simple. Making sure that everyone has access to the files and information that they need to do their job is a little more complex. Not because sharing information with them is complex, but because the organizational component of a project is so often overlooked. I discuss this a little bit in: Managing Your First Software Development Project. But, I think that’s a topic for yet another post.

So, assuming you’ve taken the time to break down your project into stages and milestones, a simple Google Document shared among all the members of your team should be enough to keep everyone on task.

Hourly Vs. Fixed Rate Contracts: Which is Better?

Should you pay your developer one lump sum, up front?

Should they get half now, and half when the job is done?

Is it safe to pay them hourly, or will they waste time and run up your bill?

These are all valid questions, and I’d like to take a moment to address them, as I’ve had some experience on both ends of each of these scenarios.

Use a Medium

For the sake of argument, I am assuming that you are paying a contractor through some kind of portal. Either they’re on Odesk, Elance, or working through some other program that tracks their work.

Secondly, I’m assuming that, because you’re using this portal, you also have a medium through which to dispute any potential payment or contract problems. I highly recommend you hire programmers through another site, where you can view their feedback, their history, and their work. This also allows you to keep better tabs on what they’re doing for you once the job begins.

Enough said.

The Advantage of Fixed Price Jobs

As employer, you will naturally gravitate towards this option. And, that’s to be expected. After all, you want to save money and ensure that you don’t get into a situation where you’re paying out more than you bargained for.

This is a fair point of view. Their are numerous situations where a fixed price contract is, I think, I fantastic option. Here are a few scenarios in which I would hire a programmer at a fixed rate:

  • The project is relatively short and simple (a few days work).
  • I know exactly how much work needs to be done, and how long it should take a competent programmer.
  • I don’t plan on making any changes to my project during or after it’s completion. Everything, down to where the buttons and form fields are located, is set in stone.
  • I don’t care that much about how it’s done, and it’s a relatively low-cost job that I just want someone else to handle. As long as they finish it, I’m going to be hands off. (This is very rare.)

Fixed price contracts are favorable agreements to both parties because everyone knows how much money is going to be spent. It removes a variable, making both programmer and employer a bit more comfortable. That being said, it also has it’s limitations.

Fixed Price Limitations

What if you want to make changes to your program or website (changes that weren’t in the contract)? What if you want to add or remove something? What if you want to cancel the project and cut your losses? What if your programmer can’t handle the project?

These are all scenarios that are a little more tricky in a fixed price situation. Most employers don’t initially consider these issues, because they’re more concerned about the finances. But, if you ask your programmer to do work (in any amount) above and beyond what was specifically agreed upon at the outset, they are not going to be happy. And I can tell you right now, that if you’re new to all of this, you are likely going to have to ask for extra features and functionality in your program (that you’re not planning for now.)


Secondly, if you decide to cancel the project under a fixed price contract, it’s difficult to figure out how to negotiate the situation. Do you pay a partial amount? How much work have they actually done? How do we come to an agreement?

Adding Developers

Another problem with fixed price contracts is bringing on another developer. It’s not uncommon to reach a point in your project where things just aren’t moving along as quickly as you would like. Perhaps your programmer is doing a great job, but they’re swamped with other projects. If you’ve agreed to pay them X amount, and, that was your entire budget for the project, you’re going to be hesitant to bring on fresh help because of the additional cost. You could easily double the cost of the project in order to get it done in a timely manner.

But, I think we’ve said enough about fixed price contacts. Let’s talk about hourly rates.

The Advantages of Hiring Programmers by The Hour

One thing I like about hourly contracts is that this model eliminates a great deal of the problems encountered with fixed price jobs. If I need an additional programmer, I just go find one and add them to the team. If my programmer isn’t working out, I fire them. They’ve already been paid for all the hours they’ve worked, and I am in possession of the code they have completed thus far.

Better Talent

A second advantage to hiring programmers by the hour is that you will generally attract better talent (at least on freelance sites). Experienced programmers have worked plenty of jobs and contracts, and, they know the rules of the game. Every experienced developer has had contracts that slowly got larger and larger (or more complicated than expected). When this happens on a fixed payment contract, the developer slowly watches their hourly pay sink lower and lower. And, it isn’t uncommon to end up working for minimum wage (or less).

If the contract is hourly, it’s just a minor nuisance or unexpected scenario. Either way, the developer get’s compensated and is generally ok with project scope creep.

Why should you care if your developer is happy?

Well, you want your project done professionally, quickly and correctly – right? And don’t you think the project is more likely to unfold that way if everyone is happy with the arrangement? If you felt like you were getting taken advantage of, would you feel obligated to do good work?

Saving Money

Another potential benefit is that, as an employer, you might actually save money by paying by the hour (if your developer is fast). Most people who hire for development projects for the first time don’t have a firm concept of how much time programming takes. Thus, they are likely to estimate either too much money or two little. As a result, it would be easy to overpay someone for the work they do if it’s at a fixed rate.

I’ve had more than one situation where I was prepared to shell out quite a bit more money than necessary. But as the project progressed, my programmer was able to complete the work in a fraction of the time I had anticipated. (And I’m a programmer!)

Hourly Rate Limitations

I think most people’s biggest fear with paying by the hour is that their programmer will either waste time or deceive them (since you can’t read code and you don’t know what they’re doing). While this is absolutely a legitimate concern, and does happen, it is rare in my experience.

After an interview, I generally have a pretty good feel as to whether or not I trust the person I’ve just talked to. And, this rarely fails me. In fact, I even rate the programmers I talk to on a scale of 1 – 10 in terms of ‘likeability’.

Most programmers are freelancing because they want to earn their income outside of a traditional employment setting. They want to own more of their time and learn some business skills. Consequently, most of them are trying to deal honestly and fairly with people (the best way to do business).

Another concern for many employers, is that their project will take a great deal of time, and, as a result, cost a great deal of money (if paid for by the hour). If you have a poor, inefficient, or negligent programmer – you’re right, you will waste a lot of money.

If you have a smart, intelligent, fast working programmer, you will oftentimes save money.


There is no right or wrong here, though, I’m guessing from reading this article you can tell my personal preference.

I like to hire by the hour.

Personally, I feel like this gives me a lot more control. I can pick who I want, I can give them big tasks or small tasks. I can hold development up for a week and pay nothing, etc…

And, I know that since most programmers prefer this form of compensation, I have a bargaining chip in my corner when I hire them, and thus, am generally able to hire better talent.

Whatever route you choose to go with, the basics of managing your project are essentially the same. If you communicate poorly, don’t explain your business and needs, don’t break down the different parts of your project, etc… it doesn’t matter what type of payment model you use, you’re likely to be dissatisfied with the results.

A Step by Step Guide to Hiring a Freelance Programmer on Odesk

30 years ago, if you wanted to hire a programmer, designer, writer, etc… you had to use the usual channels. E.g. hire a family member, ask a friend, colleague, put an ad in the paper, etc… Now, with some patience, no more than a few hours of work, and a little due dilligence, you can have an excellent, friendly, and qualified worker at very reasonable rates.

In this article, I’m assuming that you’re building (or looking to build) some kind of website or web-based software application, and thus, need a programmer. I am also assuming you know at least what languages you need this programmer to write in, and the difference between a front-end web developer, back-end developer, web designer, etc…

If not, no worries. I’m going to address all of those things in future posts.

An Overview of the Process

To be honest, I think the reason a lot of people walk away from freelance websites with bad experiences and horror stories, is that they didn’t approach their hiring process in the same way that they would have in the ‘real world’.

If you were going to pay someone thousands of dollars, and request that they come to work every day, communicate with you, and sit in your office, you’d make a point of ensuring they were a good fit before you brought them on.

You should do the same thing on Odesk. Just because the process and the worker are virtual doesn’t mean you get to be more lax about how you select and filter candidates.

I’ve hired a handful of programmers on Odesk and have yet to get burned, or, even to have a bad experience.

Here’s my process (adapted from my own methods and my mentor’s hiring practices):

Step 1: Explain The Job

I’m often surprised when I look at the jobs posted on Odesk and other freelancing sites. It’s not uncommon to find employers posting 1 – 2 paragraph job descriptions that don’t get into much detail.

The job posting is your first opportunity to attract the perfect programmer.

Programmers (the good ones anyway) often have a list of things they know they can do well, quickly, and affordably. They also know what they enjoy. So, if you hit a few of those touchpoints in your job posting, you’re much more likely to gather (at least a few) applicants who actually WANT to do your work. Odesk has an RSS feed that many contractors browser weekly for work. You want some buzz words in your job that grabs their attention.

This is important, as the quality will likely be better if they don’t hate you or the project.

Make sure you include any skills that would be required and explain the job in detail. No one is going to steal your idea on Odesk. You don’t have to reveal the farm if this is a unique tool or piece of software, but don’t be vague.

Step 2: Use a Catch Word.

This is a great tip that I got from my mentor/friend Joe.

In your job description, tell the applicants to include a word like ‘China Town’ (or something) in their response. This serves two purposes.

First, it shows you that any programmer who complies will make a point of reading your directions and paying attention to details. That’s important once development is underway.

Secondly, it allows you to thin the herd very quickly.

“Hey, no ‘China Town’ in this application – DECLINE!”

Step 3: Post The Job as ‘Paid Hourly’

I know, I know. You want to save money and not go over budget. Thus, you’re thinking that by posting the job at a fixed rate you will ensure both of the above.

You’re probably right; you also won’t get the best of the best applicants because smart programmers don’t work on fixed rate contracts. They’ve been screwed too many times and they know what their time is worth.

Worry not, you’re going to pick someone awesome who is also trustworthy and fast.

Post the job as hourly.

Step 4: List The Job Publicly

List the project publicly and let the masses apply. You probably won’t get very many quality applicants right out the gate.

Don’t by shy.

Turn down 90% of the people that apply. Save the best ones for later review.

Step 5: Thin the Herd

Delete any applicant with the following problems:

  • Poor English ability
  • Lack of attention to detail
  • No feedback or feedback less than 4.5
  • No hours on Odesk
  • Too expensive
  • Too cheap
  • Country of Origin…

This is going to make me sound like a huge jerk. But, I’m trying to help you out here.

If this is a serious or sizeable project, I would decline workers from India, Pakistan, the Philippines, Malasia, etc…

While there are quality programmers in these locations that can be had at rock-bottom prices, you really need to know what you’re doing in order to communicate effectively with most of them. You also need enough programming knowledge to sort out the good from the bad.

The majority of these workers (not all, just most) will be very task oriented, and, will likely struggle with your objecives. So, unless you’re in a position to micromanage the project, literally, down to lines of code, avoid 3rd world workers.

I know this might sound like I have something against these people or countries. I do not. But I’m writing this under the assumption that you’re trying to build something of moderate complexity, and that you don’t want to spend your time and energy sorting out communication problems and trying to figure out why your program only works in one web brower and not another.

Ok, enough said.

Step 6: Be Proactive

This is important!

Browse Odesk for people you DO want. I’ve found particularly good value from Western AND Eastern Europeans, U.S. contractors, Australians, etc…

Usually I will seach Odesk’s contractor database by rating (4.5 andup), skill tests taken, and English ability.

If you’re on a budget, Eastern Europe is a hotspot right now, as many of these workers have excellent English skills, but live in countries where the cost of living is low-ish.

Expats living in less expensive countries can be good value as well. Invite at least 10 – 20 (most will decline).

Step 7: Pick Your Best 4 – 6 Applicants

At this point, you’ve probably spent 1 – 3 hours on your search. Don’t be lazy. Trust me, you will be glad you found the perfect worker when this is all over.

Pick your top 4 to 6 candidates from the ones that applied and the ones you requested to apply. These should be people you are serious about. And any one of them should be on the table for you.

Pick 8 – 12 different interview time slots that work for YOU, and send two options to each person. If they can’t make one of your slots (be considerate of time-zones), they aren’t going to try and cater to you later, so you can safely move on to other prospects.

Step 8: Inverview Via Skype

You need to do this.

This is probably the most fundamental part of the whole process. Talking to these people will give you a feel for their personalities, abilities, interests, skills, etc…

And, most importantly, it will tell you whether or not this contractor will be a good fit for your style of communication and workflow.

I’ve learned a few interviewing tricks in the last few months, but this article is already getting pretty long. So, we’ll save that for later. However, make sure you ask about availability, interests, pricing, time-tables, and any negative feedback they might have.

Step 9: Pick One

Assuming all of them are qualified (and they should be if you’ve done it right), pick the smartest guy/gal with the best social and writing skills that you interview.

Good written and verbal communication skills suggest intelligence, organization, clear thinking and amiable personalities – all good qualities to have in an employee.

You should like and trust this person, as they might end up having access to your web server, private business information, passwords, etc…

Don’t take this lightly. If someone gives you a weird vibe, or just doesn’t seem to fit – move on.

If you enjoy talking with them, and, could see yourself happy to buy them a cup of coffee and chat, then, at a minimum, they aren’t likely to screw you over.

Step 10: Pat Yourself on The Back

You’re done!

The total process will probably take 1 – 2 weeks. 3 – 6 hours invested. But once you’re using your website or selling the software that your genius programmer built, you’ll be glad you made a smart investment up-front.