How to effectively utilise contractors

The main thrust of the arguments I'll make here is that the most effective way to utilise contractors is to assign them simple, well defined, well contained units of work that they can plough through. Organisations should avoid delegating architectural decisions to contractors.

Note that throughout this article I'm referring to hiring contractors within the context of general software development.

Note also - you don't need to be hiring contractors to get value out of the advice I'm giving here. The suggestions I make will be helpful in structuring and breaking down the work in any software development organisation.

There are some exceptions to the advice I'm giving here:

• When you're hiring a contractor with a specific niche speciality, to achieve that one specific thing.
• You're hiring an experienced contractor to train your salaried engineers and bring them up to speed.

Common mistakes organisations make in hiring contractors:

Thinking that more pay = better work.

I think that, even if just subconsciously, stakeholders can believe that because they're paying contractors usually significantly more than their salaried engineers, that the contractors are more effective or are producing high quality work.

But to give a simple example as to why this is a logical fallacy - I've worked as both a contractor and a salaried engineer in Melbourne. As a contractor I was earning $850/day, and as a salaried engineer I was earning $135k/year + super. Just because you're paying me a daily rate doesn't magically make me a more experienced or better engineer.

Not assigning contractors simple work 'because we've got to get our money's worth'.

By a similar token I think stakeholders are often reluctant to assign small, simple tickets to contractors, as 'this is something we could get our juniors to do' and 'we're paying the contractor so much, we might as well get them to do something difficult'.

Firstly, I would agree that the small, simple tickets that I'm talking about are suitable for juniors to pick up. However, these also make for good tickets for contractors to do. The differences are:

• The contractors should be getting through the tickets at a much faster clip than the juniors
• The contractors should be fairly self reliant in doing these tickets.
• With a junior, you're not just getting the work done when you assign the work to a junior, you're also giving the junior training and experience.

Not understanding the contractor's incentives

A contractor has different incentives to a salaried engineer.

A contractor wants to be seen to delivering features quickly, this justifies their high day-rate. If the going gets tough, and the job no longer becomes fun, the contractor can just leave to their next gig.

A salaried engineer on the other hand has the long term prospect of working on the code base to think about; the salaried engineer is also thinking 'I need to be working on this codebase in a years time, I don't want to be a building myself a nightmare to work in'. The contractor on the other hand, may have no such qualms and be more inclined to produce quick dirty fixes for the product owner asking for it.

Being reluctant to assign salaried engineers away from their currently assigned work.

I think often stakeholders see reassigning engineers as disruptive. There maybe some bureaucratic reasoning here, performance targets for the engineer may be tied to the project they're working on, or reporting lines may be difficult to change.

Also, reassigning engineers can be demoralising, I would certainly encourage some amount of caution when it comes to reassigning engineers; basically ask them if they like the idea of being reassigned.

Reality is - there are probably plenty of engineers in the organisation who are chomping at bit to the architect a solution.

How I recommend managing contractors

Unfortunately, what I propose is subject to Brook's Law - "adding manpower to a late software project makes it later".

Define a set of constraints that the contractor works within.

Don't give the contractor free reign to 'do what you need to get the job done'.

Instead, ideally they will be coming in with a clear list of dos and don'ts and a task list to achieve against these dos and don'ts.

For example some dos and don'ts:

• We write our React components this ways, use this snippet to generate them.
• We write our REST API endpoints this way
• We want to see corresponding tests - see these test examples for what we're looking for.
• Don't install any new dependencies (ask if you think they're needed)

As for a task a list:

• Implement XYZ endpoint
• Create SuchAndSuch component

Work needs to be done upfront, to get most effective use out of a contractor

Your senior salaried engineers will need to spend time building or defining the constraints the contractor works under.

This shouldn't be considered a small task that can happen along side the engineer's other project work - this should be their primary task.

Addressing objections

The quick dirty fixes are what the organisation wants

Putting my pragmatic hat on, I accept that this may be the case. Perhaps there's a deadline coming up and we need to showcase this feature to investors to secure more funding.

If this is the case then the organisation needs to be very clear that this is the strategy, and the salaried engineers can be coming along for the ride too. (Or working on v2 of the feature with the plan of potentially completely scrapping the initial feature).

What they shouldn't be doing is relying on the contractors to be creating quick and dirty fixes, while also telling the salaried engineers that 'we care about code quality and long term maintainability'. The contradictory messaging causes confusion and frustration and will have a demoralising effect on the organisation.

You're being cynical and distrustful about the quality of code that contractors produce

You might be right that it's possible for an organisation to hire just the right contractor, assign to them to architectural work, and they do an outstanding job of it.

However, I would argue that if it's possible to hire a contractor to do such a job, then it should be equally possible to hire a salaried engineer to do the job.

If it's not equally possible, then I would suggest that the organisation needs to increase the salary you offering potential salaried employees.

I would argue that on balance of probabilities, it is more likely to get that outstanding job from a salaried engineer.

Hiring salaried engineers takes time, and we need someone to build this feature now.

This indicates a deeper problem within the organisation which in the long run, is going to cause a lot more problems than the lack of this one feature will.

For one, the organisation is apparently having trouble attracting or retaining salaried engineers who are able to build the feature. What's possibly more likely, is that the organisation does have salaried engineers, but they're reluctant to assign them away.

If you agree with my argument that a contractor is less likely to produce maintainable code, and you're saying 'despite this, it's worth the risk, because we need this feature now', what you're also saying is 'we're ok slowing down all future work to get this thing done now'. Probably a reasonable decision to make if the company is otherwise about the close the doors, but if you've got a couple of years of runway - I'd reconsider.

We want to hire a contractor because they're got the experience and our team is not particularly mature.

Let's say you've got a team of self taught developers, they've built something and it's a year or two later, they've built the proof of concept and you've secured funding, but things are running into the mud and you're having trouble iterating. You think 'let's get some experts in to help us out'.

Certainly, I feel I need to carve out an exception for myself here - in some future scenario where I'm working as a contractor again, I don't want to advise that 'You wouldn't get very good value out of hiring me because I'm a contractor'.

However, the key thing I would highlight here - is that you would be hiring the contractor in the role of an educator not as somebody to build out architecture.

Building out architecture might well be something that they do, but the important thing a contractor in this role should be doing explaining why they're doing they're doing and spreading the knowledge and experience as much as possible. What they shouldn't be doing is dropping a whole heap of code on your lap, as pristine as it might be, and then leaving. That won't solve your engineering maturity problem.