Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
2  
big important projects (like Linux, etc) have lots of people who can check and debug other's code. –  Dan Pichelman Oct 15 '13 at 19:37
    
Thanks - I'm beginning to realize that. So I'm wondering what my expectations should be of contractors who work for me. –  Dogweather Oct 15 '13 at 19:42
3  
You're the tech lead. What's more important than communicating priorities, setting goals and ensuring compliance from your contractors? Certainly not writing code anymore. –  Dan Pichelman Oct 15 '13 at 20:06
4  
I wasn't trying to be ironic. You said the project has had a problem with its contractors. Since you're the new tech lead, it sounds to me like you now own that problem. What's the best use of your time? If I were your boss I'd encourage you to spend the time necessary to fix your development process over spending time cranking out code. –  Dan Pichelman Oct 15 '13 at 20:43
2  
The most difficult adjustment moving into certain roles is learning that you're less valuable as a coder than you are as a leader. –  Mike Brown Oct 15 '13 at 21:14

1 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.