Do I need a consultant, contractor or employee?
Here’s a scenario I find myself helping out with a bunch. I’m working with a small company, say a couple dozen employees, and they have a gap. Maybe it’s a capacity spike: they need to build new features by a tight deadline to land (or keep) a customer. Maybe it’s a skills gap: they’re implementing end-to-end encryption and need to get the cryptography right. Maybe their staff are chronically over-subscribed.
Most companies jump right to hiring full-time, but that’s not always the right approach. In many situations, I think companies – particularly small ones – will be better off with contractors (or occasionally consultants). When and why would you prefer that over a full-time employee? What’s the difference? Read on!
The difference between employees, contractors, and consultants
For my purposes, I’m defining employee as: full-time, indefinite, and dedicated. That is, employees work a full work-week (40 hours or whatever) for you, have no other work obligations, and there’s no fixed “end date” on your working relationship. (Yes, part-time employees are a thing, as are employees with other jobs, but both are somewhat rare in the tech industry that makes up the bulk of my audience.) Full-time employees are usually salaried (again, in tech), so there’s a fixed, predictable cost. They usually have the most flexible job responsibilities: it’s not uncommon for an individual’s role to change and shift, sometimes dramatically, throughout their employment.
Contractors, by contrast, are often paid hourly (so their costs are flexible), frequently work less than full-time hours, and often are on contracts with fixed end dates.
The line between consultant and contractor is blurry. From a logistics standpoint they work similarly, but the kind and style of work is usually different, which I’ll get into below. Consultants usually charge more than contractors and frequently work on fixed-fee or weekly/monthly bases rather than hourly.
Some caveats:
- These definitions are vague. I’m talking in broad generalizations here; there are exceptions to nearly everything. But it’s helpful to have at least a rough sense of what the differences are, structurally.
- I’m also deliberately not covering legal distinctions. There are quite important legal differences between employees and contractors/consultants, but I’m not a lawyer. I’m writing here about what we might call “cultural” differences: differences in expectations, management, style, and general practice.
- Finally: this is US-centric and drawn from my experience in tech. Other countries, and other fields, probably differ.
When should I use a consultant, contractor, or employee?
You should hire a consultant when you need help with strategy and/or vision, and/or you need very complex deep domain knowledge. Consultants typically aren’t hands-on; they’ll work with you on high-level strategy/design/guidance, but leave implementation up to you. So you’ll need staffing – and need to give them time – to execute on the consultants’ recommendations.
Consultants are quite expensive — you want them to be. You’re paying for expertise, and experts aren’t cheap. Used correctly they can be incredibly high-value, but they can be a total boondoggle if you don’t use them correctly. As an example, a consultant friend of mine once saved a client over a million dollars a year in under a week of work. He charged them $50k for that one week. That’s a huge sum for a week of work if you’re not getting any value out of it, but given the value he provided, everyone’s thrilled.
If you’re going to hire (expensive) consultants, you must be prepared to take their advice. One memorable story: a company had this ambitious product roadmap involving zero-knowledge computing, end-to-end encryption, and other fancy cryptography stuff. They did the thing you’re supposed to do and hired cryptographer consultants to design the features in question. They spent tens (hundreds?) of thousands of dollars … and never implemented the design (or any design). Turns out, they didn’t have anyone on staff with the engineering skills to implement something like this, even with a detailed design, and didn’t have the funding to hire anyone.
Most often, a consultant’s “work product” involves more work, a roadmap for your team. If you know you’re not going to be able to implement their recommendations, hiring consultants is throwing money down the drain.
Contractors, on the other hand, let you exchange money for features. You should hire contractors when you have specific, well-defined outcomes and need people to execute. The clearer and better defined those goals, the better you’ll find working with contractors. Usually, contractors are hired for goals that are in some sense time-bound (often implicitly time-bound by the completion of a project), which points to one of the main advantages of contractors over employees. The shared understanding that contracts are short-term and time-bounded makes it much more OK to end a contract that’s run its course if it isn’t working out. I wouldn’t consider it ethical to hire a full-time employee with an expectation that you’ll only employ them for three months, but I’d consider it fine to hire a contractor just for that same three-month project. (This isn’t to say that you can’t have open-ended, long-term contracts, or short-term employment contracts with mutual agreement, but these are somewhat unusual.)
So, essentially what you’re getting out of contractors (vs. employees) is optionality. It’s far easier to ramp contractors up or down in response to workload. This leads to a couple of more subtle points about using contractors effectively:
It is sometimes true that contractors can be cheaper than employees, but be careful here: remember that the point is optionality, not cost-savings. Contractors can certainly be much cheaper than full-time staff, but you get what you pay for. Don’t try to save money at the expense of quality. If you end up saving money, nice bonus, but that should in no way be your deciding factor in choosing contractors. Choose based on quality and maximum flexibility. In some cases, this means it’s worth paying contractors more than you would pay staff!
It’s often better to hire a contracting firm, rather than working directly with individuals. Once again: optionality. If you contract with a solo Django developer and then a few months in land a huge sale that means you need to squeeze person-months of work into just a few weeks, that single person can’t help. You’ll need to look for and bring on more people, who will have to learn to work with your existing solo contractor. But if you’ve contracted with a firm to get that one person, the firm may able to help you burst capacity and bring on more staff – and those staff will have already worked with your existing contractor and should be able to ramp up quickly.
I think many times companies — particularly small ones — jump to full-time hires when they should be more strongly considering contractors. I often advise small companies still looking for product/market fit to seriously consider working with a contracting firm and delaying much of their engineering hiring. Being able to burst capacity to land a big sale, or temporarily bring on additional staff with other skills or expertise, can be huge.
So, finally, let’s talk full-time hires. You should hire full-time when you have ongoing, indefinite needs, and/or those needs are vague, and/or you have expectations of autonomy and ownership (including leadership roles). The main advantages of full-time staff over consultants are predictability and flexibility.
Optionality cuts both ways: it’s easier for you to end a contract that you’re no longer getting value out of, and the contractor can likewise decide to move to other clients at any time. Yes, full-time staff leave too; once again this is about culture and expectations as much as anything. With full-time staff, you can make plans that stretch much farther into the future with a greater degree of confidence.
There’s a point in most product development where the scope of work starts to become more predictable. Early on, before you have a solid, well-defined product, there’s a lot of bursty work to get initial features built. That work maps well to shorter-term contracts. But as the product matures, the amount of work becomes more predictable. Sure, you can’t predict which features you’ll be building a year from now, not really, but in a somewhat mature engineering org you can have a pretty good sense of how much work you want to deliver each month/quarter, and how many staff you need to reach those goals. Put another way: once your product has enough customers, you now know how much money is coming in, and can decide how much of that budget to devote to staff. So full-time hires make more and more sense the more mature your organization is.
Perhaps the best example of this comes from infrastructure work. Early on, when you’re first building out your production infrastructure, it can make a ton of sense to contract for the initial build of that infrastructure. Experience and economies of scale mean that a firm like CloudPosse1 can get your entire production infra built in less time than it’ll take you to get headcount approved. But over time building infrastructure gives way to operating and maintaining infrastructure, and as that work becomes more predictable and less bursty, it makes sense to build an SRE team in-house.
As for flexibility: you can generally expect full-time staff to cope with changes of technology or even role better than contractors. Say you decide to migrate from AWS to GCP2. If you’ve been working with contractors to build your AWS infrastructure, there’s a solid chance you’ll need a new firm to help. At the very least you’ll almost certainly need new people on an existing contract. That’s because contractors generally land business by being experts. When you were looking for AWS contractors, you probably weren’t looking for GCP experience too. So it’s quite likely that you hired AWS experts who know nothing about GCP. That would have been a fine decision then, but you’d be in trouble now. And it’s rare for either side of a contract to want to invest in training. For full-time staff, on the other hand, it’s fairly reasonable to decide that, as part of a shift like this, you’ll invest in training and your staff will move along with it.
This plays out with product decisions as well. As I mentioned above, contractors do their best work with very clear and specific goals/outcomes. Usually that translates into clear and precise feature definitions. If those change, there’s often some work to renegotiate the contract, particularly if the change in direction means a change in scope. With full-time staff, pivots are easier all around.
This is the most true when you’ve got ill-defined or vague product/technology direction, or when you want staff who can kinda make it up as they go along. Contractors don’t do well with autonomy because it’s a big risk to them: “go build whatever you think is the right thing” is terrifying for contractors: they fear getting it wrong and not getting paid!
Leadership in general is something that contractors (and consultants) often can’t do effectively. The goal of trying to please your client conflicts with leadership’s need for Real Talk at times. Job security, something lacking in contractor/consultant relationships, really helps people deliver hard messages or navigate through unpopular changes.
Summary
Here is a dramatically over-simplified summary:
- Hire consultants when you don’t know what to do, and need an expert to tell you.
- Hire contractors when you know what to do, but need more people to do it, and want maximum flexibility to scale staffing – up or down – quickly.
- Hire staff when you want to optimize for predictability of bandwidth, and/or want the ability to change strategic direction, and/or need autonomy and leadership.