If that's what your OKRs look like as a developer, then your company is doing them very wrong. They're supposed to be hierarchical, becoming more concrete as you go down the line. Your examples sound like top-level OKRs; mine are usually something like "internationalize feature x, launch in Y locales" or "Implement feature Z, measure effect on meric A".
Which is not to say the OKR system doesn't still have issues, they just look more like the ones discussed in the OP.
Yep, this would be good feedback up the chain. People above you should be working on breaking the company level goals into team and role specific ones.
Edit: just to note that I have some other criticisms of OKRs, but having them be way too high level, broad, and not actionable should not be the problem.
Please share your criticism. I would be happy to get as much perspective on the topic as possible.
The problem I encountered was having, or the notion of wanting, a product roadmap which is produced from stakeholder, C-level, product- and IT team input parallel to OKRs. I feel this is an anti pattern. You have OKRs and they make your quarterly roadmap or you don't apply OKRs at all to the producing team.
That would be nice. My intuition is that this doesn't happen because the person in the hierarchy who translates "improve customer value by x%" into "internationalize feature x, launch in Y locales" is effectively taking responsibility for showing that the latter impacts the former, which is the problem I find to be intractable.
Which is not to say the OKR system doesn't still have issues, they just look more like the ones discussed in the OP.