We've been doing OKRs at my employer for a while. It's always really difficult for the development team to come up with ideas because we know that there's a higher than average chance that we'll get pulled to work on something that's unrelated to the OKRs we've come up with; and while everyone says we're not being judged on our OKRs, _someone_ is keeping track, otherwise they're not really useful.
I'll be reading and re-reading this article for a while.
I work at at company that does OKRs as well. I think I've viewed both the symptoms you described and the common pattern described in the article of fitting an existing backlog to OKRs.
I think one observation that I have is that OKRs are really a framework to help teams understand what direction/goal to head to and understand progress toward that goal. And really, this mindset needs to be adopted not just by the development teams-- it needs rigor and consistency from leadership as well.
For example, the leaders are accountable for setting direction and describing what they think is important. If they then start asking you for things that aren't tied with an OKR, it's a perfectly fair question to ask leadership "Why are you asking me to work on this when you indicated it's not important to our company strategy?" If the team feels like they're going to be working on something unrelated to their OKRs, that's symptomatic of leadership not sending a consistent message on strategy or prioritization.
I've also seen it from the other side as described in the article. I've seen development teams really struggle to initially understand OKRs and the value. As mentioned earlier, it's really designed to help clarify direction and progress-- if a team is ignoring the OKR and fitting their backlog, that's symptomatic that they're really not trying to understand the direction leadership wants to head.
What I like about the author's suggestion is that it really forces the team to understand the problem the organization is trying to solve and think up solutions how to achieve it. Backlog bankruptcy is one way to do it, though there are likely some items that can still solve the problems outlined in the OKR. Those items just shouldn't automatically be transferred over without verifying they solve a problem that needs to be solved.
Teams shouldn't be fitting problems to work-- teams should be fitting work to problems.
This seems like there isn't buy-in to the OKRs across your employer. My company does OKRs and it's taken seriously by VPs as well as the devs. Here, it's very reasonable to say no to something (and have that be respected) because it's not contributing to your team's OKRs. If it's a VP or something and insists it needs to be done then that means the OKRs need to be updated to reflect the nature of this work.
Thanks for another example of how OKRs aren't working for devs. A part of the inspiration to write this was that I noticed most developers feel that something is wrong with the OKR process, but they can't put their finger on exactly what.
I'll be reading and re-reading this article for a while.