3 ms·

I meant to say that I don't see why I should give someone a raise simply as a result of increased performance. it's my goal as an employer to extract more value

by ouid 10y ago

I meant to say that I don't see why I should give someone a raise simply as a result of increased performance. it's my goal as an employer to extract more value from an employee than they cost. The only thing that would compel me to give out raises is a change in market conditions, which can usually be detected by an employee threatening to leave for a job which pays more.

falcolas 10y ago
If you're waiting for employees to leave, you're waiting too long. Raises, bonuses, cost of living adjustments; all are part of how you attempt to retain talent. If you're hiring coding cogs, then no, you don't need to give any raises. Just hire at the market rate and plan for 50% attrition every year. But if you want to keep your employees for more than a few years, you pay them more than the market rate. You match the cost of living increases, you give them performance bonuses, and you give them a minimum of 5-10% raises annually. Bonus points if you recognize that ass-in-seat time is not a good proxy for performance. Do that, and they won't leave because they aren't getting paid commensurately with their skills. Still need to give them interesting work, though.
- ouid 10y ago
  You are making the false assumption that value is fixed for a fixed amount of work. Programmers, and more generally engineers, do not have a fixed value for labor. It is generally the case that it is much more efficient to have the same engineer starting and finishing a project. This means that you as a programmer, have negotiating power that scales with the amount of work that you have already done. If you are not getting paid in proportion to what it would cost to replace you at any given point of the process, then you are getting paid well below the actual "market" rate. This means that if you are an at will programmer, you can do less work the closer the project gets to completion without it being a good idea to fire you. If a small raise disproportionately discourages this behavior, then it makes sense, but it does not count as "paying you more than the market rate". I suspect that you receive, on average, a smaller percentage of the cost of replacement as time goes on.

by ouid 10y ago

falcolas 10y ago

If you're waiting for employees to leave, you're waiting too long. Raises, bonuses, cost of living adjustments; all are part of how you attempt to retain talent. If you're hiring coding cogs, then no, you don't need to give any raises. Just hire at the market rate and plan for 50% attrition every year. But if you want to keep your employees for more than a few years, you pay them more than the market rate. You match the cost of living increases, you give them performance bonuses, and you give them a minimum of 5-10% raises annually. Bonus points if you recognize that ass-in-seat time is not a good proxy for performance. Do that, and they won't leave because they aren't getting paid commensurately with their skills. Still need to give them interesting work, though.

ouid 10y ago
You are making the false assumption that value is fixed for a fixed amount of work. Programmers, and more generally engineers, do not have a fixed value for labor. It is generally the case that it is much more efficient to have the same engineer starting and finishing a project. This means that you as a programmer, have negotiating power that scales with the amount of work that you have already done. If you are not getting paid in proportion to what it would cost to replace you at any given point of the process, then you are getting paid well below the actual "market" rate. This means that if you are an at will programmer, you can do less work the closer the project gets to completion without it being a good idea to fire you. If a small raise disproportionately discourages this behavior, then it makes sense, but it does not count as "paying you more than the market rate". I suspect that you receive, on average, a smaller percentage of the cost of replacement as time goes on.