Managing p/t consultants like Open Source contributors?

Question

I just assumed tech lead for a project which has had a problem with its very part-time (maybe 2-5 hours / week) contractors:

• submitting code that brings down the production app,
• pull requests that cannot be auto-merged,
• writing misnamed tests that don't actually test what they claim, and
• not writing tests for the new submitted features.

A big problem is that these remote, part time contractors aren't in the office to respond immediately if there's a problem with their code.

Also, I'm the only full time developer on the app, and we can't afford to have my time spent checking and debugging others' code.

My idea is to adopt an open-source working style with them. I.e., would a big, important project (like Linux, Ruby, Rails, etc.) accept the proposed changes? We find out the criteria they have and then enforce that. We let go any contractor who doesn't play by the rules.

Is this the way to handle the relationships?

EDITED: To highlight the very part-time nature of the contractors. Less than 10 hours per week, usually 2-5.

Answer 1

One thing I kept trying to get across in my previous company with limited success is that a project needs to maintain a minimum thinker-to-doer ratio, if you get to the threshold and go beyond that, you'll find yourself in a situation that you are in. Way too many people who simple "do" the tasks are actually introducing more damage than good.

That's why I kept telling my boss and his boss that we need to spend time and invest in people. Give them some freedom and also more responsibility (if they choose to have it, don't shove it down their throats) and promote more thinking and taking ownership for the product.

However, everything I've dealt with has been internal within our own development team with full-time people on it. I've never been in your situation and it almost seems that contractor by its definition is a "doer", but then again, not necessarily.

So my only advice, and I'm making most of this up would be:

• See if you can get one more permanent person on your team to help you with reviews and monitoring
• Limit number of contractors you work with so that a) you only keep the top N which cause the least amount of overhead and b) you have more time to do your job, not just do reviews all day
• Identify good, long-term contractors and try to convert some of them into "thinkers". If you like working with them and they like working with you and you already established expectations, see if you can establish some kind of hierarchy where those guys would actually review work of other contractors.
• As you suggested, establish some base guidelines that everyone should follow and when you do a review, if those guidelines aren't met, reject it with minimal effort on your part.

Unfortunately, IMO last thing you want to do is stop monitoring/reviewing/mentoring them. As Dan suggested in the comments, as a team lead, this is your higher priority than delivering your own code.