What a terrible idea. I mean, heck, who is even measuring revenue here? Certainly, their work to measure it isn't increasing revenue, so I guess they're just donating their time.
Likewise, we certainly don't need a security team; there's no way to measure their impact on revenue just over two weeks. And DevOps? Forget about it; despite all the work they do it doesn't have any measurable effect on revenue (since even a measurable speed up in time to market doesn't allow you to A/B test the impact on revenue in a measurable way).
I think this is intended to be just a bonus (though I didn't see where it was clearly called out as such) or in lieu of contract work. At least, I hope so. But as written it's farcical. It also is written with a "hypothetical" tone of voice; they imply they're doing it but don't actually demonstrate any results or measurable impact (let alone how they address the obvious shortcomings). Maybe they just mean "feature developers", but then that's just trying to tie bonuses (hopefully not base comp) to things those developers don't control.
I think something along these lines might be viable, where increases in revenue lead to increases in compensation in a direct and measurable way (i.e., revenue doubled with no additional headcount; everyone's comp doubles; rather than indirectly via RSUs, which isn't really tied to profitability but instead market perception), but as written this is so obviously untenable for any mature company, and isn't even a case study of trying it.
If someone else can come around and "claw back" my money, I want to make my contributions as impossible to build on, to change, and to understand as I can make them. This will lead to intentionally-horrific code.
It also makes no sense practically. You can only A/B test so many alternatives at the same time. This is a huge problem even at the scale of Google and Amazon who have a lot of infrastructure to run overlapping A/B tests.
How is a feature that makes $1000/week going to run even 10 concurrent A/B tests?
There is also zero accountability. The company wants to make profit and pay you as little as possible. You have no way of knowing if any improvements came from you or from someone else.
Is giving your source code to random people that don't give a damn about your company a good idea? I bet you can make more money selling zero days for many products than you can make by improving them.
This is just the beginning, the list of problems with this model is just endless for everyone.
I meant to write a lengthy answer here, but this one hits the nail on the head.
Companies take the full risk for starting projects and hiring people: especially those just very indirectly relevant to the bottom line. For that, they get the full reward of taking this kind of risk. That's the nature of business and entrepreneurship.
Smart employers recognize value created by employees — direct as well as indirect — and give these employees a share of success. Sometimes in salary, sometimes in stock.
And I said smart because in the long run, there's nothing cheaper than keeping insanely productive employees around by issuing some company stock, promoting them and keeping them happy and productive in any other way possible.
Trying to keep tally on a cent-by-cent base doesn't just create a massive bureaucracy (I've seen one full-time person just doing the compensation plans for the sales team), it also opens up a massive field of bickering around details that could have gone into the product.
If it makes you feel better, imagine if the worker started their own startup and then approached us with a business proposition. How would we fairly pay that startup, versus exploiting them?
“Wrap” the person in a startup since you feel that only companies should be entrepreneurial. I don’t mind. Then let’s look at the QCM again.
This is exactly about attracting the most productive people and giving them a share of the company’s revenues. If you want to do it via stock grants - sure, pay the QCM out in that!
> If someone else can come around and "claw back" my money, I want to make my contributions as impossible to build on, to change, and to understand as I can make them.
In theory, the "claw back" is decreasing your percentage while increasing the total pie such that your slice remains the same, or otherwise grows or shrinks exactly as much as it would all have without the "claw back". The theory makes sense if the measurements over a 2-4 week period are completely accurate and hold true over the entire lifespan of the product.
(Edit: Reading again, it seems likely that you are paid a fixed sum each week, not a percentage. Therefore the "claw back" is only referring to the psychological feeling of ownership)
> There is also zero accountability. The company wants to make profit and pay you as little as possible. You have no way of knowing if any improvements came from you or from someone else.
The article author calls out that as an issue, and gets over it by assuming everyone trusts his published metrics. Explicitly calls it out as an assumption that the metrics are trusted to make the system work.
Thank you. Look, all this is voluntary. We live in a capitalist system where businesses amass capital and take risks with that capital. The owners of the business “centrally plan” what will happen.
The goal of this to try a free-market approach to get closer to employee-owned companies. Ideas can be suggested by anyone. They can be even given a budget to go do it. If they succeed, they get a share of the revenues.
Many of us are so “whipped” by full-time employment that we commute long hours to work, neglect our kids and do what the boss says or get fired. QCM is closer to Adam Smith’s ideal of everyone being a free agent. Read this and tell me why no one should ever voluntarily agree to it:
Imagine, as a developer or designer, coming across a SaaS company whose product you are very familiar with, that openly publishes its metrics. They honestly reveal that some metrics could use improvement, and you have a great idea for how to do it. You get in touch and – instead of hiring you to for some full-time position doing mostly drudge work inside the company – they agree to pay you for your contribution, if it works out. $1,000,000 / year x (C–1) for every factor C that you improve a certain KPI metric.
Since I have written this, I have found that paying people in cryptocurrencies for their time may be a better way when it comes to time-based compensation. But for results-based compensation, I have found that this works quite well, and is closer to the ideal of “to each according to their contribution”. Just because I started a for-profit company doesn’t mean I have to take all the risk and reap all the reward and compensate employees at my whim. That’s how salaries stagnate.
Certainly, this isn’t for everyone. It attracts a certain type of person: independent, results-driven, and turned off by the bullshit in full time employment. There are plenty of people who contribute to open source and wikipedia and science FOR FREE. This is for compensating those kinds of people.
PS: in a society I wish we’d move towards, everyone gets enough UBI and health insurance indeendent of working for any corporation that they would voluntarily choose to learn guitar or contribute to a company’s bottom line. Then software and digital projects would have far more contributions from free people around the planet. Until then, many people have to keep their head down and conform to get that steady paycheck, and risktaking like this is apparently … derided! … even on a site which is hosted by an accelerator for entrepreneurs. I truly feel we are living in Plato’s cave here. (But then again, I remember HN’s traditional snarky character towards anything unorthodox and realize people may not actually be so against free humans choosing to have their contributions measured by a consistent system that attempts to be fair.)
They can “claw back” the percentage they give you by growing revenues. You lose nothing in absolute terms.
It simply means whoever triples revenues after you reduces your percentage by 3, so you didn’t contribute to the 3x and it’s a complete wash for you, the payments you get neither go up or down. As it should be.
As described this scheme seems unrealistic. But it has good ideas in it.
The clawing back just means the developers inside and outside the company compete to increase its bottom line even more. Your own revenues don’t go down, if everyone succeeds. They increase. Why would you sabotage others?
Furthermore! They can claw back the percentage by releasing code in a completely unrelated part of the system. Or perhaps improving the sales process or other things.
Unfortunately the title has been editorialised because my first red flag was 'an alternative to hiring and paying employees'. That language isn't used inside the post.
It's not far off the mark though - the 'model' asks you to contribute work up-front and then sets up a few conditions you have to meet if you expect to see any compensation for the work. One of these conditions is actually launching it into prod and measuring it for a month, after spending a few weeks beta testing it. Any contributor is looking at a multiple-month project where the cost of the project is not contractually set in stone, and where they earn nothing while the business cooks up some metrics to avoid paying out.
And let's be honest, no business using this model is going to pay a contributor $10k a week using this calculation, potentially for 5 years, when a full time hire would cost them less.
The model is a scam. The only thing missing is that it doesn't ask you to rope in other people to help contribute for you, to passively earn up to half-a-million bucks a year.
> Certainly, their work to measure it isn't increasing revenue, so I guess they're just donating their time
Well, that's why they keep 90% of the increase they measure, and only pay out 10% of it. Presumably that 90% covers security, business and other functions.
> I think this is intended to be just a bonus
I think it's intended to get some of the benefits of open-source collaboration (you write the feature you want) with a formula to compensate contributors. Of course, they are limiting themselves exclusively to revenue generating features, which is a particularly Econ 101 way of valuing contributions.
They are quite clear that these people have no base contribution or other connection to the company.
It is not for dev ops nor the security team. It is for people who freely choose to share the risks and the rewards of their contributions. They approach a company that has already done the work of getting a userbase, goodwill etc. improve its bottom line by X, and get the proportional compensation. That’s how patio11 advocates selling your services. This is just the company making it as easy as possible for folks like patio11 to come and do their thing!
Likewise, we certainly don't need a security team; there's no way to measure their impact on revenue just over two weeks. And DevOps? Forget about it; despite all the work they do it doesn't have any measurable effect on revenue (since even a measurable speed up in time to market doesn't allow you to A/B test the impact on revenue in a measurable way).
I think this is intended to be just a bonus (though I didn't see where it was clearly called out as such) or in lieu of contract work. At least, I hope so. But as written it's farcical. It also is written with a "hypothetical" tone of voice; they imply they're doing it but don't actually demonstrate any results or measurable impact (let alone how they address the obvious shortcomings). Maybe they just mean "feature developers", but then that's just trying to tie bonuses (hopefully not base comp) to things those developers don't control.
I think something along these lines might be viable, where increases in revenue lead to increases in compensation in a direct and measurable way (i.e., revenue doubled with no additional headcount; everyone's comp doubles; rather than indirectly via RSUs, which isn't really tied to profitability but instead market perception), but as written this is so obviously untenable for any mature company, and isn't even a case study of trying it.