I’m a little perplexed that salary is an afterthought here–in a field where what we do is so directly tied to outsized profits, it’s weird we aren’t pushing harder to get a cut of the pie.
I unholstered my sarcasm gun, paused to think about it, and put it away again. I fully agree with you. I recently read this book which touches on the matter. I love the stability of being an employee and I hate dealing with clients for a reason or another. I also hate very many things about corporate life, and I wanna break out of that at some point, although it ain’t possible nor practical right now. Anyway I digress, it was a good read.
A good example of this is the amount of people unhappy at work, asking for a raison to justify their stay.
Anyway, what you seem to want is a better distribution of income in a company, no specifically higher salary, so the question would be, is income equality a factor of hapiness? Maybe.
No, I specifically want a better cut of the value that I produce.
If I grow sales by 5x by implementing a feature, there are some options, right?
Others who failed to grow sales are penalized
Others who failed to grow sales are penalized and their rewards given to me instead
Everybody gets a cut of the sales, even Frank the sales guy who sucks and Ann the janitor who does the same amount of work day in and day out cleaning toilets
I get no compensation (compared to base case of not succeeding)
I get compensated by small bonus
I get a percent of the sales increase
Only two of those aren’t terrible. Only one of them is fair.
If you want to see a developer act do work that can bring in 10 million, cut them in for 5%. I can’t think of any dev who wouldn’t move heaven and earth to make 500K in a year.
Of course, the current system is more a deal of “You’re lucky to have a job here, here’s the salary, management/shareholders will skim off the profits that, by construction, they themselves could not have realized had you (or devs like you) agreed to it.”
And honestly, while I respect the problems of folks who aren’t in our industry making our wages, I also work very hard not to have those problems. I have no desire to be holding the bag when market trends correct themselves and we’re paid the same as non-devs while the people we let fleece us are fucking off in their Teslas to Moneyland.
This sounds like a great idea in principle, but how do you attribute whose work produced what value? This seems like a hard question to answer in general (i.e. not just for engineering roles), with maybe the exception of direct sales roles (where a commission based on deal size is often the norm). Even in sales roles, I think attribution is a hard question to answer: are your sales great because your salespeople are great or your application engineer is great or the intern you hired produced a ton of value by fixing a bunch of stuff that nobody had bothered to?
When I worked in adtech, we had similar difficulty trying to attribute clicks to specific ads. The honest truth seems to be that, in both ads and work, it’s hard to do attribution “fairly” when you have a high-touch process involving many people.
So, there’s a few different parts of that, but the one I’ll poke at is attribution.
A lot of sales folks work on commission: and yeah, that has pathologies, but it’s the case more often than not that a salesperson that puts in the work to seal a deal is pretty unquestionably the one that deserves a cut of the sale.
The idea that we can’t do basic accountability in engineering is something I disagree with. Some solutions:
The entire engineering team gets a cut of engineering-related success that year split evenly, if for no other reason than they failed to fuck up growth.
Individual contributors that actually lay hands on a feature and implement it get a cut of sales that touch that feature, or cost savings if it’s an efficiency improvement. If the company can’t track what features lead to sales or what features boost efficiencies, even in some rough way, I posit the company is poorly managed.
At perhaps the most asinine solution, do a trace on what functions/features get called (same as we do for code coverage!), multiply it by uses/users/revenue, and do a weighted payout to the folks that wrote the code.
At least in some fields, say e-commerce, it’s pretty obvious how to break things down. If an engineer builds the product page, builds the order logic, and builds the persistence, they’re pretty obviously the ones that deserve the credit. If one team builds, say, product search, it’s pretty easy to track what generated a sale and how the customer got there (they’re tracking the customers, right?) and give them a cut.
And one immediate objection to this is “but how do engineers that don’t do customer-facing stuff get rewarded?” And my answer to that is basically: if an engineer doesn’t directly do stuff that puts money in the hands of the business, they don’t actually generate value for the company and as such shouldn’t be rewarded a cut of the spoils. From a business standpoint, a bad engineer that ships continuously and drives sales is worth infinitely more than a great engineer that refactors in pursuit of perfection.
I’m still debating internally how hard I believe this line of reasoning, but it’s opening up some interesting tangents in my head so I don’t think it should be dismissed outright.
I disagree, a bit. A decent SRE is going to prevent an incredible amount of screwing ups that would potentially cost any given company a lot of money. In a way, their presence is a form of risk mitigation; there’s definitely value in that, but it’s less obvious. For example: At some point in my career I was asked to implement in emergency a feature that essentially mitigated a risk that, should it realize, would have cost them in the tens of millions. Once mitigated, the risk didn’t exist anymore, and I’d bet that there’s SOME value in that risk having been permanently mitigated. Probably less than tens of millions, but probably more than a pat on the back.
[edit:] I mean, it’s less obvious as opposed to “See, since I tweaked this endpoint last week sales have increased by 20k per day, where’s my cut?”
Individual contributors that actually lay hands on a feature and implement it get a cut of sales that touch that feature, or cost savings if it’s an efficiency improvement.
This might be combined with “competitive coder” schemes to get even more results if they themselves are getting the results they claim.
For instance, I have had the opportunity to help elect a president, map the human genome, and participate in building one of the first distributed filesystems that could break the CAP barrier.
To my mind, all of those were VERY good software engineer jobs, and none of them hit every bullet.
Maybe he worked on Spanner. People often describe it as high consistency and availability. Maybe it was VMS clusters on Alpha boxes at two to five sites within a few hundred miles of each other using SONET lines. I’m curious which one it was, too. ;)
I’m a little perplexed that salary is an afterthought here–in a field where what we do is so directly tied to outsized profits, it’s weird we aren’t pushing harder to get a cut of the pie.
I unholstered my sarcasm gun, paused to think about it, and put it away again. I fully agree with you. I recently read this book which touches on the matter. I love the stability of being an employee and I hate dealing with clients for a reason or another. I also hate very many things about corporate life, and I wanna break out of that at some point, although it ain’t possible nor practical right now. Anyway I digress, it was a good read.
Because a higher salary won’t make you happier.
A good example of this is the amount of people unhappy at work, asking for a raison to justify their stay.
Anyway, what you seem to want is a better distribution of income in a company, no specifically higher salary, so the question would be, is income equality a factor of hapiness? Maybe.
No, I specifically want a better cut of the value that I produce.
If I grow sales by 5x by implementing a feature, there are some options, right?
Only two of those aren’t terrible. Only one of them is fair.
If you want to see a developer act do work that can bring in 10 million, cut them in for 5%. I can’t think of any dev who wouldn’t move heaven and earth to make 500K in a year.
Of course, the current system is more a deal of “You’re lucky to have a job here, here’s the salary, management/shareholders will skim off the profits that, by construction, they themselves could not have realized had you (or devs like you) agreed to it.”
And honestly, while I respect the problems of folks who aren’t in our industry making our wages, I also work very hard not to have those problems. I have no desire to be holding the bag when market trends correct themselves and we’re paid the same as non-devs while the people we let fleece us are fucking off in their Teslas to Moneyland.
This sounds like a great idea in principle, but how do you attribute whose work produced what value? This seems like a hard question to answer in general (i.e. not just for engineering roles), with maybe the exception of direct sales roles (where a commission based on deal size is often the norm). Even in sales roles, I think attribution is a hard question to answer: are your sales great because your salespeople are great or your application engineer is great or the intern you hired produced a ton of value by fixing a bunch of stuff that nobody had bothered to?
When I worked in adtech, we had similar difficulty trying to attribute clicks to specific ads. The honest truth seems to be that, in both ads and work, it’s hard to do attribution “fairly” when you have a high-touch process involving many people.
So, there’s a few different parts of that, but the one I’ll poke at is attribution.
A lot of sales folks work on commission: and yeah, that has pathologies, but it’s the case more often than not that a salesperson that puts in the work to seal a deal is pretty unquestionably the one that deserves a cut of the sale.
The idea that we can’t do basic accountability in engineering is something I disagree with. Some solutions:
At least in some fields, say e-commerce, it’s pretty obvious how to break things down. If an engineer builds the product page, builds the order logic, and builds the persistence, they’re pretty obviously the ones that deserve the credit. If one team builds, say, product search, it’s pretty easy to track what generated a sale and how the customer got there (they’re tracking the customers, right?) and give them a cut.
And one immediate objection to this is “but how do engineers that don’t do customer-facing stuff get rewarded?” And my answer to that is basically: if an engineer doesn’t directly do stuff that puts money in the hands of the business, they don’t actually generate value for the company and as such shouldn’t be rewarded a cut of the spoils. From a business standpoint, a bad engineer that ships continuously and drives sales is worth infinitely more than a great engineer that refactors in pursuit of perfection.
I’m still debating internally how hard I believe this line of reasoning, but it’s opening up some interesting tangents in my head so I don’t think it should be dismissed outright.
I am an SRE for an online retailer (I am not, but the sake of the argument I am).
If I screw up big time, I completely halt all the sales. On the other hand, if I do decently my job, my work goes unnoticed.
So, according to your model, should I earn the entire company profit or should I earn nothing?
Well, as I wrote, you don’t drive sales or make savings, you have rated new value…you’ve acted to preserve existing value.
You should still be well compensated for your work! Just not with a cut of the growth.
I disagree, a bit. A decent SRE is going to prevent an incredible amount of screwing ups that would potentially cost any given company a lot of money. In a way, their presence is a form of risk mitigation; there’s definitely value in that, but it’s less obvious. For example: At some point in my career I was asked to implement in emergency a feature that essentially mitigated a risk that, should it realize, would have cost them in the tens of millions. Once mitigated, the risk didn’t exist anymore, and I’d bet that there’s SOME value in that risk having been permanently mitigated. Probably less than tens of millions, but probably more than a pat on the back.
[edit:] I mean, it’s less obvious as opposed to “See, since I tweaked this endpoint last week sales have increased by 20k per day, where’s my cut?”
This might be combined with “competitive coder” schemes to get even more results if they themselves are getting the results they claim.
IMO your definition is overly narrow.
For instance, I have had the opportunity to help elect a president, map the human genome, and participate in building one of the first distributed filesystems that could break the CAP barrier.
To my mind, all of those were VERY good software engineer jobs, and none of them hit every bullet.
Which distributed filesystems break the CAP barrier?
Maybe he worked on Spanner. People often describe it as high consistency and availability. Maybe it was VMS clusters on Alpha boxes at two to five sites within a few hundred miles of each other using SONET lines. I’m curious which one it was, too. ;)
Spanner is not a filesystem though.
I apparently read it too fast. My bad.