OKRs? More like, R U OK?

I started my first job as a software engineer in the early 2000s. Since then, I’ve been part of nine different teams in companies of all sizes, including my own, and every single time, at some point, we would talk about objectives and key results, or OKRs. At first, I was open and equally skeptical about trying it. I was open because, in principle, the idea feels sound: you have concrete objectives, and you have to implement measurable ways of tracking their progress. But, I was still skeptical, the same way every software engineer knows that just because a big, famous company implemented something and worked for it, it doesn’t mean it will make sense for your team. Still, in the spirit of being a good team player, I, most of the time, went along with it. Most of these OKR conversations happened when the team was growing, and communication seemed to be breaking, or when a new manager would experience pressure from the top to justify priorities or improve alignment. What I found fascinating about these conversations is that we rarely took the time to debug our underlying issues. Instead, we’d quickly commit to a new way of conceptualizing work. I know some of you reading this post may have had great experiences with OKRs, so I aim to share arguments as to why I strongly believe OKRs do not work for engineering teams. If OKRs worked for you, please share the specific context that made them work in the comments. That way, we all learn from each other. Deal? <a href="https://betterprogramming.pub/okrs-more-like-r-u-ok-caaf5b7db7e6">Visit Now</a>