Are Your Contractors Putting in Their Hours?

When a developer has code on their screen, how do you know they are putting in effective work? Or, more fundamentally, how do you know they are even working on your product? Managing a contractor’s hours gets even more difficult if they are working remotely.

In fact, tracking hours that contractors put into building your product is so tricky, I advise against it altogether. So the question remains- how do you know what to pay contractors?

The solution is simple: you pay based on the value and product that’s delivered.

The 10X Programmer

The concept of the 10X programmer –an individual who is as productive as 10 others in the field– is something that continually circulates in the tech world. And after getting experience in programming, I am a firm believer that it’s not an exaggeration.

This isn’t the case in every industry. For example, even in sales, where top salespeople outperform their peers by large percentages, they never quite sell 10X more. This is because even the best closers rely on a solid pipeline of leads and building it takes time. No salesperson has 10 times as much time as their peer does.

When it comes to programming, it’s not necessarily that one programmer is literally 10 times better than another. In fact, the superior programmer may perform trivial tasks only slightly faster than the more novice programmer. However, there are instances when the superior programmer can move at 10X the rate of the novice.

To illustrate: a novice developer building a proper authentication system may run into technical challenges that require learning, additional resources, and several attempts before finally getting it to “work,” which ends up taking three weeks, as opposed to the expert who has done the same before, and builds the proper auth in one day.

Because the difference in the rate of production from one programmer to another is so drastic, it’s even more reason that tracking hours is arbitrary. So what’s the solution?

Productivity as a Measurement

You need to use overall productivity as your measurement. One tool that should always be used is a task board such as Trello or Jira, where you can view the development cycle. I like to break the board down into the following sections:

• To Do
• Doing
• Done
• Ice Box
• Ideas/Features for the Future

I also like to add color-coded tags on each card: Bug, Low Priority, Design Related, Roadblock. Then, there is a rotating tag for the current Sprint, so that you can easily filter cards by the most important ones.

One thing to note: some of the best programmers may not be so great at tracking their tasks on Trello. It needs to be taken with a grain of salt when using to judge how productive your contractor is. If it’s a tool you want to use, the correct expectation should be established early on (and should be updated daily), and if there are any red flags, such as a card sitting in the “doing” category for multiple days, it’s possible that it’s already done and they just haven’t moved it.

You can also look at github commits. But similar warning: it’s certainly not a definitive way to measure productivity. One commit could be 10 times more valuable than another. If anything, it could be used as just another way to notice red flags. For example, if your contractor is claiming they are working each day, but you’ve never seen a single commit outside of Saturday, it could be a problem.

Ultimately, the best way to measure productivity is to know your own product extremely well. Contractors should generally be brought in for more specific features and when the product manager or lead engineer knows the product well, they have good measurements of what the feature entails and how to measure its success.  

My preferred approach to managing payment to contractors is a hybrid that relies on the overall value, but also takes hours worked into consideration. The contractor should propose a worst-case scenario, expected scenario, and best case scenario, and each should be based on the number of hours that will go into development. Something even as simple as this:

Some advantages here:

• There is an absolute minimum and max established
• The range is fairly wide, which will give some wiggle room if you need the contractors building out a few extra features not mentioned in the original proposal
• The contractor won’t necessarily just go for more money in the “worst” scenario. One contractor I trust consistently delivers somewhere in the “expected” category, and I came back to him with more business and referrals.

Implement the practical tips, know your product well, and you will never have to lose sleep over whether your contractors are putting in the hours or not.

Ready for more? Check out How to Avoid Micromanaging and Become a Great Coach Instead.