How to Set a Goals That Drive Execution: An OKR Guide

Your leadership team agreed the strategy in January. By June, you're still discussing the same priorities. People are busy, projects are moving, and department heads can explain their activity. Yet nobody can show whether the business is getting closer to the result you agreed.

I wouldn't start by rewriting the strategy. I'd examine how you set goals, assign responsibility and respond when delivery slips. A goal should help you control execution, not just describe ambition.

Why Goals Stall Between Strategy and Delivery

Consider a familiar situation. Sales commits to growth, product commits to releases, and customer success commits to retention. Each function leaves the planning meeting with a plausible list of goals.

Then the dependencies emerge. Sales needs functionality that product hasn't prioritised. Customer success needs implementation support that nobody has budgeted for. The leadership team discusses progress through departmental updates, so nobody resolves the conflict between those commitments.

By March, people are reporting work completed rather than progress against the intended result. By June, the original priorities are still on the agenda. This is an illustrative scenario, not a client case study, but it gives you a useful diagnostic question: what happens between agreeing a goal and making the next resource decision?

Agreement isn't execution

The gap between intention and practice is visible in UK performance-management evidence. More than 90% of respondents supported regular review meetings, but only 62.7% said their organisations held them to assess progress against targets, according to Performance Management in Action.

I read that as a management problem, not a wording problem. A leadership team can agree that reviews matter without creating a useful review process. A meeting invitation doesn't establish who must bring evidence, who can resolve a dependency or who decides what stops.

A goal that never changes a decision is a statement of intent, not an execution control.

My starting point is to examine the connections between priorities, people and delivery. The four dimensions of execution provide a useful lens for that diagnosis. Don't assume a missed target means the person responsible lacked effort.

Work backwards from the result

For deadline-bound work, I favour reverse planning. The advice to plan backward from your submission deadline from Thesis Book Project offers a useful parallel: start with the required endpoint, then expose the work and decisions needed before it.

In business, that means identifying the result, the evidence required to confirm it and the dependencies that could prevent it. A launch date matters, but so does knowing when a customer decision, technical approval or capacity commitment must happen.

I use these questions to expose the weak points:

• Outcome: What must change in the business?
• Ambition: Is the target demanding but credible?
• Alignment: How does each team contribute without creating conflicting commitments?
• Control: Will the OKR format make ownership and corrective decisions clearer?

If you arrived searching for “how to set a goals”, the useful answer isn't a better planning template. It's a tighter connection between what you intend and how you manage delivery.

Writing Outcome-Focused Goals Instead of Activity Lists

Launching something isn't the same as improving something. A release can go live while customers still struggle. Training can finish while the underlying performance problem remains.

I start with the business result, then separate it from the work intended to produce it. That distinction matters when leaders approve budgets, assess progress and decide whether an initiative deserves more investment.

Rewrite the result before choosing the work

Take an illustrative scale-up whose customers take too long to experience value. Its original goal is launch the new onboarding flow. That describes a deliverable. It doesn't establish whether onboarding gets better.

I'd rewrite the goal as help newly acquired customers reach their first meaningful product outcome sooner. Then I'd build the measurement specification before approving the target.

The blank values are deliberate. Use your actual baseline and agreed target, not invented precision. If the data doesn't exist, establish the baseline before claiming that the target is credible.

CIPD describes objectives as useful tools when they focus on specific, stretching outcomes, including measurable standards and time-bound work, in its performance-management guidance. The practical distinction is whether the measure reflects the improvement you need, rather than merely the completion of a task.

Specify evidence that people can trust

For time-to-first-value, define when the clock starts and stops. Decide which customers belong in the measure. Otherwise, teams can report different answers while using the same label.

For the supporting measurement work, SIX ERP's discussion of data-driven decision making for business is a relevant companion resource. My recommendation is to settle definitions before building dashboards.

I also distinguish outcomes from deliverables explicitly in the goal record. Keep the onboarding release in the delivery plan. Don't let its completion stand in for customer improvement.

Use a short drafting test:

• Result: Could the team complete every planned activity and still miss the goal? If so, keep the outcome separate.
• Evidence: Would another leader calculate achievement in the same way?
• Responsibility: Can the accountable person explain the next action when the measure moves off track?

A well-written goal should survive a change of method. If the onboarding redesign fails, the intended customer outcome should still guide the next decision.

Sizing Ambition Without Overloading Your Teams

I don't judge ambition by how uncomfortable the target sounds in a planning meeting. I judge it by whether the team has a credible way to change performance.

A stretching goal should force choices about methods, sequencing and resources. An overloaded goal assumes people will absorb more work. Those are different management decisions, and you should name them clearly.

Distinguish stretch from unsupported pressure

In a 2024 survey of 1,000 full-time UK employees, 37% reported increased pressure to meet goals and 36% planned to check work emails during time off, as reported in Workhuman's UK workforce findings. That doesn't establish that stretch goals caused the behaviour. It does make capacity and protected time relevant to goal design.

Before agreeing an ambitious target, I want the leader and team to discuss the mechanism behind it. Will they remove a bottleneck? Change a process? Gain access to a missing capability? Stop serving an unprofitable customer segment?

If the explanation is that everyone must try harder, I'd challenge the target.

CIPD's evidence assessment of workplace goal setting supports specific, difficult goals while emphasising conditions such as task type, commitment, capability and context. I wouldn't treat difficulty alone as evidence of good goal design.

Put capacity assumptions in writing

For a SaaS leadership team, Fundl's resource on how to set realistic goals for your SaaS is a relevant planning reference. I'd bring the conversation back to the resources and constraints behind the proposed commitment.

Record the assumptions that matter:

• Available capacity: Account for operational support, existing commitments and planned leave, not just project time.
• Dependencies: Identify external decisions or specialist input that the team can't supply itself.
• De-prioritisation: Name the work that will stop, shrink or move.
• Boundaries: Make clear that routine out-of-hours work isn't the delivery model.

Then monitor decision latency, blocked work, rework and overtime alongside the outcome measure. These are diagnostic signals, not automatic proof of poor performance. A growing queue of blocked tasks may require a leadership decision rather than another demand for speed.

Capacity test: If achieving the target depends on sustained overtime and nothing being deprioritised, you haven't agreed a credible delivery plan.

I use stretch goals to challenge the current approach, not to disguise a resource shortfall. When conditions change, revise the method or revisit the commitment openly. Don't leave employees to reconcile an impossible workload privately.

Aligning Goals Across Enterprise, Team and Individual Levels

Alignment isn't everyone repeating the company objective. It's being able to trace a useful contribution from the business result to the work someone can influence.

A corporate goal copied into every department's scorecard creates apparent consistency. It doesn't explain how finance, engineering and customer success should make different decisions in support of that goal.

Audit the contribution, not the wording

A UK-reported benchmark found strong alignment at 45% among middle managers and 17% among frontline employees, while 40% judged frontline alignment very weak or nonexistent, as discussed in TrainingZone's examination of goal setting and performance appraisals. The management implication is clear: agreement at the top isn't enough.

I'd audit the connections using an illustrative customer-retention priority:

The enterprise priority should include what leadership won't pursue. If retention requires product attention, explain which acquisition requests will wait. Otherwise, employees inherit incompatible promises.

An OKR cascade should make these contribution paths visible. It shouldn't force every function into an identical hierarchy or give individuals responsibility for results they can't control.

Invite challenge before asking for commitment

Awareness and ownership aren't interchangeable. A 2025 survey of more than 520 UK workers found that 89% knew their organisation's overarching goals, yet 67% wanted a greater role in determining company direction and 72% wanted greater ownership, according to IT Brief's reporting on employee involvement in strategy.

I'd keep strategic direction explicit while allowing teams to shape their contribution. Ask them to challenge the capacity assumptions, dependencies and proposed evidence of success before accepting the commitment.

Disagreement is useful execution information. A team saying that a target depends on another department's unavailable specialist isn't necessarily resisting accountability. It may be identifying a decision that leadership has avoided.

At the monthly governance review, I'd inspect these failure signals:

• Competing priorities: Teams receive incompatible instructions from different leaders.
• Unclear ownership: Contributors are named, but nobody accepts responsibility for the overall result.
• Missing measures: Updates describe confidence or effort without usable evidence.
• Overdue decisions: Teams keep escalating an issue without receiving a decision.

Keep a decision record with the accountable decision-maker and the required resolution date. Don't close an alignment discussion because everyone understands the problem. Close it when the people involved know what they're authorised to do next.

Converting Goals Into OKRs and Choosing the Right Format

OKRs are useful when you need stronger coordination and sharper decisions. They aren't automatically better than a short, well-managed goal list.

I'd retain a simple format where the work is contained, ownership is clear and dependencies are limited. I'd consider an OKR cascade where several teams must contribute to a strategic change and leaders need to see whether their combined effort is working.

Plain goal list compared with an OKR cascade

These are design choices, not guaranteed benefits. A badly managed OKR cascade can create more administration than a simple list.

The distinction between OKRs and SMART goals matters less than the problem you're trying to solve. Don't introduce another format because the existing targets look untidy. Introduce it because leaders need a clearer way to direct and inspect execution.

Convert the goal without importing the project plan

For the onboarding example, I'd use a directional objective such as make early customer adoption faster and more dependable. I'd then choose a small set of key results that test the improvement from different angles.

Possible measures include time-to-first-value and the share of new customers reaching the agreed activation milestone. Each needs its actual baseline, target and measurement definition. A quality guardrail could check that faster onboarding doesn't create more downstream support problems.

The redesign remains an initiative. The key results establish whether the initiative worked.

Don't turn every milestone into a key result. Keep delivery tracking available without confusing it with evidence of business improvement.

For implementation, the options include an internally led reset, targeted coaching or external support. Through The OKR Hub, I use OKR Focus Flow to diagnose where goals break, design the appropriate system, deploy it into existing operating rhythms and build internal capability through training and coaching.

I'd choose the scope of that work based on the execution problem. A team with inconsistent measures may need a light intervention. An enterprise with conflicting governance, disconnected planning cycles and weak cross-functional accountability needs a broader redesign.

The operating discipline matters. CIPD found that 89% of employees with systematic performance management agreed that they achieved their job objectives and fulfilled requirements, compared with 76% among those with no performance management, in its analysis of performance management's impact on employees. That's an association, not proof that adopting OKRs produces the same result.

My test is simpler: when evidence changes, does the leadership team change a decision? If not, the new format hasn't fixed the old problem.

Quick Checks and Your Next Step

Start with the goals you're already using. Don't commission a new planning process before identifying what's broken.

I'd bring the current goal register, recent review notes and unresolved dependency decisions into the same diagnostic. Read them together. The goal statement shows intent; the review record shows how managers use it.

Mark what's usable and what needs repair

Use ready, repair or unresolved as working labels. They're a triage device, not a performance score for employees.

Don't average the labels into a reassuring overall score. A strategically important goal with unresolved ownership needs attention even if its wording is excellent.

I'd repair the most consequential gaps first. Prioritise goals attached to major resource commitments, cross-functional dependencies or decisions leadership has already delayed. Cosmetic improvements can wait.

Read the review notes for warning signs

A tick-box process is visible in what managers record. Look for repeated status descriptions, unchanged action lists and discussions that end without an accountable decision-maker.

Other warning signs deserve attention:

• Universal green status: Ask whether the evidence supports the assessment, rather than assuming confidence means progress.
• Repeated deferrals: Check whether managers are moving deadlines without addressing the cause.
• Activity substitution: Notice when completed work replaces discussion of the intended result.
• Silent target changes: Require an explanation when conditions justify changing the commitment.

Stronger management practices are associated with higher productivity and resilience in the ONS assessment of management practices in the UK. I'd use that as a reason to improve the management routine, not as a promise that a new template will raise performance.

The concrete next step is a diagnostic of the current goal set and its alignment gaps. Establish whether the problems are local or systemic. Then decide whether you need a light reset, focused coaching or a full OKR operating system.

Keep what already supports useful decisions. Replace what creates reporting without control.

I help leadership teams diagnose stalled goals, resolve alignment gaps and embed OKRs into practical execution routines. To discuss what needs to change in your organisation, book a conversation.