But this does reveal an organizational problem right; either the security teams have it right and their current work is more important, in which case maybe they

But this does reveal an organizational problem right; either the security teams have it right and their current work is more important, in which case maybe they are under-staffed and need more slack. Or maybe they failed to add a KR for “perform timely security review” if that is a service that they provide to the org. If you’re blocked, you should be able to raise this up and learn something as an org. Or maybe the KRs are correct as written, but the security teams have it wrong and their KRs should be deprioritized only favor of delivering yours. When KRs clash you need to have a conversation and resolve the conflict in the way that maximizes value for the business. Ultimately prioritization of work always involves trade-offs, and there needs to be some mechanism for handling these. No system can handle 100% of cases without adding human judgement. To me it seems the pathology in your example is that everyone was just sticking to the KRs, instead of coming to the best business outcome (and if your request was not prioritized, you should be able to understand the reasoning used to decide that). I can see how OKRs could be used as a shield to hide from those difficult conversations, but it’s not clear to me that they necessarily make things worse; if you didn’t have OKRs maybe your teams would be finding other ways to avoid working on things that they don’t want to help with.