Beyond OKRs: Goal-Setting Frameworks for Engineering Teams in 2026

When OKRs Are the Wrong Tool

OKRs work brilliantly under specific conditions: a stable enough environment to set meaningful quarterly goals, leadership that tolerates aspirational failure, measurable outcomes, and quarterly planning cadence. The model that John Doerr popularized in Measure What Matters and that Google documents in re:Work assumes exactly those conditions. When they are absent, OKRs become bureaucratic overhead that demoralizes teams and produces gamed metrics.

Here are the contexts where OKRs consistently fail:

Early-Stage Startups

In a pre-product-market-fit startup, priorities shift weekly based on customer feedback, funding conversations, and competitive moves. A quarterly objective set in week 1 is often obsolete by week 4. The team either ignores the OKRs (making them theater) or rigidly pursues them despite changed circumstances (making them harmful). Startups need a framework that adapts on a weekly timescale, not a quarterly one.

Firefighting Teams

Teams in a reliability crisis or heavy maintenance mode spend most of their capacity on incidents and unplanned work. Setting forward-looking OKRs when 70% of your time is reactive sets the team up for failure. They cannot deliver on the OKRs because the incidents consume the capacity, and the failed OKRs add demoralization on top of the existing firefighting stress.

Research and Exploration Teams

ML research teams, R&D groups, and exploratory engineering teams produce their best outcomes unpredictably. The whole point of research is that you do not know the answer in advance. Forcing a research team to commit to key results ("achieve 95% model accuracy") either constrains them to safe, incremental work or sets them up to fail at genuinely ambitious exploration. Research needs a framework built around hypotheses and learning, not committed outcomes.

Continuous-Flow Platform Teams

Platform and infrastructure teams often do continuous improvement work that does not decompose neatly into quarterly objectives. Their value is in steady incremental improvement (faster deploys, fewer incidents, better developer experience) measured by trends, not quarterly targets. Forcing discrete OKRs onto continuous-flow work creates artificial milestones that distort the natural rhythm of the work.

Alternative 1: North Star Metric + Weekly Bets

Best for: fast-moving early-stage teams, growth-focused engineering organizations.

A North Star Metric (NSM) is a single number that captures the core value your product delivers. "Weekly active teams" for a collaboration tool. "Successful API calls" for a developer platform. "Nights booked" for a travel product. The entire organization aligns around moving this one metric.

How It Works for Engineering

Below the NSM are input metrics that engineering can directly influence: page load time, feature adoption rate, onboarding completion rate, API reliability. Each input metric contributes to the NSM through a documented causal hypothesis.

Instead of quarterly objectives, the team runs weekly or biweekly "bets": small, time-boxed initiatives aimed at moving an input metric. "We bet that reducing checkout latency from 800ms to 300ms will increase the conversion input metric by 5%." The bet is scoped to fit a 1-2 week cycle. At the end, you measure: did the input metric move? Did it affect the NSM?

Why It Beats OKRs for Fast Teams

The weekly bet cycle adapts to changing priorities far faster than quarterly OKRs. When customer feedback reveals a new priority, you adjust next week's bet rather than abandoning a quarterly objective. The NSM provides stable long-term direction (it rarely changes) while the bets provide tactical flexibility (they change weekly).

The Trade-Off

North Star + Bets provides less explicit organizational alignment than OKRs. Different teams might run bets that pull in slightly different directions because the framework prioritizes speed over coordination. This is acceptable for small, fast teams (under 30 engineers) where everyone can see what everyone else is doing. It breaks down at scale where coordination matters more.

Alternative 2: Shape Up

Best for: product engineering teams that struggle with the abstraction of outcome-based goals.

Shape Up, developed at Basecamp, replaces quarterly objectives with 6-week cycles. The core concepts:

• Appetite, not estimate: Instead of estimating how long a feature will take, decide how much time it is worth (the "appetite"). A small batch is 2 weeks; a big batch is 6 weeks. Then shape a solution to fit the appetite.
• Shaping: Before committing, senior people "shape" the work — define the problem, sketch a solution at the right level of abstraction, and identify risks. Shaped work is concrete enough to bet on but loose enough to leave implementation details to the team.
• Betting: Leadership bets on shaped work for the next cycle. A bet is a commitment to give a team uninterrupted time to deliver shaped work within its appetite.
• The cool-down: Between 6-week cycles, a 2-week cool-down for bug fixes, exploration, and shaping the next cycle's bets.

Why It Beats OKRs for Some Product Teams

Shape Up is concrete. Engineers commit to building specific things, not achieving abstract outcomes. For teams that find OKRs too abstract ("what does it actually mean to improve developer velocity by 20%?"), Shape Up's tangible project commitments feel more natural. The fixed appetite also prevents the scope creep that plagues OKR-driven teams: when the time is fixed and the scope is variable, teams ship something useful within the cycle rather than perpetually extending a project to hit an outcome target.

The Trade-Off

Shape Up focuses on outputs (what you build) rather than outcomes (what changes for users). It provides less strategic alignment than OKRs because it does not force the team to articulate why the work matters in measurable terms. Pair Shape Up with organizational-level outcome metrics to compensate: use Shape Up for execution, use a North Star or organizational OKRs for direction.

Alternative 3: Continuous DORA Improvement

Best for: platform teams, infrastructure teams, and mature delivery organizations focused on flow.

The DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore service) measure software delivery performance. Instead of setting quarterly targets for these metrics (an OKR approach), the continuous improvement model monitors the trends and pursues steady incremental improvement without fixed quarterly milestones.

How It Works

The team maintains a dashboard of the four DORA metrics plus a few supporting metrics (developer satisfaction, on-call burden, infrastructure cost). They review the trends weekly. When a metric trends in the wrong direction, they investigate and address the cause. When a metric plateaus, they run experiments to break through the plateau.

There are no quarterly targets. The goal is continuous improvement: every metric should trend in the right direction over time, with the rate of improvement varying based on where the bottlenecks are.

Why It Beats OKRs for Flow Work

Platform and infrastructure work is inherently continuous. There is no natural "done" point for reliability or developer experience — you keep making it better incrementally. Forcing this work into quarterly OKRs creates artificial milestones that distort the work. The continuous improvement model matches the natural rhythm: monitor trends, address bottlenecks, improve steadily.

It also avoids the gaming problem. When deployment frequency is an OKR target, teams game it (deploy trivial changes to inflate the number). When it is a monitored trend in service of genuine flow improvement, the incentive to game disappears because the team owns the metric rather than being measured against it.

The Trade-Off

Continuous improvement provides less forcing function than OKRs. Without targets, complacency is a risk: the team monitors the metrics but does not push hard to improve them. Mitigate this with periodic "improvement sprints" where the team picks the weakest metric and runs a focused effort to improve it. The continuous model provides the steady-state; the improvement sprints provide the occasional push.

Alternative 4: Opportunity Solution Trees

Best for: discovery-driven product engineering, research teams, exploratory work.

Opportunity Solution Trees (OST), from Teresa Torres's continuous discovery work, structure goal-setting around a clear desired outcome at the top, branching into opportunities (user needs or problems), then solutions (ideas to address opportunities), then experiments (tests to validate solutions).

How It Works for Engineering

Start with a desired outcome ("reduce time-to-first-value for new users"). Map the opportunities (the problems preventing fast time-to-value): confusing onboarding, slow initial load, unclear next steps. For each opportunity, brainstorm solutions. For each solution, design experiments to validate it before committing engineering effort.

The framework embraces uncertainty. Instead of committing to "build feature X" (which assumes you know X is the right solution), you commit to "explore the onboarding opportunity through these three experiments." The output is learning, which informs the next round of solution exploration.

Why It Beats OKRs for Exploratory Work

Research and discovery work produces its value through learning, not through predetermined outcomes. OKRs force you to commit to results you cannot predict. OST lets you commit to a learning process toward an outcome, which matches the actual nature of exploratory work. You still have a clear desired outcome (the top of the tree) but the path to it emerges through experimentation rather than being committed in advance.

The Trade-Off

OST requires discipline to avoid becoming an excuse for unfocused exploration. The desired outcome at the top of the tree must be clear and the experiments must have genuine learning goals. Without this discipline, OST degrades into "we are exploring" with no accountability. It works best for teams with strong product discovery skills and weak with teams that need external structure.

Choosing the Right Framework

The right framework depends on two dimensions: how predictable is the work, and how continuous is the work. Map your team and pick accordingly:

The Hybrid Model

Mature organizations rarely use a single framework across all teams. The most effective pattern I have seen combines organizational-level OKRs with team-level execution frameworks:

• Company and CTO level: OKRs that set strategic direction. "Reduce customer churn by improving product reliability and performance."
• Product engineering teams: Shape Up cycles or North Star bets, aligned to the organizational OKRs. The team chooses what to build to contribute to the organizational outcomes.
• Platform teams: Continuous DORA improvement, with the understanding that better delivery infrastructure serves the organizational OKRs indirectly.
• Research teams: Opportunity Solution Trees, with desired outcomes derived from the organizational OKRs.

The organizational OKRs provide alignment (everyone knows what outcomes the company is pursuing). The team frameworks provide execution flexibility (each team works in the way that fits its nature). This is the maturity: aligning on outcomes while allowing flexible execution, rather than forcing one framework everywhere.

How to Transition Away from OKRs

If your team is using OKRs and they are not working, do not abandon them abruptly. The transition:

1. Diagnose why OKRs are failing. Is the environment too unstable (early-stage)? Is the work too continuous (platform)? Is it too exploratory (research)? Is the team in firefighting mode? The diagnosis determines the alternative.
2. Pilot one team. Pick the team where OKRs are most clearly failing and try the matching alternative for one quarter. Measure whether the new framework improves focus, morale, and delivery.
3. Keep organizational OKRs. Even if individual teams move to other frameworks, maintain company and CTO-level OKRs for strategic alignment. The teams' frameworks should connect to these organizational outcomes.
4. Expand based on results. If the pilot works, extend the matching framework to similar teams. Do not force every team to the same alternative — match the framework to each team's context.

The Core Principle

Goal-setting frameworks are tools, not religions. OKRs, North Star Metrics, Shape Up, DORA continuous improvement, and Opportunity Solution Trees each work well in their fitting context and poorly outside it. The mistake is not choosing the wrong framework — it is choosing any framework dogmatically and forcing it onto work that does not fit.

The best CTOs I know are framework-pluralists. They understand the conditions under which each framework works, they diagnose their teams' contexts honestly, and they match the framework to the work. They maintain organizational alignment through high-level outcome goals while allowing teams the flexibility to organize their execution in the way that fits their nature.

OKRs are not outdated. They are over-applied. The 2026 maturity is knowing when to use them and when to reach for something else.