3 ms·
There are many ways to do this, and most lead to some dark incentive nightmares. -If a dev get a percent of total company revenue, then you really don't want t
by hibikir 3y ago
There are many ways to do this, and most lead to some dark incentive nightmares.
-If a dev get a percent of total company revenue, then you really don't want to hire many!
-If you have a basket of revenue for developers, and then they split it based on whether they worked there for the last X years, then it's the devs that don't want other people hired: The pie shrinks
- If it's by code getting executed and how much revenue that brought, then the difference in value of which team to work in becomes amazing. It's also a great idea to rewrite other people's code: This inner loop of the main revenue generating code is a goldmine. GDPR compliance? worth little
- If instead of by execution or LOC we go by system contribution, we instead get yearly rewrites or very long tenures, as people protect the systems they worked in.
Either way you slice it, the good of the company is only of tangential value, as barring a growing startup, optimizing your slice of the pie becomes far more relevant than helping the company's goal, any more than just remaining employed, and therefore capable of protecting your contribution level. It would need massive changes to the way we work to avoid massive profiteering dysfunction. The culture of software would be so different as to be borderline unrecognizable. Not unlike what would happen to plumbing if they could charge per gallon that flows through the pipe, or times a toilet is flushed.