So, we know that at very low costs, you may get someone who is just utterly useless for your purposes. They may not be forever broken -- maybe they're just a smart but inexperienced graduate. We all were once. But while they're at that stage of learning, they are barely worth the paper you wipe their noses with.
But the good thing is, they improve quickly. Start spending more and you get a little bit of improvement. Spend more and the increase gets even bigger. Something like this:
Now it doesn't really matter what measure we're using for "goodness". It's just some overall measure of "rate of effective output". I say "effective" because we all know that something as crude as, for example, "lines of code" is rarely, on its own, a useful measure in software.
The next thing to notice though is that while effectiveness versus hourly rate is superlinear at low hourly rates, it becomes sublinear at higher rates. Like this:
The curve shown is a sigmoid. It has the general form:
y = 1/(1 - e-x)
Now I'm not claiming that cost/performance of engineers exactly matches that function, but it is roughly in line with experience. For any given problem, while it's possible to spend too little per hour on a programmer, it's also possible to spend too much. If all you want some mid-range Perl to drive a website, your probably don't want a complete beginner no matter how cheap, but nor do you need Larry Wall, nor Larry's hourly rate.
But notice that "for any given problem". That brings us to the third point about effectiveness and rate. Exactly where on the actual hourly cost and actual hourly contribution axes our curve sits depends on the kind of programming or engineering (or legal or accounting) problem at hand. So really we have a family of such curves, each one representing a given level of difficulty of work. It could look a bit like this:
Now this is where it starts to get interesting. The key point in all this is seen when we look not at the cost per hour of the programmer, but at the total cost for the whole project. Except for situations of troubled cash flow, the hourly rate is not important. It is total cost that matters. And even if cash flow is an issue, forcing the project to use cheaper-by-the-hour resources, it is still useful to know to what extent that choice affects the final total cost.
The graph below shows just this. It is the reciprocal of the sigmoid, with the hourly rate axes based on real rates and the Y axis, showing normalized total cost. The actual numbers are irrelevant; what is key is the shapes of those curves.
The crucial point to notice is that the low point on each curve does not correspond to the lowest hourly rate. Because of the underlying "S curve" of the sigmoid, showing increasing "returns" at the low end of hourly rate, and diminishing returns at the high end, there is a sweet spot of hourly rate. Go above that, and you are over-engineering your labor and spending too much. But go below it and just as surely you are going to spend more than you need to.
The trick then -- and this should be a central part of the discovery process in selling technical professional services -- is to delve deep enough into the project to decide on two simple things:
- Decide how tough is the proposed work. This lets the client and you, together, identify which of the family of "Optimal Hourly Rate" curves applies to their project
- Decide if your firm has resources to offer at the low point on their curve
If in doing that you find that the optimal resource is at a cost far below where you operate, you should be telling your client that you are not the right solution. Similarly, if you do decide that you are in the sweet spot and they still insist on going to someone cheaper then, provided you have built sufficient rapport in your relationship with your client, you are only doing them a service to explain that if they do they will most likely end up spending more overall.
One final point. Notice the asymmetry in the final curves. Total cost increases more quickly as you go down in rate, away from the sweet spot, than it does when you go up in rate away from it. But buying cheap is worse even than that. One of the biggest dangers for a project is being late to the market. Even if it still makes it in time for some profit, the damage from missing the core of the market window can be devastating. Labor that is too cheap not only costs more, but it takes a lot longer in time to complete the job. So if you have to err, it makes sense to err on the higher side of rate and capability, than on the cheapside.