My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, health care this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.
I own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.
Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.
As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”
Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.
Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?
If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.
If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.
That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair to the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.
The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.
There’s got to be a better way.
