Consultants vs. Employees: The Real Costs
I hear from a lot of potential clients that they can't afford consultants. So I ran the numbers, because we're a Rails consulting firm and we rely, for better or worse, on people that don't have employees.
I also have a vested interest in not costing our clients too much money, for obvious reasons.
What follows is my thought process on estimating the cost of a Rails or iOS lead developer / project manager position, which is typically what most of our clients are emulating when they hire us.
Along with that thought process, I'll address a few of the fallacies I've encountered when people make the argument that an employee is de facto a cheaper alternative to a consultant.
Before we get into it, I have to say that this post is specifically addressed to small businesses weighing their options when choosing to hire an employee or a consultant to build software. It is not a slight on existing product employees, nor is it a final answer for all hiring decisions. It's just, like, my opinion, man.
Anyway, TL;DR: consultants are slightly more expensive than an employee until you account for opportunity cost and capacity utilization; when you do, consultants are crazy cheap compared to employees.
Fallacy the First: "Employees are cheaper because they're salaried"
I get it. A salary looks like a predictable, regular expense, which is desirable. But talk of salaries almost always leaves out any of the associated costs of a full-time employee (like health insurance, 401k, etc).
Here are some base adjustments you can make to get closer to the true cost of an employee. This is by no means an exhaustive list, nor does it necessarily represent your conditions (you may not be paying Maryland unemployment insurance, for example), but it should at least help illustrate how a salary is just the starting point for estimating the true cost of an employee.
- You pay a team lead / project manager a salary of $100k
- You pay for $5k in health insurance
- You match 3% for their 401k
- You pay 2.6% unemployment insurance per quarter on the first $8,500 of their salary ($884 / year)
- You buy them a nice, new computer every three years ($1,000)
|1 salaried employee||=||$109,844|
Tack on a few free lunches, and your employee costs about 10% more than you thought they did.
Fallacy the Second: "Employees are profitable all year"
I'm not sure why people forget about this one, but it's rare for someone to show up every week across an entire year. So to calculate an employee's hourly rate (in order to compare them to a consultant), you need to figure out how many days they actually work.
These base assumptions are taken from our vacation policies and the national average for sick days.
- There are 260 workdays in a year (52 × 5)
- There are 9 bank holidays a year
- You offer 20 vacation days a year (we do, and you should, too)
- They take an average of 8.5 sick days a year (it happens)
|260 weekdays - 9 holidays - 20 vacation days - 8.5 sick days||=||222.5 workdays per year|
Fallacy the Third: "Employees work forty hours a week"
Come on. You probably don't; why would you expect everyone else to? Here's a realistic breakdown of the average programmer's workday:
- Your office is open 9am to 5pm
- Your employees take an hour for lunch
- Your employees take an hour to sustain life through bathroom, water cooler, and other breaks
- Your employees spend at least an hour on Facebook, Reddit, Hacker News, or whatever else they're into (and this is a generously low estimate for "time playing on the internet")
- Your employees spend an hour a day meeting with you or someone else, conducting pre-work planning
If you just said, "my employees are productive way more than four hours a day," you are living in Dreamtopia. There has never been a bigger productivity murderer than the internet, and guess where your programmers work?
But there's a huge upside to this "lost time": programmers are way more valuable when they're keeping up with all of the developments and new ideas that are popping up in the ever-shifting sands of Rails development. The hour(s) they spend "screwing off" are often more valuable than they would be if spent repeating the same rote task over and over again, especially if you'd like them to stick around and be happy doing it.
Anyway, that gives us...
|8 hours - 1 hour lunch - 1 hour poopin' - 1 hour screwing off - 1 organizational hour||=||4 hours per day|
|$109,884 per year 222.5 days × 4 hours||=||$123 / hour|
Now we have a number comparable to a consultant, whose hourly wage calculation is roughly something like the following:
|$150 1 hour||=||$150 / hour|
So... ZOMG CONTRACTORS ARE MORE EXPENSIVE sorry, my knee jerked.
There's (always!) more to the story than that.
Fallacy the Fourth: "I can keep an employee busy indefinitely"
I realize you believe that now, and that may even be true for the first few months of a new employee's engagement. But you're eventually going to run out of stuff for them to do, at least from time to time. Maybe it's just when you and your management team need to meet with customers to figure out which features to prioritize, but whatever the case, every job has some downtime. Which brings us to capacity utilization.
Capacity utilization is the amount of work you put through your productive assets relative to their maximum potential production.
In software engineering terms, it looks something like this:
|Capacity Utilization||=||Hours You Actually Work Hours I Pay You To Work|
Since we already calculated an employee's hourly rate based on hours they actually work, let's use a daily capacity of four hours instead of the all-too-common "8 hours totally bro."
What happens when you don't have enough work for them to do?
|3 hours of work 4 hours of productive time||=||75% capacity utilization|
Which does the following to an employee's hourly rate:
|$123 / hour 75% time utilized||=||$165 / hour|
Again, I realize you probably have more than enough work for a programmer right now. It's when you don't that these cost problems will start to crop up.
Taking a weighted average of, say, 85% capacity utilization across an employee's time at your firm, you're looking at:
|$123 / hour 85% time utilized||=||$145 / hour|
Not bad. It's a little better than a consultant, but of course, a consultant's capacity utilization is always 100% - you don't pay them for hours they don't work (or at least you shouldn't, silly).
Fallacy the Fifth: "My experienced employees can get it done just as well as a consultant"
There's a central concern I have with efficiency when it comes to employees: at some point, they'll have been working on your software for a long time. That means that they'll have gotten really good at solving problems with your codebase, which most of the time is awesome since they're going to be more efficient at maintaining that codebase than an unfamiliar consultant. But this creates two problems.
First, I'll just rephrase what I said in the previous paragraph in a slightly mean way: they're one-trick ponies. I could also trot out Brad Pittisms, like, "to a hammer, everything looks like a nail."
Someone who knows how to solve your one problem twelve different ways may not know how to solve the new ones all that well. True, they have the capacity to find a solution, but the time it takes your employee to solve a new set of engineering challenges will always be more than it takes a seasoned consultant who has already done the legwork. Or at least that's true for the kind that demands a $150/hour rate.
It's pretty simple. A consultant has spent his or her career solving all different types of problems; a long-term employee has spent theirs solving just the ones you've needed them to thus far.
Second, employees who operate in a vacuum often succumb to their own vision of how software should be built. The more brilliant the engineer - or even worse, the more aware of their own brilliance they are - the worse this problem becomes. The end result is often software that no one else can maintain. The minute employee #2 has to handle that code, their efficiency dips below 20% while they try and unravel someone else's overly clever solution.
This is an avoidable side-effect of a growing company, but it's avoided through pairing, best practices, code review, and retrospectives; you know, the stuff quality consulting firms do to ensure that every time code is delivered, another team could pick it up and know exactly how it works (this is, incidentally, also why you should employ a professional to build it right the first time instead of being a cheapskate and paying double or triple for it later).
Anyway, let's say any of the aforementioned conditions bring an employee's relative efficiency, as compared to a talented Rails consultant (who has seen, if not "it all," most of it) to 80%.
|$123 / hour 85% time utilized 80% efficiency||=||$181 / hour|
And the scary thing is, 80% efficiency may be unlikely. Suppose they've never had to deal with media encoding issues and rendering that media in a browser. When you've never seen these issues before, it's going to take you a whole day or two to figure out what the problem is and another day or two to solve it.
A seasoned consultant, on the other hand, might immediately wire you up to Amazon Elastic Transcoder and go about their day. It's almost as if they were paid an absurd amount of money to know how to do that the right way the first time.
Fallacy the Last: "Employees allow me to take advantage of market opportunities"
This is true and it isn't true. If you don't have a development team hired right now, obviously it's not. If you decide to hire a team today, for the sake of argument, let's say it takes you, what, 2 months to find a lead developer who can really run your project?
(By the by, if you think it actually takes a puny two months to find a team-lead quality Rails developer, you are, again, living in Dreamtopia. Is the weather nice there? I'll bet it's delightful.)
Anyway, let's also say you're doing this because your customers have been asking for a feature. And meanwhile, some seventeen year old in Russia noticed the same hole in the market you have, and over two weekends starts to take potential business away from you.
Don't worry. You're only six weeks out from having a team hired that can then brainstorm the way to build the features you're looking for.
How many customers did you lose in that time?
One more assumption: let's say your customer lifetime value is $1,234, because why not, it's a fun number. Let's say this Killer Feature is a major concern for 10% of your potential customers, especially since someone else started offering it. Finally, let's say your sales cycle lets you hit about 50 conversions a month. Over the two months you spend looking for a developer, the un-discounted market value of that feature is:
|10% × 100 × $1,234||=||$12,340|
That's a Mazda right there, son. And you can't buy it because you're still looking for a lead developer.
On the other hand, if you already have a team in place but need more bandwidth, consultants add the same value they always have: they're an instant-on, scalable resource. You can add a consultant tomorrow for $150/hour and a two-week engagement. Or you can wait a month or two to find and hire a new employee, keep them busy for those two weeks of work (assuming the opportunity hasn't passed), and then deal with the excess capacity until you've got more work for them.
Fixed vs. Variable Cost Models, The End
Ultimately, what I'm talking about here is the difference between a fixed and variable cost model. It's the difference between paying a factory to sew your shoes together and owning the factory.
Do you have a multi-year project and the ability to provide constant project oversight? Then it's probably time for an employee. If you're a startup, it may also be time to re-evaluate your business model, but that's another story.
Do you need a few mission-critical features implemented from time-to-time? Then you're looking for a consultant, who has assumed all of the risks of a large asset (a talented developer), and lowered your own risk ("can't afford to pay a developer anymore? Don't ask the consultant for new features.")
So a responsible consultant becomes a variable cost that you can expect and plan for with every feature you add to a product; an employee is a fixed cost that, assuming you achieve maximum capacity utilization and efficiency, can pay higher dividends over time.
Ah, but they probably won't. This is a whole blog post of its own, but the missing link between every entrepreneur and development team is project management. Without it, you're not going to maximize your returns, and if you actually manage to maximize your returns, your developers are going to quit because you're treating them like factories and not people, which takes us back to ... opportunity costs. Cause now you gotta hire someone else.
And that's the true advantage of a consulting firm: we know how to keep good developers happy (hint: they like new challenges, NOT repeating the same solutions), and we know how to manage your project to ensure they can achieve optimal efficiency, without spending time in meetings or charging you for their internet learning hours. That's what project managers and open source Fridays are for, and that burden is on the consultant (assuming they don't suck).
Look, ultimately I'm not saying you shouldn't hire an employee to help build your product; I'm saying there's a great big grey area and you'll have to feel it out yourself.
Whatever the case, this notion that "we can't afford a consultant because employees are cheaper" just isn't so cut-and-dry.