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.
Comments on this entry are closed.
The model you describe is basically a shifted fixed-price model with risks moved from an employer to developers. One could describe it as client / middleman / multiple individual contractors model. I put on my client’s hat and I wonder whether I even need a middleman. I have to pay for all their overhead which I may avoid working directly with contractors. Anyway, I see how potentially the business could be organized in a way that the middleman adds value, even though that’s not an easy task.
The big problem, however, is the assumption that the work has a stable and predictable value and a stable and predictable cost. The key problem of fixed price projects is the quality of estimates. And I would understand the last sentence very broadly. First, the client estimates how much they’re willing to pay for the work (which is may or may not be derived from the expected returns of doing the work). This is usually highly speculative number. Then, the scope is also some sort of speculation – the client speculates that software should have such and such features and should work in this or that way. Although it’s not exactly estimation it faces the same key issue: dealing with the unknown.
Before we switch to the vendor there is another huge iceberg on the way which is communication issue. I’m yet to see the specs that describe what’s to be done precisely and in a manner that leaves no place for interpretation. This means that understanding of work scope on both ends of communication channel is different. In other words the client estimates something different than the vendor.
And then there is an old peeve of mine, which is estimating software basing on specs. Humans are infamous for being crappy estimators. Not only are we way too optimistic in terms of how much the work is going to take but we also ignore how little productive time we invest in building things. This is basically why vast majority of fixed price projects is underestimated. They are, despite the fact that organizations selling these projects usually add heavy padding.
I’m afraid that expectations that developers individually would make better estimates is flawed. Some of them would, but those guys would rarely, if ever, win any work as there would always be very wide range of available options, vast majority of them looking way more attractive for the client.
I don’t even want to think how the discussions about delivered value would look like.
Given that the model that shifts estimation responsibility to individuals would be put in work, I doubt that most efficient or hardest-working people would be winners. It’s not the economic that has stable variation of effort to value ratio. You can build an app that randomly changes square photos and sell it or a billion dollars. You can have weird app that forces you to limit your messages to 140 char, which also fails very frequently, and end up having hundreds millions of users… As the same time you can build great, high-quality and valuable product that fails miserably because of e.g. poor marketing.
To summarize it somehow: a middleman (an employer) makes sense as it works as some sort of insurance company. It guarantees, to some point, a steady flow of cash for employees and it guarantees that expected value (software) will be delivered to the client according to agreed set of rules, e.g. the vendor won’t simply walk away because he’s just found a better gig.
Have you ever heard about EVO methodology by Tom Gilb?
It is agile-lean-like methodology, that responds very well to this problem. It allows to create contracts based on qualities to be achieve.
It’s been a decade since I’ve looked at Evo. I’ll revisit the methodology after I’ve finished with my upcoming Kanban workshop and ACE! Conference.