Tag: Strategic Alignment

Most quarterly reviews are retrospectives disguised as strategy sessions. They spend 80% of the time reviewing what happened and 20% of the time agreeing that the same plan will work better this quarter if everyone just executes a bit harder. Nothing changes. The cycle repeats.

A quarterly strategic review that drives change looks different. Here’s how to run one.

Pre-Work (Week Before)

Send three questions to all participants in advance:

1. Which of our strategic objectives made meaningful progress this quarter, and what drove it?
2. Which made insufficient progress, and what was the root cause?
3. What assumption has changed that should affect our strategy or priorities?

Require written answers — not slides, not bullet points in Slack. Written pre-work forces synthesis and reveals where there is genuine alignment versus polite agreement.

The Agenda

Opening (20 min): Review the strategic objective scorecard — not a deep dive, just the RAG status and headline results for each objective. Everyone should already know the details from the pre-work.

Deep dives (60 min): Focus on two to three objectives — one that’s going well (to understand what’s replicable) and one or two that are struggling. For each, root-cause the performance rather than accepting surface explanations.

Strategic assumptions review (30 min): Which assumptions underlying the strategy have changed? Market conditions, competitive landscape, internal capacity, technology availability — what’s different from when the plan was set?

Priority adjustments (20 min): Based on the above, what — if anything — should change in the next quarter’s priorities? This should result in at least one explicit decision, even if the decision is to stay the course.

Close (10 min): Assign owners to any actions arising. Every action needs a person and a date — not a team, not “we.”

What Makes It Drive Change

The difference between a review that drives change and one that doesn’t is the willingness to surface and act on uncomfortable truths. That requires psychological safety — leaders who won’t penalise honesty about what’s not working — and structural mechanisms that force the conversation, like the written pre-work and the strategic assumptions review.

COOs who run reviews this way consistently report better strategic adaptation and better team engagement. The format is not complicated. The discipline required to maintain it is.

Busyness is not the same as progress. Teams can be genuinely stretched, consistently delivering work, and still spending most of their time on things that don’t meaningfully advance the company’s strategic priorities. The question “are we working on the right things?” is one of the hardest for a COO to answer — and one of the most important.

Here are five diagnostic approaches.

1. Do a Strategic Theme Audit

List all the active projects and initiatives in your portfolio. For each one, ask: which strategic theme does this serve? If you can’t answer that question, the project may be valuable — but it’s not connected to strategy. A theme audit will typically reveal that 20–30% of active work is either disconnected from strategic priorities or connected to priorities that have since changed.

2. Measure the “Urgent vs Important” Split

Track what percentage of team capacity is consumed by urgent reactive work (support escalations, production bugs, ad hoc requests) versus planned strategic work. If urgent work consistently consumes more than 25–30% of capacity, your teams are in a reactive mode that structurally prevents strategic progress.

3. Check Your Senior Talent’s Allocation

Your senior people should be disproportionately allocated to strategic priorities. If your most experienced team members are primarily solving operational fires, you have an inversion — your strategic engines are under-powered.

4. Ask “What Would We Stop If We Had Less?”

This counterfactual is a useful prioritisation tool. If the company had 20% less capacity next quarter, what would you stop? Whatever survives that cut is your strategic core. Everything that would get cut first is probably not a strategic priority — and yet it’s consuming capacity now.

5. Review the Last Three Quarters of Delivery

Look at what your teams actually delivered over the last three quarters. Map each delivered item to a strategic theme. Where is there delivery concentration? Where are there gaps? If you spent six months shipping features but your strategic priority was “reduce operational complexity,” the delivery-strategy connection has broken down.

Every COO manages two types of numbers. Strategic objectives tell you where you’re going — they’re directional, longer-term, and tied to the company’s competitive ambition. Operational metrics tell you how healthy the machine is right now — throughput, quality, reliability, team utilisation.

Both matter. The mistake is treating them as the same thing.

Why Conflating Them Causes Problems

When operational metrics become strategic objectives, you optimise the wrong things. A company that sets “achieve 99.9% uptime” as a strategic objective hasn’t got a strategy problem — it’s got an operational baseline problem. Uptime is table stakes, not differentiation.

When strategic objectives are measured with operational metrics, you lose signal. “Increase customer satisfaction” measured by support ticket volume tells you something about operational health but nothing about strategic progress. You need both, tracked separately.

The Two-Layer Dashboard

Sophisticated COOs maintain two distinct measurement layers:

The strategic dashboard tracks OKR progress, strategic theme advancement, and outcome metrics — things like market share, NPS trend, enterprise ARR, product adoption rate. Reviewed quarterly, with monthly check-ins.

The operational dashboard tracks throughput, quality, reliability, and team health — things like delivery predictability, defect rates, capacity utilisation, team satisfaction. Reviewed weekly.

The two dashboards occasionally overlap — a customer satisfaction metric might appear in both. That’s fine. What matters is that they serve different decisions: strategic dashboards inform investment and direction; operational dashboards inform intervention and adjustment.

Telling the Story to the Board

One practical implication of this distinction: your board reporting should lean heavily on the strategic dashboard. Boards need to understand strategic progress, not operational detail. “We achieved 85% on-time delivery this quarter” is an operational metric. “We reduced enterprise customer churn by 12% against a target of 10%” is a strategic result.

The COO’s communication skill — translating operational reality into strategic narrative — is what distinguishes good board reporting from confusing data dumps.

Cascading OKRs — translating company-level objectives into team-level and individual-level goals — is one of the most challenging operational design problems a COO faces. Done well, it creates alignment without rigidity. Done poorly, it creates bureaucracy without accountability.

The Cascade Architecture

Think of OKR cascade as a tree, not a chain. Company objectives sit at the root. Team objectives branch from them. Individual objectives branch from team objectives. Each level should be able to answer: “How does my goal contribute to the one above it?”

The key mistake is trying to make the cascade too tight — insisting that every team’s OKRs map one-for-one to company OKRs. Most teams have legitimate operational objectives that are necessary to support the strategy but don’t map to a single company OKR. Platform reliability, team development, process improvements — these matter, but they don’t always have a clean OKR parent.

Aim for directional alignment, not structural perfection.

Setting the Rhythm

Cascading OKRs requires a sequenced planning process:

1. Company OKRs set by CEO/leadership: Weeks 1–2 of the quarter before
2. Team OKRs drafted: Weeks 3–4 (bottom-up, informed by company OKRs)
3. Alignment review: Week 4–5 (COO reviews team OKRs for gaps and conflicts)
4. Final sign-off: Week 6 (before the quarter begins)

This timeline is tighter than most organisations allow, which is why it must be explicitly scheduled, not assumed.

The COO’s Role in the Cascade

The COO’s job in an OKR cascade is not to write the team’s OKRs — it’s to ensure the cascade is coherent. That means:

• Identifying gaps: Which company objectives have no team-level work mapped to them?
• Identifying conflicts: Are two teams optimising for goals that are in tension?
• Identifying overload: Have teams committed to more key results than is achievable?

These three reviews should be the COO’s primary output from the cascade planning process.

Making It Stick

The most common failure mode is setting OKRs and then not revisiting them until the end-of-quarter review. Cascaded OKRs require monthly check-ins — not full reviews, but fifteen-minute updates: what’s progressing, what’s stalling, what needs leadership attention?

Teams that check in monthly on their OKRs deliver significantly better results than those that don’t. The check-in is not overhead — it’s the mechanism by which the cascade stays connected to reality.

Strategy documents are aspirational. Sprint backlogs are operational. The gap between them — the execution gap — is where most company strategies quietly die.

Closing that gap requires more than good intentions. It requires structural mechanisms that make the connection between strategic intent and daily work explicit, visible, and maintained over time.

Step 1: Define Your Strategic Themes

Start with the company’s strategic objectives for the year. Under each objective, define two to five strategic themes — the major focus areas that need to progress for the objective to be achieved.

Themes should be specific enough to guide prioritisation but broad enough to encompass multiple initiatives. “Improve enterprise reliability” is a theme. “Fix the database timeout bug” is not. “Increase annual contract value” is a theme. “Train the sales team” is a tactic.

Step 2: Tag Every Initiative

Every significant project, initiative, or epic in your portfolio should be tagged to one primary strategic theme. This tagging is simple but powerful — it makes the portfolio-strategy connection explicit.

When the CEO asks “what are we doing to improve enterprise reliability?”, the answer should come from a filtered view of tagged work, not from a manually assembled slide.

Step 3: Review at the Theme Level

In your monthly or quarterly operations reviews, review progress by theme rather than project by project. “How are we progressing against Enterprise Reliability?” surfaces all the relevant initiatives together and gives leadership a coherent view of momentum — or lack of it.

Step 4: Use Metrics to Track Theme Progress

Each theme should have one to three metrics that measure whether progress is real. Issue count is a weak metric — it tells you how much work is being done, not whether the theme is advancing. Better metrics are outcome-based: customer satisfaction score, on-time delivery rate, enterprise ARR.

These metrics should be tracked in real time, not manually aggregated quarterly.

Step 5: Connect Individual Tasks to the Strategy

The final step is making the connection visible at the individual task level. When a developer opens a task, they should be able to see which theme it contributes to and why it matters. This isn’t motivational fluff — it’s the information teams need to make good micro-decisions about priority and trade-offs.

OKRs were supposed to fix the strategy-execution gap. And for a small number of organisations — typically those that implemented them carefully, with significant leadership investment — they have. For most, they’ve become another layer of overhead: goals that get set in January, reviewed perfunctorily in April, and largely ignored by the time Q3 arrives.

The problem is almost never the OKR methodology itself. It’s the gap between where OKRs live and where work happens.

The Layers Problem

In a typical organisation, OKRs exist at three levels: company, team, and individual. Each level is supposed to cascade from the one above. In practice, each level is often set relatively independently, with loose alignment that looks connected in a slide deck but doesn’t hold up under operational scrutiny.

The company sets an OKR: “Achieve market leadership in enterprise by Q4.” The product team sets an OKR: “Ship three enterprise features.” The individual engineer’s sprint backlog contains: seventeen bugs, a refactor, and one enterprise feature that’s blocked on design.

The cascade has broken. But nobody can see it, because OKRs live in one tool and work lives in another.

Why the Measurement Gap Is Fatal

OKRs require leading indicators to be useful. You need to know whether you’re making progress toward the key result before the quarter ends — not in the final review. But most organisations measure OKR progress manually, quarterly, in a presentation. By the time you know you’re off track, it’s too late to correct.

The solution is connecting OKR metrics to real-time operational data. If your key result is “increase on-time delivery rate to 85%,” your tracking should pull from actual delivery data, not from a number someone manually enters into a spreadsheet each month.

The Ownership Problem

OKRs also fail when ownership is fuzzy. A key result owned by “the engineering team” is owned by nobody. Effective OKRs have a named owner — a single person who is accountable for the result, even if the work is distributed across multiple teams.

Without clear ownership, OKRs become shared aspirations rather than accountable commitments — and shared aspirations tend to stay aspired to rather than achieved.

How to Fix It

1. Connect OKRs to operational data. Every key result should be measurable from data that already exists in your systems. If you can’t measure it without a monthly survey, you probably haven’t defined it specifically enough.

2. Assign issues and projects to themes. Every significant piece of work should be traceable to a strategic objective or theme. This creates a visible link between what teams are building and what the company is trying to achieve.

3. Review at the right cadence. OKR check-ins should be monthly at minimum, weekly for critical key results. Quarterly reviews are post-mortems, not management tools.

4. Make the connection visible to teams. Developers and designers who understand why their work matters to the company’s strategic priorities are significantly more motivated than those who don’t. The connection between a sprint task and a company objective should be one click, not a paragraph of explanation.