What are OKRs?
OKRs - Objectives and Key Results - are a goal-setting framework that connects ambitious qualitative goals (objectives) to specific, measurable outcomes (key results). The framework was developed at Intel, popularized at Google, and adopted across the technology industry as a way to align teams around shared priorities without prescribing the exact work to be done.
An Objective is a qualitative statement of what the team wants to achieve. It should be ambitious, inspiring, and time-bound. "Become the go-to project management tool for remote engineering teams" is an objective. It's directional, motivating, and clear about the desired end state - but it doesn't tell you how to measure whether you've achieved it.
Key Results are the measurable outcomes that indicate whether the objective is being achieved. Each objective has two to four key results. For the objective above, key results might include: "Increase monthly active remote-team workspaces from 200 to 500," "Achieve a Net Promoter Score of 50+ among remote teams," and "Reduce median onboarding time for new workspaces from 3 days to 1 day." Key results are specific, quantifiable, and verifiable - either you hit the number or you didn't.
OKRs vs KPIs: understanding the distinction
OKRs and KPIs solve different problems. KPIs (Key Performance Indicators) are ongoing metrics that track the health of existing systems and processes. They answer "how are we performing right now?" - things like uptime, customer satisfaction, revenue growth, or deployment frequency. KPIs are baselines. You monitor them continuously and investigate when they move outside acceptable ranges.
OKRs are about change. They answer "where do we want to be in three months that's different from where we are now?" OKRs are time-bound, aspirational, and focused on improvement. When the quarter ends, you evaluate whether you hit the key results, learn from the gaps, and set new OKRs for the next quarter.
Most teams need both. KPIs keep the lights on. OKRs push the team forward. Tracking them in the same system - a kanban board where KPI dashboards are cards and OKR progress is a separate board - keeps both visible without requiring separate tools.
How to set good OKRs
The difference between OKRs that drive alignment and OKRs that become shelf-ware is in how they're written. Good OKRs share a few properties:
Objectives should be ambitious but not impossible
Google's internal OKR guidance suggests that achieving 70% of a key result is a success - the implication being that key results should be set aggressively enough that 100% achievement means you aimed too low. This "stretch goal" philosophy works for some organizations and demoralizes others. The practical middle ground: set key results that are achievable with focused effort and some things going right, but not achievable with business-as-usual. If the team hits every key result at 100%, the goals weren't ambitious enough. If the team consistently achieves less than 50%, the goals are demoralizing and need recalibration.
Key results must be measurable and verifiable
A key result that says "improve code quality" is not measurable. A key result that says "reduce production incidents from 8 per month to 3 per month" is. Every key result should have a number - a percentage, a count, a time metric, a ratio. At the end of the quarter, evaluation should be a simple question: did we hit the number? If the answer requires subjective judgment, the key result wasn't specific enough.
Limit the total count
Two to four objectives per team per quarter, each with two to four key results. That's a total of four to sixteen key results. More than that and the team loses focus. Fewer than that and the OKRs might be too broad to be actionable. The discipline of limiting OKRs forces the team to make priority decisions - which is the whole point. If everything is a priority, nothing is.
Separate output OKRs from outcome OKRs
Output OKRs measure what the team produces: "Ship 5 new integrations." Outcome OKRs measure the impact of what the team produces: "Increase integration-driven signups from 2% to 8% of total." Outcome OKRs are harder to set and harder to achieve, but they're more valuable because they connect the team's work to business results. When possible, prefer outcome key results. Use output key results as supporting metrics when outcome measurement is impractical.
Tracking OKRs with kanban boards
Flux doesn't have native OKR scoring or automated progress calculations - it's a kanban tool, not a dedicated OKR platform. But kanban boards provide the two things that make OKRs succeed: visibility and accountability. Here's how to structure OKR tracking on a kanban board.
Board structure: one board per quarter
Create a board for each OKR cycle (typically quarterly). The columns represent progress stages:
- Not Started. Key results that haven't been actively worked on yet.
- In Progress. Key results where work is underway and the metric is moving.
- At Risk. Key results that are behind target or blocked. This column is the early-warning system.
- Complete. Key results that have met or exceeded their target.
Each key result becomes a card. The card title is the key result statement. The card description includes the baseline metric (where we are now), the target metric (where we want to be), and the measurement method (how we'll verify). Checklists within the card track milestones toward the key result.
Labels for objective grouping
Create a label for each objective and apply it to the corresponding key result cards. If Objective 1 is "Become the go-to tool for remote teams" and it has three key results, all three cards get the "Obj 1: Remote Teams" label. This lets you filter the board by objective and see at a glance how each objective's key results are distributed across the progress columns.
Color-code the labels by objective. If Objective 1 is blue and Objective 2 is green, a quick glance at the board shows the color distribution across columns. If all the green cards are in "Not Started" while the blue cards are in "In Progress," you know Objective 2 needs attention.
Multi-board view for cross-team OKR visibility
If multiple teams or departments set OKRs, the multi-board view displays all OKR boards side by side. A VP of Engineering can see every team's OKR board in one screen - which teams are making progress, which have key results at risk, and how the overall quarterly goals are tracking. This replaces the monthly OKR review meeting where each team presents a slide deck of their progress. The board is the presentation, and it's always up to date.
See multi-board views in action.
The weekly OKR check-in
OKRs that are set in January and reviewed in March are almost always disappointing. Quarterly goals need weekly attention. The weekly OKR check-in is a lightweight ritual - five to ten minutes per team - that keeps key results visible and surfaces problems early.
The check-in process
- Review the board. Open the OKR board and scan the column distribution. Are any key results stuck in "Not Started" past the first few weeks? Are any in "At Risk"?
- Update card comments. For each active key result, the owner posts a brief comment: current metric value, what moved this week, and any blockers. This takes two minutes per card and creates a weekly progress record that's more useful than a meeting summary.
- Move cards if status changed. If a key result that was "In Progress" is now blocked, move it to "At Risk." If one that was "At Risk" got unblocked, move it back. The column is the status - keep it current.
- Flag dependencies. If a key result depends on another team or an external factor, note it in a card comment and escalate if the dependency is causing the key result to slip.
This check-in can be fully async. Each key result owner updates their card at their own pace during the week. The team lead reviews the board and follows up on anything that looks off. No meeting required. For more on replacing meetings with board-based rituals, see the meeting alternatives guide.
Common OKR mistakes and how to avoid them
OKRs fail more often from implementation mistakes than from conceptual problems. The framework is simple. The execution is where teams stumble.
Mistake 1: Setting too many OKRs
Teams that set eight objectives with four key results each end up with 32 items to track. Nobody maintains 32 key results weekly. Within a month, half are stale and the system loses credibility. The fix: ruthlessly prioritize. Two to four objectives, two to four key results each. Force the difficult conversations about what matters most this quarter. The things that don't make the cut go on a backlog for next quarter.
Mistake 2: Confusing key results with tasks
"Launch the new onboarding flow" is a task, not a key result. It describes output (something to ship), not an outcome (a measurable change). The key result should be the measurable impact of launching the onboarding flow: "Reduce new workspace setup time from 20 minutes to 5 minutes" or "Increase day-7 retention from 40% to 55%." If a key result doesn't have a number, it's a task in disguise.
Mistake 3: Setting OKRs and forgetting them
OKRs that live in a Google Doc opened once per quarter are not OKRs - they're wishes. The weekly check-in is what turns goals into actions. If the team doesn't review progress weekly, the quarterly review becomes an unpleasant surprise. The kanban board approach helps here because the board is always visible. It's harder to forget a key result when it's a card on a board you see every day than when it's a line item in a document you opened three months ago.
Mistake 4: Making OKRs punitive
If missing an OKR target triggers negative consequences (reduced bonuses, poor performance reviews), people set safe, easily achievable goals. The entire point of OKRs is to aim high and learn from the gap between ambition and reality. OKR achievement rates should be discussed, not judged. The question is "what did we learn from the gap?" not "why did you fail?" If your organization ties OKR achievement to compensation, OKRs will become conservative targets, and the framework loses its value.
Mistake 5: Top-down only
OKRs work best when they flow in both directions. Company-level OKRs set the strategic direction. Team-level OKRs define how each team contributes to that direction. But team-level OKRs should be authored by the team, not handed down by leadership. The team closest to the work knows what's achievable and what matters. Leadership sets the "what." Teams set the "how."
Getting started with OKRs on a kanban board
If your team hasn't used OKRs before, start small. Set one objective with three key results for the current quarter. Create a board with four columns (Not Started, In Progress, At Risk, Complete). Add three cards. Do the weekly check-in for one quarter and evaluate whether the framework adds value. Most teams find that even this minimal version creates better alignment than no goal-setting framework at all.
Be honest with your team that a kanban board is a lightweight OKR tracker, not a purpose-built OKR platform. It won't calculate confidence scores, generate progress reports, or cascade OKRs across organizational levels automatically. What it does do - and what matters most - is make goals visible, trackable, and part of the team's daily workflow. If the team outgrows the kanban approach and needs automated scoring and hierarchical OKR trees, that's a sign the framework is working and it might be time for a dedicated tool. For most small to mid-size teams, the board is enough.