4 ms·

This is simple - pay people by the value they bring to the company upon every annual compensation review. Yes, it costs money to train people. Consequently th

This is simple - pay people by the value they bring to the company upon every annual compensation review. Yes, it costs money to train people. Consequently they get paid less during that period. But once they can fly on their own, treat them as if you hired them like that.

vetinari 8y ago
> Consequently they get paid less during that period. But once they can fly on their own, treat them as if you hired them like that. That's too early. You made an investment, that investment has to break even. With your suggestion, it would never break even.
- teddyh 8y ago
  But that’s not the trick. The trick should be that you train your employees how to do your business, and then you pay them more than what they’re worth to someone else. Since you’ve trained them in the ways of your business, they’re worth more than that, but only to you, and that’s the trick. Nobody else could squeeze as much value out of these people as you could (since the training is specific to what your business does), so you can afford to keep them, and the people have no monetary reason to leave.
  - scarface74 8y ago
    I never thought about this, but this definitely seemed to be the original thinking at one company I worked for. As far as I know, the company was started in 2003. The founder wrote a custom IDE, VM and compiler. This was the only company that used it. He hired a bunch of people from a well known but not well regarded private for profit college and paid them below market rates. Of course developers on this proprietary platform were completely useless anywhere else. By the time I came aboard in 2008 and the rest of the “adult supervision” - a new CTO and developers - they were in the process of transitioning to C#. Once the bottom fell out of the market with the 2008 recession, they laid off most of the developers working on the proprietary stuff who hadn’t learned C# on their own. They also forced the founder out. They kept me around because I was the only person who both knew C# and knew enough C++/MFC to maintain the old system.
    - teddyh 8y ago
      Yes, when digging a moat you have to be careful that it does not drown you as well.
- cableshaft 8y ago
  If they keep leaving because you won't pay them what they can get elsewhere, you won't ever break even that way either.
- brandall10 8y ago
  With all due respect, if hiring an entry level dev is a loss for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level. You pay them market when they need to be trained, you pay them market when they move up the skill food chain.
  - vetinari 8y ago
    He is a loss in short term. He is supposed to be a net gain in long term. If he leaves prematurely, the loss is realized and the gain never happens. If he stays for long enough time, he is a net gain.
    - brandall10 8y ago
      Again, if an entry level dev is a loss then don't hire entry level devs; your company does not adequately utilize them.
      - vetinari 8y ago
        Not every company is using popular, widely available tech, that folks can learn in their spare time. In this regard, unfortunately, we are using a proprietary platform and there is no chance to learn anything until you have access to the bits and docs. Due to that, fresh hires are completely useless to be utilized in any way, until they learn at least basics.
        brandall10 8y ago
        You're conflating ramp up time of business domain knowledge with skill level. Yes, a sr. dev will come up quicker than an entry because they have the wisdom and experience of past companies, but all devs need some sort of ramp up in an environment like that. You don't hold back pay from your sr. staff until they've ramped up, right? Of course not, they would take a better offer elsewhere. As would your entry levels that have now risen to mid-levels once they get the chance. But all the same, any company should be able to make any dev useful from pretty much the very beginning. Whether it's rote refactoring work, research tasks that are too time consuming for more sr. folks, tasks that are in the domain of data entry that can be automated with simple scripts, low-hanging fruit bugs, etc. It's a failure of the org not to properly utilize the abilities of a smart person who knows how to program.
bosie 8y ago
> pay people by the value they bring to the company upon every annual compensation review. how do you determine the value they bring to the company? Presumably it must be a % of the revenue or valuation growth but I cannot come up how you derive the value.
- brandall10 8y ago
  How do you determine the value of any candidate you interview? You have a job req. Do they match that req? Yes, good, you make them an offer. What level of pay do you negotiate? What is market. If they're otherwise happy going toward the bottom of market is feasible, esp. if it's a large bump. If this person goes out the door, you're going to be paying their replacement roughly the same as what they'll negotiate elsewhere... and on top of that, you have to deal with the cost of turnover. You basically just lost a ton of $$ by letting them walk. This is not hard. Just run the thought experiment of what it would cost to find a suitable replacement.
- scarface74 8y ago
  Simple. How much would it cost you to pay someone to replace them at market rates and then add the amount it would cost you to give them time to ramp up on the institutional knowledge and codebase.
  - bosie 8y ago
    Well, not really. The phrase was specifically about how much value they bring to the company. Market rates have no meaning in this context. E.g. how is "if a team works on a product that no customer seems to use/purchase/pay for, what is the value that team brings to the company" connected to market value? I would say it isn't.
    - scarface74 8y ago
      If you want to keep the employee you have to pay market rates or they can easily leave. If the team works on a product that no one wants, that’s the fault of the business side. It’s up to the business to either find something for the tea to work on or let them go.
reallydude 8y ago
> pay people by the value they bring to the company That's a fun game. Most people can argue endlessly about who is responsible for what and then you get to disclose where the money (and how much) is actually coming in. It necessarily constrains the management to a whole new slew of in-fighting and disclosure control. Never gonna happen.

vetinari 8y ago

> Consequently they get paid less during that period. But once they can fly on their own, treat them as if you hired them like that. That's too early. You made an investment, that investment has to break even. With your suggestion, it would never break even.

teddyh 8y ago
But that’s not the trick. The trick should be that you train your employees how to do your business, and then you pay them more than what they’re worth to someone else. Since you’ve trained them in the ways of your business, they’re worth more than that, but only to you, and that’s the trick. Nobody else could squeeze as much value out of these people as you could (since the training is specific to what your business does), so you can afford to keep them, and the people have no monetary reason to leave.
- scarface74 8y ago
  I never thought about this, but this definitely seemed to be the original thinking at one company I worked for. As far as I know, the company was started in 2003. The founder wrote a custom IDE, VM and compiler. This was the only company that used it. He hired a bunch of people from a well known but not well regarded private for profit college and paid them below market rates. Of course developers on this proprietary platform were completely useless anywhere else. By the time I came aboard in 2008 and the rest of the “adult supervision” - a new CTO and developers - they were in the process of transitioning to C#. Once the bottom fell out of the market with the 2008 recession, they laid off most of the developers working on the proprietary stuff who hadn’t learned C# on their own. They also forced the founder out. They kept me around because I was the only person who both knew C# and knew enough C++/MFC to maintain the old system.
  - teddyh 8y ago
    Yes, when digging a moat you have to be careful that it does not drown you as well.
cableshaft 8y ago
If they keep leaving because you won't pay them what they can get elsewhere, you won't ever break even that way either.
brandall10 8y ago
With all due respect, if hiring an entry level dev is a loss for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level. You pay them market when they need to be trained, you pay them market when they move up the skill food chain.
- vetinari 8y ago
  He is a loss in short term. He is supposed to be a net gain in long term. If he leaves prematurely, the loss is realized and the gain never happens. If he stays for long enough time, he is a net gain.
  - brandall10 8y ago
    Again, if an entry level dev is a loss then don't hire entry level devs; your company does not adequately utilize them.
    - vetinari 8y ago
      Not every company is using popular, widely available tech, that folks can learn in their spare time. In this regard, unfortunately, we are using a proprietary platform and there is no chance to learn anything until you have access to the bits and docs. Due to that, fresh hires are completely useless to be utilized in any way, until they learn at least basics.
      - brandall10 8y ago
        You're conflating ramp up time of business domain knowledge with skill level. Yes, a sr. dev will come up quicker than an entry because they have the wisdom and experience of past companies, but all devs need some sort of ramp up in an environment like that. You don't hold back pay from your sr. staff until they've ramped up, right? Of course not, they would take a better offer elsewhere. As would your entry levels that have now risen to mid-levels once they get the chance. But all the same, any company should be able to make any dev useful from pretty much the very beginning. Whether it's rote refactoring work, research tasks that are too time consuming for more sr. folks, tasks that are in the domain of data entry that can be automated with simple scripts, low-hanging fruit bugs, etc. It's a failure of the org not to properly utilize the abilities of a smart person who knows how to program.

bosie 8y ago

> pay people by the value they bring to the company upon every annual compensation review. how do you determine the value they bring to the company? Presumably it must be a % of the revenue or valuation growth but I cannot come up how you derive the value.

brandall10 8y ago
How do you determine the value of any candidate you interview? You have a job req. Do they match that req? Yes, good, you make them an offer. What level of pay do you negotiate? What is market. If they're otherwise happy going toward the bottom of market is feasible, esp. if it's a large bump. If this person goes out the door, you're going to be paying their replacement roughly the same as what they'll negotiate elsewhere... and on top of that, you have to deal with the cost of turnover. You basically just lost a ton of $$ by letting them walk. This is not hard. Just run the thought experiment of what it would cost to find a suitable replacement.
scarface74 8y ago
Simple. How much would it cost you to pay someone to replace them at market rates and then add the amount it would cost you to give them time to ramp up on the institutional knowledge and codebase.
- bosie 8y ago
  Well, not really. The phrase was specifically about how much value they bring to the company. Market rates have no meaning in this context. E.g. how is "if a team works on a product that no customer seems to use/purchase/pay for, what is the value that team brings to the company" connected to market value? I would say it isn't.
  - scarface74 8y ago
    If you want to keep the employee you have to pay market rates or they can easily leave. If the team works on a product that no one wants, that’s the fault of the business side. It’s up to the business to either find something for the tea to work on or let them go.

reallydude 8y ago

> pay people by the value they bring to the company That's a fun game. Most people can argue endlessly about who is responsible for what and then you get to disclose where the money (and how much) is actually coming in. It necessarily constrains the management to a whole new slew of in-fighting and disclosure control. Never gonna happen.