TL;DR: Most advice on how to write OKRs starts with templates and frameworks. The real problem is who’s doing the writing. When leadership defines the objective and the team writes the key results, you get OKRs people defend in week nine. When leadership writes both and hands them down, you get homework that gets updated out of obligation. Direction from the top. Evidence from the bottom.
This isn’t the foundational guide on writing effective OKRs. That’s over here. This is the deep dive on what changes when teams write their own key results instead of having them handed down.
Your team updates the OKRs every week. The numbers go in. The boxes get checked. And somehow, nobody seems to care.
Not because they’re disengaged. Not because the work is bad. Because the OKRs don’t describe work they recognize as theirs.
How to write OKRs your team will actually care about, in one sentence: leadership sets the direction by defining objectives, and teams propose the key results that show they’ve moved in that direction. That’s it. When teams write their own key results, they own them. When leadership writes them and hands them down, the team gets homework.
Why Do OKRs Feel Like Homework?
The failure mode is almost always the same.
Leadership sets the objectives. Then they ask teams to “cascade” key results downward. The team fills in numbers that satisfy the template. They’re not sandbagging. They’re not resistant. They’re just completing an exercise that someone above them designed for a purpose they don’t fully own.
The OKRs get done. Execution doesn’t follow.
This isn’t a motivation problem. It’s a design problem. Teams can’t care about OKRs they didn’t write, because caring requires ownership. And ownership requires having made actual decisions about what success looks like. Atlassian’s OKR guidance makes this point well: OKRs are most effective when the people responsible for hitting them are also the ones drafting them.
What Bottom-Up OKRs Actually Look Like
Bottom-up doesn’t mean “let teams write whatever they want.”
It means leadership holds the direction and teams hold the measurement. Leadership defines the objective: what does winning look like this quarter for this part of the business? Teams propose the key results: here’s how we’ll know we’ve moved in that direction, based on the work we actually control.
That’s the exchange. Direction from the top. Evidence from the bottom. Both sides in the conversation, not just one side handing things down. Google’s re:Work guide on communicating OKRs reinforces this: the rollout matters as much as the OKRs themselves. Rollouts where teams have a real say in what gets measured land differently than ones where the spreadsheet shows up Friday.
When teams propose their own key results, two things happen. First, the numbers reflect how the team actually works, not how it looks from a spreadsheet. Second, when the quarter gets hard and priorities compete, the team has a reason to come back to the OKRs. They wrote them. They chose those specific outcomes as the signal. When teams write their own key results, you’ve solved the foundational question of how to write OKRs people will own.
How to Write OKRs That Get Owned, Not Assigned
There are four things that separate OKRs a team will chase from OKRs a team will manage. Use these as a checklist when learning how to write OKRs that stick.
- Key results describe outcomes the team controls, not outputs leadership wants. “Launch three features” is an output. “Reduce time-to-first-value for new users by 30%” is an outcome. The pillar guide walks through the full activity-vs-outcome reframe with more examples. The point that matters here: outcomes create ownership, outputs create compliance.
- The first OKR session is a workshop, not a fill-in exercise. Sending a spreadsheet and asking teams to return it by Friday is not an OKR process. It’s a form. Run the first session as a working conversation. What does the objective actually mean for your team’s day-to-day? What would you measure to know it’s happening? That conversation is where ownership gets built.
- Teams can push back on objectives that don’t connect to their work. If a team can’t draw a straight line from a company objective to what they do every week, the objective either doesn’t apply to them or it’s written at the wrong level of abstraction. Both are worth surfacing. A team that can’t find themselves in the objective will treat it as background noise.
- Scoring happens together, not in isolation. When managers score their teams’ OKRs without discussion, the score lands as a verdict. When teams score themselves and walk leadership through their reasoning, the score becomes a calibration. The difference in how it lands is significant. One creates defensiveness. The other creates learning.
These four rules cover the practical mechanics of how to write OKRs that people defend, not just submit. The weekly check-in is where the work compounds: teams update their own progress and add their own context, not a place where managers review what their reports have done. That distinction isn’t subtle. It changes who owns the quarter.
How to Write OKRs Worth Defending Mid-Quarter
The department heads I’ve talked to are usually asking the wrong question.
They’re asking: “How do I get my team to care about our OKRs?”
The better question is: “Why did I write OKRs they can’t care about?”
The first puts the problem on the team. The second puts it where it belongs: in the design of the OKR itself. Key results that describe outcomes the team controls, built in a process that includes the team, scored in a conversation rather than delivered as a grade. That’s not a complicated system. It’s just how to write OKRs that people will actually use.
The teams that consistently hit their OKRs aren’t the ones with the most ambitious objectives. They’re the ones who wrote OKRs they were going to argue about in week nine. Start there. That’s how to write OKRs that survive contact with reality.
Frequently Asked Questions
How to write OKRs that aren’t just leadership’s wishlist?
Separate the objective from the key results in who writes them. Leadership defines the objective (what winning looks like this quarter for this part of the business). Teams propose the key results (the specific outcomes they’ll move and the targets they’ll hit). When the work to write key results sits with the people doing the work, the OKRs land differently.
Should every team have OKRs, or just product and engineering?
Every team that has its own quarterly priorities benefits from OKRs. Sales, marketing, customer success, ops, finance: they all set quarterly goals already. OKRs just give those goals a more rigorous structure. The teams where OKRs add the least value are the ones whose work is genuinely steady-state with no priority changes quarter to quarter, which is rare.
How long should it take to write OKRs for a team?
A first-time OKR writing session, done well, takes 90 minutes to 2 hours per team. Subsequent quarters get faster, usually 60 to 75 minutes once the rhythm is established. If you’re spending less than an hour, you’re probably filling in a template rather than writing OKRs. If you’re spending more than three hours, the objective is probably underspecified and the team is trying to compensate by writing more key results.
What’s the difference between writing OKRs top-down vs bottom-up?
Top-down means leadership writes both the objectives and the key results, then asks teams to execute. Bottom-up (or properly, both-directions) means leadership writes the objectives and teams write the key results that flow from those objectives. The second model creates ownership because the team made actual decisions about what success looks like for them. The first model creates compliance because the team is just executing someone else’s specifications.
Explore the Platform and see how OKR Leader supports the back-and-forth that makes OKR ownership possible.
