Ben Scofield

Ben Scofield

… rarely updated

22 Apr 2013

On fairness and developer salaries

I’m taking advantage of being funemployed by taking a few online courses, including Dan Ariely’s A Beginner’s Guide to Irrational Behavior at Coursera. I’m very familiar with Ariely’s work (I’ve read each of his books and cited various pieces of his research in my talk at SXSW a few years ago), but I’ve been pleasantly surprised as each week has taught me something new.

Case in point: fairness, specifically as it relates to salaries. It’s rare to see developers paid in multiples – even if the 10x developer is a myth, it’s certainly true that some devs are several times more valuable to a company than others. Even in those cases, however, it’s exceedingly rare to see salaries that vary by the same magnitude as the value the worker brings.

As it turns out, research implies that “fairness” as a concept depends more on effort than on results. Imagine how much you’d be willing to pay two people to accomplish the same task (say, fixing your car). The first person takes eight hours and is clearly struggling the whole time, while the second person barely breaks a sweat and fixes it in fifteen minutes. Most people are inclined to pay the first person more, despite the fact that the outcomes are the same – and that the second person imposed much less of an opportunity cost on you (since you’ll have seven and a half hours to drive around in your car that would’ve been lost in the first scenario).

So there’s the problem: concerns of fairness predispose us against paying people according to their actual value, instead moving us towards paying based on the effort they exert. Thus, we probably overpay inexperienced developers (who have to exert more effort to produce a given amount of value) and massively underpay our best developers (who create much more value more easily).

Note that hourly consulting rates codify this intuition – if a task takes longer, you pay more – and that’s only partially offset by different rates. Flat fees for a project (based on the projected value the project will bring) are the clear alternative, but there are known issues with those as well.