I implemented OKRs among my small team of 10 devs who are all pretty awesome rockstars and good contributors, but still early in their careers. It turns out th

I implemented OKRs among my small team of 10 devs who are all pretty awesome rockstars and good contributors, but still early in their careers. It turns out that OKRs made the employees happier, because it served as a “more abstract” form of feedback. Before, they were receiving feedback, but it was too specific and narrow. Things like “this class can be refactored to X pattern” or “You missed a few unit tests covering X Y Z cases.” But when we started tracking things like time to ship a new feature, bugs per implemented feature, hard deadlines for certain product releases, etc. it really helped to give some better feedback. You could tell people who were writing code very fast to slow down in general, and write more stable, thought-out code. For example, there was one dev who tended to have substantially more bugs in his code than the others, and slower ship times. It turns out that he was always being assigned to more complicated Tasks and Stories, and the poor guy was overworked to shit and he didn’t even realize it. It’s got nothing to do with being a drone, and everything to do with not being able to improve until you measure. Do you think Usain Bolt doesn’t have a stopwatch when he runs?