The Problem With Contractors In Software Projects

November 14, 2006

Every project I’ve worked on has had at least one contractor working on some part of it.  I’ve worked both as a contractor and with many and I’d like to discuss a few of the problems I’ve seen.  Some of these problems are quite subtle and I believe are often overlooked by managers of software projects.

1.  Pay difference

There’s just something about knowing that the person sitting next to you is earning twice as much (or more) than you, per hour.  Even though contractors have to pay their own super, holidays, sick leave etc, they still often end up earning a lot more on an hourly basis.  This builds major resentment between the contractor and the rest of the team.  A while ago I talked about keeping programmers happy by not letting them know how much they are being billed out at, compared to how much they are receiving.  Knowing how much more a contractor is getting paid is even worse!  It’s basically saying that some guy who doesn’t even work at your company is more valuable than you are.  I don’t care who you are, that hurts.

2.  Shows a lack of planning in management

Needing to hire a bunch of contractors at the end of a project (as it runs overtime and grows in budget) shows that management can’t properly plan for the future.  They’re saying that they didn’t think that the project would run over time or budget and by the time they admit it, the only option is getting in hired help.  It’s a basic fact of all complex software development, it’s generally going to run over time and budget and management needs to stay on top of this and supply enough resources as soon as the need is realized.

3.  Can’t hire good people

Unlike #2, if you have a bunch of contractors on a project for its entirety, it shows that the contractors wouldn’t dare work for your company.  How does that make the rest of the employee’s feel?  It makes most people I know feel like they’re stupid enough to be paid less for to do exactly the same work.  If your company hasn’t got enough incentives to make people want to work there full-time then something needs to be done.

4.  Team doesn’t work as well together

Unfortunately, your contractors will be outsiders.  For the reasons above, the rest of the team will resent them and you can’t have good team cohesion with this resentment present.  Thankfully, most contractors are nice, happy people (otherwise no one would hire them) which keeps the resentment from becoming personal, but it’s still there at some level.

5.  They don’t care as much about the project

On the flip side to #4, it’s hard to have as much passion or care about a project you’re simply being paid to work on.  From monetary incentives like profit sharing down to not being part of the full company dynamic, contractors just won’t care as much as their regular employed colleagues.  If they were passionate, they’d be an employee, living and breathing the game and the company.  The bottom line is that contractors are mercenaries; they go to the highest bidder at the time.

Share:
  • Digg
  • Reddit
  • Facebook
  • del.icio.us
  • DZone
  • LinkedIn
  • email

Find Us On Facebook

Filed under:
Game Development by Doolwind

  • No Related Post
  • Mcdrewski

    I know exactly where you’re coming from, but disagree on almost every point.

    1. As a full-time employee, you are paid based on a long-term basis. You are paid when there’s very little work to do, and paid when you’re in milestone crunch. A contractor is paid for a short duration. Neither of you is paid more than the company values your services for (although yes, either of you may be paid less). Unless you can honestly say that every single “senior” is exactly as good as each other, then there will always be pay differences. This is how the un-unionised capitalist system works.

    2. Sure, but also shows a willingness to step up and admit mistakes/underestimates to get things done. If your options are to move the deadline with existing staff or bring in contractors, why is bringing contractors the wrong choice?

    3. Typically a contractor is hired for two reasons. (a) The company needs work done and (b) The contractor can get the work done in the time needed. Most people need to give around a month’s notice to take a ‘real’ full-time job, and that is much much longer than the typical contractor startup time. You might be caught in the situation that you’d love to hire new people fulltime, but there is nobody available right now who can actually help. You also fall back on the “paid more for exactly the same work” argument from #1.

    4/5. This is that “Passion” and “Loyalty” argument I hear so much about. If you’re passionate about the project, why is it that someone from outside who is helping to get your profit sharing and your company’s game published a problem? If they’re not helping, then you need to let management know right now that the contractor isn’t doing what they’re being paid for. If they are, then thay’re helping *your* intangible goals no matter what *their* motivation is. That means that while they’re helping, who cares why they are? While they’re not, hit the ejector seat button and drop them right this second.

    Sure, working with a contractor is difficult. There’s the regular dilbertesque/office space scenario where because the contractor is “from outside” and paid “so much more”, that their opinions matter that much more to managment. This is a mistake that everyone should work to avoid. Otherwise, you are, as you say, hiring mercenaries to get the game shipped. That’s really what we’re all in this for, right?

  • http://www.doolwind.com Doolwind

    Firstly, I agree that there is definitely a time and place for contractors, and I can’t see them going away any time soon. My main motivation was to point out some of the subtler problems I find with contractors to try and bring up debate such as this. Thanks for your comments, now on with my counter arguments :)

    1. “Unless you can honestly say that every single “senior” is exactly as good as each other, then there will always be pay differences.”

    This is true, however the problem with contractors is that they are often paid 2-4 times as much as their equivalent position would as an employee. I doubt you’d find two “seniors” that have this kind of disparity in their pay. Whereas with two equivalent programmers working for the company may have differences in pay based on skills/experience/time with company, a contractor automatically gets more simply because they are a contractor. It’s hard to think objectively about this pay difference when psychologically it just seems like you’re both sitting there doing the same work for completely different money.

    2. “If your options are to move the deadline with existing staff or bring in contractors, why is bringing contractors the wrong choice?”

    Definitely, if these are your only two options, go for the contractor, that’s why there will always be a place for them in the current climate. The problem I have is when managers blindly believe that ‘everything’s just fine’ and there’s no need to bring in new employees or swap them from other projects. They often go on believing this until it’s so late in the project that their only option is to bring in a contractor.

    3. “You might be caught in the situation that you’d love to hire new people fulltime, but there is nobody available right now who can actually help.”

    Again, if it’s the only option then definitely hire a contractor, however if you have the choice, it’s better to go with a full-time employee.

    4/5. “This is that “Passion” and “Loyalty” argument I hear so much about. If you’re passionate about the project, why is it that someone from outside who is helping to get your profit sharing and your company’s game published a problem?”

    I think for games the problem of lacking passion is how that fits in with making an awesome game, compared to a mediocre one. Fun is such a hard ingredient to add to games and I think you’re at a major disadvantage if you’re workers aren’t passionate about what they are creating.

    Thanks again for your comments, I agree that contractors can’t be removed, and if they are the only choice it’s better than nothing, but I believe managers need to think before just throwing them at a problem.

  • http://www.runesofavalon.com Roman Budzowski

    Great points from both of you – Doolwind shows the perspective of an employee and Mcdrewski of an manager. Then, no matter who you hire, fulltime employee or contractor – make sure one fits the project well (and finding out that part is the hardest task for managers).

  • http://www.doolwind.com Doolwind

    Roman-
    You couldn’t have put it better. I’ve seen excellent and terrible contractors and full-time employees. Most people can program fairly well, finding someone that can program, communicate, get on with everyone on a team and generally be productive is much harder to find.

    It seems with the current shortage in programmers we’re experiencing at the moment companies are having to simply go with what they can afford, which often isn’t what’s best for the team.

  • http://stodge.blogspot.com Stodge

    I’ve worked with some incredibly good contractors over recent years. And I’ve worked with some incredibly bad ones. It’s a crap shoot at times and I often wondered how these people get hired with trumped up resumes. It still leaves me scratching my head.

  • Jensen

    good discussion.

    plus the fact that when the Contractors leave, they are out and have no obligations. meaning that all support, mainenance etc. goes to regulary staff.
    abd in the last period of the contract, the level of commitment falls, postponing all the shit until after they have left.