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.

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.

Which is why I disagree with a strict rubric.