1. Why We Needed More Than Just Alignment
By mid-2022, many of us working with quarterly planning had grown weary of OKRs that never quite landed. They started high-level and aspirational, but often lost traction once the quarter began. We’d spend time crafting objectives that sounded impressive but lacked grounding in actual team work, customer data, or technical feasibility. The result was familiar: OKRs that were either too vague to guide daily priorities or too disconnected from delivery reality to be useful.
OKRs weren’t broken. But they weren’t helping either. We didn’t need a revolution—we needed relevance. We needed a structure that created space for reflection, allowed for diverse perspectives, and translated strategic direction into shared ownership. Our real question wasn’t “how do we write better OKRs?” but “how do we get real commitment from the team to execute them meaningfully?”
So we decided to stop treating OKRs as quarterly rituals and start treating them as a conversation. This is where OKRA was born: not from ambition, but from a grounded desire to make things work better.
| Challenge | Impact on Execution |
|---|---|
| Late definition of OKRs | Poor alignment and lack of visibility |
| Lack of cross-functional input | Goals misaligned with actual constraints |
| No continuity between quarters | Repetitive context-setting and rework |
We needed a framework that didn’t just tell people what to aim for—but involved them in shaping the aim.
2. The Core Belief: Commitment Through Co-Creation
The foundation of OKRA is deceptively simple: people commit to what they help build. Yet this belief had profound consequences. It meant we had to stop handing down OKRs and start co-creating them. This wasn’t just a feel-good philosophy—it was a deliberate shift in ownership, trust, and accountability.
Instead of locking ourselves in a room to define the quarter, we invited team members to sessions where their ideas, concerns, and priorities shaped the final output. This allowed engineers, product managers, designers, analysts, and other specialists to bring their perspective. Often, they flagged risks or surfaced insights leadership alone wouldn’t have seen.
Here’s what shifted:
- Team members understood the “why” behind the work
- Trade-offs became explicit and debated early
- Milestones were scoped with actual technical constraints in mind
- Conversations moved from abstract strategy to actionable priorities
# From High-Level Objective
Objective: Improve Pricing Experience for Multi-Leg Journeys
# To Co-Created, Shared Ownership
Key Result: Reduce support tickets related to pricing by 40%
Milestone: Deliver dynamic markup preview component by Week 6
What began as a messy, collaborative draft often turned into a strong shared plan—precisely because everyone had a voice in shaping it.
3. Familiar Tools, Different Rhythm
One of the smartest moves we made wasn’t to reinvent tools, but to rethink how and when we used them. Spreadsheets, Figma boards, Miro maps, Jira—none of these were new. What changed was our rhythm.
We introduced a five-session process that took our team from vision to execution. Each session had a purpose, a facilitator, and a shared template. No session was about “status updates.” They were about making trade-offs visible, aligning early, and removing ambiguity.
The rhythm looked like this:
| Session | Goal |
|---|---|
| #0: Vision | Clarify intent and top priorities if company OKRs unclear |
| #1: Ideation | Draft OKRs linked to company direction |
| #2: Milestones | Break OKRs into epics, spikes, validation work |
| #3: Prioritisation | Map milestones by value, effort, dependencies |
| #4: Quarter Draft | Sequence milestones, set ownership and timelines |
This rhythm was light but effective. It gave space to co-create without dragging into process fatigue.
# Example folder structure for OKRA docs
okra/
├── vision.md
├── okrs-draft.md
├── milestones.csv
├── prioritisation.xlsx
└── quarter-plan.md
Templates weren’t for reporting—they were decision-making scaffolds.
4. What Changed When We Used OKRA
The biggest difference was not what we planned—it was how we executed. Mid-quarter confusion dropped dramatically. We heard fewer questions like “why are we building this?” or “when did this become important?” Instead, teams asked, “when do we start?”
With shared milestones and clearer ownership, engineers could spot blockers early. Product managers had more support aligning delivery. Designers and analysts felt less like side contributors and more like core builders.
We also saw stronger mid-quarter decisions. Because we had defined effort and risk early, we could make real trade-offs when priorities shifted. We weren’t throwing plans away—we were adjusting with clarity.
| Result | What Enabled It |
|---|---|
| 82% Milestone Completion | Shared visibility, sequencing, commitment |
| Less Execution Chaos | Pre-discussed risks and owner accountability |
| More Cross-Functional Support | Co-creation fostered shared responsibility |
We didn’t just align. We actually delivered.
5. Start Small. Don’t Wait for Perfect.
You don’t need to adopt the whole OKRA framework overnight. Most teams won’t. But if you can run Session #0 this quarter, or map milestones with engineers before finalizing OKRs, you’ll start to see the shift.
OKRA isn’t about more process. It’s about higher signal. It turns OKRs from quarterly ceremonies into quarterly commitments—because they’re built by the people doing the work.
If you’re stuck resetting every three months, give co-creation a chance. It won’t solve everything. But it might just help your team find a better rhythm, together.
# Minimal setup to start OKRA
cp templates/okra/* your-team/q3-2022/
open vision.md # Start with what matters most
Try it. Adapt it. Make it yours. That’s how OKRA was built—and how it continues to evolve.