The Problem with OKRs Isn’t OKRs
Why most teams would be better off with a clear plan than a quarterly ritual.
I first encountered OKRs at Datadog. They were already in place when I joined — nobody really explained the “why” behind them. You just filled out your section in the shared Google Doc. The company was growing fast, already past 1000 employees. My team was new. We cargo-culted what others were doing.
In theory, OKRs are about aligning a team around measurable objectives. You set a direction (“Objective”), define how you’ll know you’ve made progress (“Key Results”), and track it. Simple. Ambitious. Inspiring, even.
In practice? It was a glorified quarterly to-do list.
Management would come down with a spreadsheet of tasks. You could discuss the list, maybe argue your way into trimming it down. But the measure of success wasn’t impact. It wasn’t even delivery velocity. It was binary: did we check the box, yes or no?
There was no conversation about why we were doing these things. No attempt to tie work to outcomes like activation, retention, support ticket volume, user satisfaction — anything. Product management was largely absent. Engineering was expected to execute. Period.
That’s not OKRs. That’s project management theater with a quarterly cadence.
When Metrics Become a Bludgeon
Because impact could not be measured, the game became about managing perception. If your manager brought you a list of 10 items, the game was to negotiate down to 5 and deliver 6. Overdeliver by carefully managing the optics.
It became a ritual of negotiated checklists, not shared purpose. A way to evaluate individuals, not steer teams. The illusion of alignment without any of the benefits.
When we started Mergify, I brought some of that skepticism with me.
We did try OKRs — for a while. And in some areas, they worked. Marketing, for instance, benefitted from clear metrics and planning: support ticket volume, incident count, lead generation. Things we could measure and reflect on quarterly.
But for product and engineering? Not so much. We didn’t have a mature enough product management function early on. And engineers — rightly — didn’t see the value in spending hours fine-tuning quarterly goals that wouldn’t actually guide their day-to-day.
Eventually, we stopped.
Not because we didn’t believe in planning or goals — but because the format had become more effort than it was worth. We weren’t getting leverage from the process.
Plans, Not Rituals
What I’ve come to believe is this: most teams would be better off writing down a plan than chasing OKR perfection.
A good plan answers: what are we going to ship, why does it matter, and how will we know if it worked?
That’s it.
I appreciated how Posthog described this recently in one of their updates:
“In 2022, we required “OKRs” as part of quarterly planning, but eventually walked it back. We found engineers were agonizing over finding the right metrics, while also feeling like metrics didn't accurately reflect their subjective view of progress.”
They realized something important: even if you do write OKRs, you still need to write the plan. So maybe just… start with the plan.
Let OKRs emerge when they make sense — when you have a clear outcome to optimize for. But don’t let a framework become a crutch.
Success Isn’t a Template
We love templates in tech. We copy Google’s OKRs. Amazon’s memos. Netflix’s culture deck.
But these practices only work when paired with deep understanding. Blindly copying them won’t align your team or 10x your output.
Success isn’t a template. It’s clarity, judgment, and execution.
Sometimes that means writing OKRs. Sometimes it just means writing a plan that everyone understands — and ships.