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.

Putting this in a separate reply as it's a separate train of thought.

> Even so, how does one write an OKR for a scenario like this? Objective: be able to access GSuite API from tool Foobar so it knows about everyone's availability. Key result: Umm, can complete a feature everyone wants?

The key thing about an objective is that it is a high-level goal. You've written the implementation into the O, which is a bit of an anti-pattern.

It's a bit hard to extrapolate exactly what the context was for your feature, but let's say your team owns an internal tool that orchestrates a business ops system that manages a task queue for "agents"; say "review these potential fraud cases that the system flagged".

As this is an existing system that you're trying to improve, not a new product, your team's objective for the Q might be attacking the main stakeholder-facing pain point with "Improve response time for manual review tasks". A KR that measures this might be "P50 latency for handling fraud reviews is reduced from 5d to 1d". (This formulation gives you a progress bar -- "0% complete" is >=5d, "100% complete" is <= 1d. You can easily build a dashboard for this, which is the holy grail for KRs.)

Now, based on the observation that most of your significant delays for this process are due to tasks being scheduled on agents that are on vacation, an initiative that you propose to progress the KR is to add calendar-awareness to your service's scheduling process. But, there are a bunch of possible initiatives that could move the needle here, and so as a team you get together and figure out which are going to have the best bang-for-buck.

Formulating the OKRs like this gives the team freedom to figure out exactly how they are going to solve the problem, while also communicating to the rest of the org what you're working on (and giving the org a chance to say "isn't <other objective> way more important?". And turning the implementation into a precise KR gives you the opportunity to discuss with stakeholders whether P50 is really the metric they care about, or if the business would be better served with P99 or some other way of measuring things. These metric discussions can be annoying, but at their best they can uncover subtle differences in expectations.

Note -- this is quite process-heavy; you wouldn't go into this much detail with a two-pizza-team startup! But if your team is dedicated to this internal tool in a company of tens of teams, then this level of detail might make sense for you.