10 ms·

An alternative to hiring and paying employees – the Qbix Compensation Model

26 points by EGreg 5y ago

awb 5y ago
So, basically it’s a commission tied to increased revenue. The problem IMO is that revenue is tied to things outside a developer’s control like advertising. If your benchmark week had a big ad push or a public event, then you’re going to underperform no matter how good your feature is. It’s like they’re assuming that they can isolate everything but this single feature and tie that directly to revenue, but that’s just not realistic. Maybe realistic enough for some, but I wouldn’t take that risk with my time.
a3n 5y ago
So, piecework, and you're paid for your risk if the company likes it according to some metric, and constrained by how well the company is able to monetize the work. Since health insurance is tied to employment for most people in the states, it's hard to see the downside. For the company. Aside: I can imagine specific people from my past selling this model. It's slightly nauseating when I cast it that way.
- eropple 5y ago
  Yeah, for real--this feels like the sort of idea I'd hear hauled out by some of the most disreputable people I've run into in this industry. This is wishful and short-sighted project management with an exploitative cost structure for anybody you could sucker into it. I am uncomfortable reading it.
  - danpalmer 5y ago
    It's the sort of thing I hear from people who have never built something, worked in a job for more than a few months, or worked as part of a team. These people still think they have some amazing idea to contribute, that they're being "disruptive", but anyone with literally any experience can see right through it.
ungawatkt 5y ago
My immediate feeling is this could skip all of the metric parts and lean more into "I will give you X% of revenue for Y amount of time" and get much the same effect of providing motivation for outside devs contributing one-off work. The metrics approach only using revenue as a goal can only capture some parts of project work. A DB upgrade or new load balancer doesn't get you new signups, but it can critical to handling the next few thousand users.
woleium 5y ago
I'd hate to be the one writing / negotiating that contract. What happens if the company pulls the feature? What if the code introduces a vulnerability that leaks data? How much of the pie does the code reviewer get when he finds that bug?
srfvtgb 5y ago
Even if it were possible to accurately attribute revenue to particular contributions, I could see this compensation model leading to short term thinking. For example a contribution may generate a lot of revenue now, but could end up costing more when a security hole causes you to lose all your customers data. And who will fix bugs that don't directly contribute to revenue? Or work on behind the scenes code which isn't directly monetizable? Maybe this could work as a factor in a bonus that is a small portion of total compensation, but as a driver of total compensation there are far too many issues.
- EGreg 5y ago
  Well this model assumes all the other mechanisms of the company are still in place. Including quality control and so forth. People intentionally writing bad spaghetti code or bugs will have to fix it before going live. Companies do beta tests with a small sample all the time. We just measure revenue increases and share them with the person who is responsible :)
lostcolony 5y ago
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.
- light_hue_1 5y ago
  It's so much worse than 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. 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.
babesh 5y ago
People should look at their graph of the times that their app is used. It is decelerating. That would mean that a no-op would actually be measured as having negative value according to the formula provided if measured in the medium term. A minor improvement would benefit them and would result in no benefit to you. In fact, many apps actually decay when people don’t regularly improve them. Without the next developer, your ongoing compensation will soon fall to zero. They need a better formula at the very least. They also need protections for the developer against copying the feature. If it is cheaper to do so, they can just hire developers to duplicate the feature and then toss your implementation.
altacc 5y ago
This sounds impractical and also skews development focus to features of a product that relate to short term revenue gains, not necessarily long term & customer focused improvements. For example, I think SaaS products & subscriptions should have good cancellation processes, which are the opposite of revenue generating. Someone working on the cancellation process with an eye on revenue generation is going to dig deep into the bucket of customer hostile anti-patterns, and nobody should be paid for that work. They might have a better answer to this than the short term & limited analysis they describe in the article, but I think it is typically very hard to link individual features to revenue and not all beneficial features will be revenue generating. It is rare for SaaS or application pricing models to be per feature (e.g. pay $5/month more for this single feature). So, considering that there are a lot of other factors affecting revenue, how do they isolate the effects of a single feature? My guess is that even with public metrics, the company does, so the developer is depending upon a fair assessment. I also wonder if they measure this new feature's effect on customer retention, which isn't an obvious short term increase. I can think of many examples of features I've introduced in the past that didn't directly increase short term revenue but did improve the customer experience, which is key for customer retention for our annual payment models.
polyterative 5y ago
this looks really bad
database_lost 5y ago
"... and actually drives everyone to compete in how much they can contribute" - because this is what we all need, competing everyday for making someone else more money. Also, this model seems to work reallly well for you: none of the top navigation buttons on your site work for me (using Chrome beta)
- EGreg 5y ago
  This is an entirely voluntary option. Someone like patio11 advocates it all the time. (It was partly inspired by his writings.) It was supposed to address the arbitrage that the middlemen take when they rent out your skills to effect real change, while they stick you in a “steady” paycheck situation and give you bundled health insurance. You want to be underpaid in a full time job and pretend to work 8 hours a day, while your time is billed out at 3x by a consulting company? Have at it. Or you can think about how much value you are bringing to the business and get a cut of that value. No one at Qbix is FORCED to accept such an arrangement. However, people have chosen to do it voluntarily, and it is a way to be properly compensated fairly for just how much you helped grow the software company’s bottom line. 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. PS: Those aren’t buttons, they are menus, you’re supposed to use the dropdown.
  - database_lost 5y ago
    "compensated fairly for just how much you helped grow the software company’s bottom line" - as others have said: what do you do with all the stuff below the waterline, that DON'T grow the bottom line? Bugfixing, reliability, privacy, security, etc. PS: Thanks, knew that, the dropdown buttons didn't work. And they still don't.
    - 5y ago
vkou 5y ago
If I'd be paid like this, I'd do the equivalent of taking all of your money, flying to Vegas, and putting it on red. Heads, I win, tails, you lose.
anonymoushn 5y ago
So if two developers both increase revenue by the same factor, and the changes are independent, their compensation should be determined by which order they ship in, with the one who ships later being paid more?
- HWR_14 5y ago
  It's always better to be the second developer, often by quite a margin. The second developer's compensation is multiplied by the revenue factor of the first developer's growth.
  - deleted 5y ago
    [deleted]
anm89 5y ago
I feel bad for anyone who works under these conditions. I'd imagine you'd never get paid at all. You are setting yourself up to just have the requirements lawyered and they'd argue that you didn't hit your metric due to some technicality and therefor are entitled to nothing.
_448 5y ago
The intentions are good. But the implication could be otherwise. Because it takes a very simplistic view of what affects a company's bottomline!

26 points by EGreg 5y ago

awb 5y ago

So, basically it’s a commission tied to increased revenue. The problem IMO is that revenue is tied to things outside a developer’s control like advertising. If your benchmark week had a big ad push or a public event, then you’re going to underperform no matter how good your feature is. It’s like they’re assuming that they can isolate everything but this single feature and tie that directly to revenue, but that’s just not realistic. Maybe realistic enough for some, but I wouldn’t take that risk with my time.

a3n 5y ago

So, piecework, and you're paid for your risk if the company likes it according to some metric, and constrained by how well the company is able to monetize the work. Since health insurance is tied to employment for most people in the states, it's hard to see the downside. For the company. Aside: I can imagine specific people from my past selling this model. It's slightly nauseating when I cast it that way.

eropple 5y ago
Yeah, for real--this feels like the sort of idea I'd hear hauled out by some of the most disreputable people I've run into in this industry. This is wishful and short-sighted project management with an exploitative cost structure for anybody you could sucker into it. I am uncomfortable reading it.
- danpalmer 5y ago
  It's the sort of thing I hear from people who have never built something, worked in a job for more than a few months, or worked as part of a team. These people still think they have some amazing idea to contribute, that they're being "disruptive", but anyone with literally any experience can see right through it.

ungawatkt 5y ago

My immediate feeling is this could skip all of the metric parts and lean more into "I will give you X% of revenue for Y amount of time" and get much the same effect of providing motivation for outside devs contributing one-off work. The metrics approach only using revenue as a goal can only capture some parts of project work. A DB upgrade or new load balancer doesn't get you new signups, but it can critical to handling the next few thousand users.

woleium 5y ago

I'd hate to be the one writing / negotiating that contract. What happens if the company pulls the feature? What if the code introduces a vulnerability that leaks data? How much of the pie does the code reviewer get when he finds that bug?

srfvtgb 5y ago

Even if it were possible to accurately attribute revenue to particular contributions, I could see this compensation model leading to short term thinking. For example a contribution may generate a lot of revenue now, but could end up costing more when a security hole causes you to lose all your customers data. And who will fix bugs that don't directly contribute to revenue? Or work on behind the scenes code which isn't directly monetizable? Maybe this could work as a factor in a bonus that is a small portion of total compensation, but as a driver of total compensation there are far too many issues.

EGreg 5y ago
Well this model assumes all the other mechanisms of the company are still in place. Including quality control and so forth. People intentionally writing bad spaghetti code or bugs will have to fix it before going live. Companies do beta tests with a small sample all the time. We just measure revenue increases and share them with the person who is responsible :)

lostcolony 5y ago

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.

light_hue_1 5y ago
It's so much worse than 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. 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.

babesh 5y ago

People should look at their graph of the times that their app is used. It is decelerating. That would mean that a no-op would actually be measured as having negative value according to the formula provided if measured in the medium term. A minor improvement would benefit them and would result in no benefit to you. In fact, many apps actually decay when people don’t regularly improve them. Without the next developer, your ongoing compensation will soon fall to zero. They need a better formula at the very least. They also need protections for the developer against copying the feature. If it is cheaper to do so, they can just hire developers to duplicate the feature and then toss your implementation.

altacc 5y ago

This sounds impractical and also skews development focus to features of a product that relate to short term revenue gains, not necessarily long term & customer focused improvements. For example, I think SaaS products & subscriptions should have good cancellation processes, which are the opposite of revenue generating. Someone working on the cancellation process with an eye on revenue generation is going to dig deep into the bucket of customer hostile anti-patterns, and nobody should be paid for that work. They might have a better answer to this than the short term & limited analysis they describe in the article, but I think it is typically very hard to link individual features to revenue and not all beneficial features will be revenue generating. It is rare for SaaS or application pricing models to be per feature (e.g. pay $5/month more for this single feature). So, considering that there are a lot of other factors affecting revenue, how do they isolate the effects of a single feature? My guess is that even with public metrics, the company does, so the developer is depending upon a fair assessment. I also wonder if they measure this new feature's effect on customer retention, which isn't an obvious short term increase. I can think of many examples of features I've introduced in the past that didn't directly increase short term revenue but did improve the customer experience, which is key for customer retention for our annual payment models.

polyterative 5y ago

this looks really bad

database_lost 5y ago

"... and actually drives everyone to compete in how much they can contribute" - because this is what we all need, competing everyday for making someone else more money. Also, this model seems to work reallly well for you: none of the top navigation buttons on your site work for me (using Chrome beta)

EGreg 5y ago
This is an entirely voluntary option. Someone like patio11 advocates it all the time. (It was partly inspired by his writings.) It was supposed to address the arbitrage that the middlemen take when they rent out your skills to effect real change, while they stick you in a “steady” paycheck situation and give you bundled health insurance. You want to be underpaid in a full time job and pretend to work 8 hours a day, while your time is billed out at 3x by a consulting company? Have at it. Or you can think about how much value you are bringing to the business and get a cut of that value. No one at Qbix is FORCED to accept such an arrangement. However, people have chosen to do it voluntarily, and it is a way to be properly compensated fairly for just how much you helped grow the software company’s bottom line. 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. PS: Those aren’t buttons, they are menus, you’re supposed to use the dropdown.
- database_lost 5y ago
  "compensated fairly for just how much you helped grow the software company’s bottom line" - as others have said: what do you do with all the stuff below the waterline, that DON'T grow the bottom line? Bugfixing, reliability, privacy, security, etc. PS: Thanks, knew that, the dropdown buttons didn't work. And they still don't.
  - 5y ago

vkou 5y ago

If I'd be paid like this, I'd do the equivalent of taking all of your money, flying to Vegas, and putting it on red. Heads, I win, tails, you lose.

anonymoushn 5y ago

So if two developers both increase revenue by the same factor, and the changes are independent, their compensation should be determined by which order they ship in, with the one who ships later being paid more?

HWR_14 5y ago
It's always better to be the second developer, often by quite a margin. The second developer's compensation is multiplied by the revenue factor of the first developer's growth.
- deleted 5y ago
  [deleted]

anm89 5y ago

I feel bad for anyone who works under these conditions. I'd imagine you'd never get paid at all. You are setting yourself up to just have the requirements lawyered and they'd argue that you didn't hit your metric due to some technicality and therefor are entitled to nothing.

_448 5y ago

The intentions are good. But the implication could be otherwise. Because it takes a very simplistic view of what affects a company's bottomline!