5 ms·

What is a deliverable, though? You can deliver output but the question should be if the quality of the work is better wfh or wfo. The quality of work increases

What is a deliverable, though? You can deliver output but the question should be if the quality of the work is better wfh or wfo. The quality of work increases with face to face time with my colleagues. The quality decreased when I was all alone at home. So for some people with very straight forward deliverables it might be great, but for others that quality may have gone down.

brigadier132 3y ago
I've actually been thinking about ways to align incentives of employees and the company they work for because from working in tech in SF I don't think the Google / Facebook incentive system works. I have some ideas for how to measure output: 1. Code output: I know this one is controversial but at the end of the day code needs to be written. People wouldn't get penalized for missing this minimum output, it's just a signal that their work needs more detailed review. Rather than incentivize people to write more code I would say that some minimum amount of lines of code should be changed or a more detailed review of your work needs to be done. 2. Document output: Designs are obviously important to launching quality software so the work put into design documents should be taken into consideration but it should also result in actual features and products being launched. 3. Feature / Product launches: People actually shipping software and running and completing experiments should be tracked. This should be tracked and rewarded separately from the actual result of the experiment. 4. Feature / Product success: If feature and product launches are successful this should also be tied to employee performance but obviously the employee is not in complete control of this outcome. Sometimes things can be executed on well and just fail so this should be used for a bonus system of some sort. There are obviously ways people can game a system and the system should be adjusted to account for them as they come up. Either way, I think anything that encourages actual accountability is superior to the system people have blindly copied from Google and Facebook where you are rewarded for getting into management and building a tiny kingdom of people that do nothing.
- nine_zeros 3y ago
  This is a personal area of interest for me. I think a lot of what you have described is flawed. It feels more like trying to systemize something that cannot be systemized. One time I spent 6 months in a brutal migration of a critical system. Lines of code in production in those 6 months = 20 lines. By your measure, I did not accomplish much. But where exactly did my time go? It went in getting stakeholders together, performing significant experiments to identify the problem, performing more experiments to find solutions, carefully roll out the experiments in various production datacenter - often over weekends. The output? Migration completed. It was hard work, stressful and took a lot from me. But for a manager strictly follows your rubric, I was unproductive. And now, I get a poor performance rating. I would likely have to sink more time to produce tons of artifacts to prove that that rating was incorrect. Other engineers sees it. Learn to never take up hard problems ever. Just smash more lines of code to be safe. You have single handedly shot the success of engineering by having an uninformed performance review criteria.
  - brigadier132 3y ago
    You missed the nuance of the code output just being one of many signals. But I have to say, if you are hired to produce software and you are doing things like "coordinating stakeholders" then there is already systemic rot in the company.
    - nine_zeros 3y ago
      There is a systematic rot. And often management uses a performance review rubric only to protect themselves or to gut out engineers they don't jive with. It sets the wrong incentives by suggesting that any work outside of these items is worthless. Which is why I disagree with a strict rubric.

brigadier132 3y ago

I've actually been thinking about ways to align incentives of employees and the company they work for because from working in tech in SF I don't think the Google / Facebook incentive system works. I have some ideas for how to measure output: 1. Code output: I know this one is controversial but at the end of the day code needs to be written. People wouldn't get penalized for missing this minimum output, it's just a signal that their work needs more detailed review. Rather than incentivize people to write more code I would say that some minimum amount of lines of code should be changed or a more detailed review of your work needs to be done. 2. Document output: Designs are obviously important to launching quality software so the work put into design documents should be taken into consideration but it should also result in actual features and products being launched. 3. Feature / Product launches: People actually shipping software and running and completing experiments should be tracked. This should be tracked and rewarded separately from the actual result of the experiment. 4. Feature / Product success: If feature and product launches are successful this should also be tied to employee performance but obviously the employee is not in complete control of this outcome. Sometimes things can be executed on well and just fail so this should be used for a bonus system of some sort. There are obviously ways people can game a system and the system should be adjusted to account for them as they come up. Either way, I think anything that encourages actual accountability is superior to the system people have blindly copied from Google and Facebook where you are rewarded for getting into management and building a tiny kingdom of people that do nothing.

nine_zeros 3y ago
This is a personal area of interest for me. I think a lot of what you have described is flawed. It feels more like trying to systemize something that cannot be systemized. One time I spent 6 months in a brutal migration of a critical system. Lines of code in production in those 6 months = 20 lines. By your measure, I did not accomplish much. But where exactly did my time go? It went in getting stakeholders together, performing significant experiments to identify the problem, performing more experiments to find solutions, carefully roll out the experiments in various production datacenter - often over weekends. The output? Migration completed. It was hard work, stressful and took a lot from me. But for a manager strictly follows your rubric, I was unproductive. And now, I get a poor performance rating. I would likely have to sink more time to produce tons of artifacts to prove that that rating was incorrect. Other engineers sees it. Learn to never take up hard problems ever. Just smash more lines of code to be safe. You have single handedly shot the success of engineering by having an uninformed performance review criteria.
- brigadier132 3y ago
  You missed the nuance of the code output just being one of many signals. But I have to say, if you are hired to produce software and you are doing things like "coordinating stakeholders" then there is already systemic rot in the company.
  - nine_zeros 3y ago
    There is a systematic rot. And often management uses a performance review rubric only to protect themselves or to gut out engineers they don't jive with. It sets the wrong incentives by suggesting that any work outside of these items is worthless. Which is why I disagree with a strict rubric.