Your leadership team has agreed the priorities. Yet the reporting stays, the meetings stay, and every new initiative lands on people who were already fully committed. The strategy changes. The working week doesn't.
I would use an eliminate reduce raise create grid to force a harder conversation: what will stop, who can authorise that decision, and where will the released capacity go? The useful output isn't a balanced set of boxes. It's a set of choices that leaders can fund, assign and turn into measurable OKRs.
What a Usable Grid Looks Like on One Page
Start with a single page. The header names the customer or stakeholder outcome, the current baseline, the decision date and the accountable executive. Without that header, people will classify activities against different ideas of value.
The body contains the four quadrants. I recommend no more than seven items in each, with an owner and a piece of evidence beside every item. That's a facilitation limit, not a target to fill.
Grid template: the question and evidence for each quadrant
| Quadrant | Question to answer | Scale-up example | Evidence to gather |
|---|---|---|---|
| Eliminate | Which work adds no value to the customer outcome? | Monthly steering pack nobody uses in decisions | Usage logs, owner interviews, decision trail |
| Reduce | Which work is over-specified or costs more than it returns? | Weekly status meeting running 90 minutes | Hours per cycle, cost-to-serve, cycle time |
| Raise | Which capability is underprovided but critical to the outcome? | Client onboarding support answering in five days | Response times, customer scores, error rates |
| Create | Which new source of value can be tested cheaply? | Self-serve reporting module for existing clients | Demand signal, pilot sign-ups, willingness to pay |
The examples are hypothetical. The distinction matters: Eliminate removes work; Reduce changes its intensity or specification; Raise improves an existing capability; Create tests something genuinely new.
Classify the work, not the proposed solution
Consider a hypothetical 140-person UK property services firm. Its first draft puts a monthly steering pack in Create because someone has proposed a new dashboard. That describes a technology proposal, not a source of customer value.
Checking the decision trail reveals that the pack already exists and nobody uses it to make decisions. The existing pack belongs in Eliminate. Whether a different information service deserves investment is a separate question, requiring separate evidence.
An item sits in one quadrant only. If people place client reporting in both Reduce and Create, break it into specific factors: manual report preparation and client access to live information, for example.
Practical rule: Classify the factor being changed, not the enthusiasm attached to someone's preferred solution.
Keep the evidence proportionate. A usage log, a sample of customer requests and a clear preparation-time estimate are more useful than a polished presentation full of assumptions. Record uncertainty openly rather than treating a confident opinion as a baseline.
I would build the first page from this table in a 20-minute preparation exercise. Bring the evidence to the session, not a completed grid that colleagues are expected to endorse.
How to Run the Grid Workshop Step by Step
Invite the executives who can make trade-offs and the people who understand the work. I recommend a room of eight to twelve people, with an external or non-owning facilitator who doesn't need a particular initiative to survive.
As a working agenda, allow about 90 minutes for the grid and another 30 for the release test. These are suggested timeboxes. If the evidence is missing, extending the debate won't make the decision stronger.
Prepare decisions rather than presentations
-
Send an evidence pack a week ahead. Include cost, hours, usage and customer evidence for every candidate so people arrive ready to challenge assumptions. Keep each candidate to a page and mark estimates clearly.
-
Agree the outcome before listing activities. State the result the workshop must protect, such as reliable client onboarding without avoidable hand-offs. Ask participants to explain what would count as deterioration before discussing savings.
-
Run a silent first round. I suggest asking each participant for 15 to 25 factors on separate cards, then clustering duplicates. Silent writing prevents the most senior person from defining the whole conversation; insist on concrete factors rather than labels such as operational excellence.
-
Place each factor by vote. Use the quadrant questions, then move split decisions to a parking board for evidence. A vote exposes disagreement, but it doesn't establish whether a contractual obligation exists.
-
Run the release test. For every Eliminate and Reduce decision, name the hours or spend released and who controls it. Ask the receiving manager to confirm that the proposed Raise or Create work can actually use that resource.
-
Write a measurable hypothesis. Record an owner, baseline, target, cost, risk and review date for each surviving decision. Make the causal claim explicit: changing this factor should improve that outcome because of this evidence.
-
Agree the review cadence before leaving. Put decision reviews into existing leadership meetings wherever possible. Assign responsibility for bringing evidence, not merely reporting activity.
The process diagram provides a compact facilitation aid, including the scoring discussion that supports placement.
Resolve disagreement at the right level
Distinguish disagreement about the outcome from disagreement about the mechanism. A sales director may want bespoke reporting because clients value reassurance. An operations director may oppose it because preparation delays service delivery. Both concerns can be valid.
Test the underlying requirement. Do clients need a bespoke document, or timely confirmation that someone is handling exceptions? The answer might justify eliminating document production while raising exception handling, with different owners and measures.
When leaders disagree about the result itself, I would pause classification and use a goal alignment workshop to settle the competing commitments. Otherwise, the facilitator is trying to resolve a strategic conflict through card placement.
Don't use aggregate scores to conceal a serious risk. A candidate can look attractive on cost, quality and adoption while still failing an essential operational control. Record that constraint and assign someone to resolve it.
The single output leaving the room should be a signed decision list. It names the accountable executive, the action owner and any conditions that must be satisfied. A photograph of the wall records participation, not commitment.
Making Elimination Stick Beyond the Workshop
Elimination usually fails because leaders treat it as a workshop prompt rather than a governance decision. People agree that something should disappear without answering who has authority to stop it.
Standing meetings, recurring reports, approval steps and unused metrics all have sponsors. Legacy commitments can also belong to a client or board member. The person doing the work may have no authority to withdraw it.
Remove the mechanisms that recreate the work
Consider a hypothetical monthly board pack. The finance director keeps it alive for one more quarter, and it returns three times within a year without anyone announcing it. Nobody has reversed the elimination formally, but everyone is still producing the pack.
The fix isn't another reminder. Remove the calendar request, retire the template and tell recipients where essential information will come from instead. Give the finance director responsibility for agreeing that replacement with the board.
Record the decision with:
- Authority and ownership: Who approves the stop, and who implements it.
- Affected teams: Who produces, receives or depends on the output.
- Risk and transition: What could go wrong, the safeguards and the transition date.
- Operating change: Which OKR, meeting or decision process replaces the old arrangement.
At that point, strategic trade-offs become operational. Leaders must accept what they will no longer receive, not just approve somebody else's efficiency target.
Stopping production while leaving the request mechanism intact is a temporary pause, not elimination.
Watch the routes back in
The first reversal route is executive exception. Someone asks for the old pack just this once. Require the sponsor to explain the new decision need and approve the capacity cost before production resumes.
The second is shadow work. Middle managers rebuild the report in Excel because they don't trust the replacement. Search shared folders and ask preparers directly what they're still compiling.
The third is compliance anxiety. Get the compliance owner to confirm in writing which obligations remain, including retention requirements. Eliminating report production doesn't automatically mean deleting its records.
Where templates, guidance and published documents must change together, TheContentMap's steps for managing content changes provide useful context for controlling that transition. Apply the same discipline to internal reporting instructions.
I recommend a 60-day reversal check for this scenario. Put it in the diary before announcing the elimination, with someone responsible for checking whether the work has reappeared.
Checking Capacity Before You Raise or Create
Raise and Create sound positive. That is the blind spot. Every new capability, service promise or metric can add training, dependencies, decision load and recurring operational work.
Employees are often already stretched, so a leadership team should not assume motivated people can absorb another commitment. Treat each Raise or Create choice as a governance decision: it only proceeds when subtraction has released specific capacity and leaders have protected that capacity for the new work.
I would require each proposed investment to pass these tests before it starts.
Capacity tests before raising or creating
| Capacity test | Question to ask | Pass signal | If it fails |
|---|---|---|---|
| Released capacity | Which eliminate or reduce item frees the people or budget this needs? | Named hours or spend freed before work starts | Defer the raise or create item |
| Scarce skill | Who has this capability, and are they already on critical work? | Named owner with protected time in the plan | Train first or run a smaller pilot |
| Dependencies | What else must change before this works? | Each dependency listed with a date and owner | Sequence this after the blocking item |
| Kill criteria | What result ends this bet, and when does the review happen? | Written threshold and review date | Don't start; a bet without an exit is a commitment |
Check whether capacity is transferable
Released time is not automatically usable capacity. Removing administration from account managers does not produce software engineering capacity. A finance saving also will not resolve a bottleneck in a specialist's calendar unless leaders can use it to obtain the required capability.
Say a team wants to create a self-service reporting module. Stopping manual slides may release account-management time, but the module still needs product design, engineering, security review and support ownership. Name those demands before promising a launch. If the freed hours belong to people who cannot do that work, the grid has produced a paper saving rather than delivery capacity.
Use capacity planning methods to check availability by role and dependency instead of balancing a company-wide total. Protect the required time in the delivery plan and remove conflicting assignments.
Make creation reversible
Treat Create as a staged experiment. Test demand with a manual service, prototype or limited pilot before committing to permanent staffing and support.
Write the continuation threshold and review date before spending begins. Include the ongoing cost of running the capability, not only the cost of building it. Positive pilot feedback is insufficient when nobody adopts the offer or the service economics do not work.
Capacity warning: If the backlog grows after planning and nothing leaves it, leaders have added work rather than made strategic choices.
At the quarterly capacity check, compare protected hours and budget with the demands placed on the same teams. Cut or defer the lowest-value item until the commitments fit. Don't close the gap with an assumption that people will work harder.
Turning Quadrant Choices Into Measurable OKRs
From quadrant to OKR shape
| Quadrant | Objective shape | Key result shape | Watch for |
|---|---|---|---|
| Eliminate | Free capacity by stopping [activity] without harming [outcome] | Hours or spend released, and outcome held at or above baseline | Stopping with no guardrail on the outcome |
| Reduce | Deliver [outcome] at lower cost or effort | Cost per unit or cycle time down, quality threshold held | Cuts that push quality below the floor |
| Raise | Lift [capability] to [standard] | Score, rate or cycle time moved to a named target | Vague improve wording with no baseline |
| Create | Prove [new offer or capability] works for [customer] | Adoption, paying users or revenue from pilot by a set date | Treating a wish as a committed programme |
The objective describes the business change. The key results establish whether it happened and whether the outcome justified the effort. Tasks belong in the delivery plan beneath them.
I wouldn't create an objective for every card. Group related choices around the outcome they jointly support, while keeping ownership of the underlying decisions clear.
Work from the grid to the evidence
Consider this hypothetical grid decision: reduce the effort behind monthly reporting. The underlying problem is that leaders receive competing versions of performance and analysts spend too much time reconciling them.
Objective: Run the business from one trusted weekly view.
For this illustrative example, the key results could be:
- Preparation effort: Reporting preparation falls from 28 hours a week to 10 by the end of Q3.
- Report retirement: Nine standing reports fall to four, with required controls retained.
- Decision use: Three of five leadership team members identify the weekly view as the source for at least one recorded decision during the review period.
These are example baselines and targets, not benchmarks. Replace them with measured starting points and thresholds that reflect the organisation's economics.
The report count alone is insufficient. Leaders could retire documents while shifting preparation into spreadsheets or private slide decks. The effort measure detects that displacement; the decision-use measure tests whether the replacement is useful.
The relationship between the grid and the objective should remain visible on the planning page.
Keep delivery plans separate from success measures
Build dashboard, interview clients and configure workflow are actions. They can all finish without producing a useful outcome. My approach to writing measurable outcomes is to ask what observable change would justify the work.
For product-related Create decisions, Figr's guide to building a product roadmap is useful context for sequencing delivery. Keep the roadmap connected to the hypothesis, but don't mistake shipped features for evidence that customers value them.
I recommend no more than three objectives per team in a quarter. That's a focus constraint, not a universal benchmark. If leaders can't fit the priorities within it, they need to resolve the choices rather than hide more work inside broad wording.
Every Create item needs a kill date written into its key result. Every Eliminate item needs evidence both that the work stopped and that the protected outcome held at baseline.
A good OKR can fail visibly in week six. If the team can stay green by completing tasks while effort, adoption or customer outcomes remain unchanged, rewrite it.
Confirm the Grid Survives the Next Planning Cycle
Start in week one with a baseline sheet covering financial cost, cycle time, quality, adoption, customer outcome and operational risk. Record the starting position before changing the work.
The Strategy Execution 2025 survey found that only 18.4% of 250 internationally active UK companies with turnover above £20 million achieved more than 80% of their aspirational growth goals within three years. Agreeing priorities isn't proof of delivery.
Check readiness before action
- Elimination: A named owner and transition date.
- Capacity: Released hours or spend recorded.
- Creation: A kill date and continuation threshold.
- Measurement: Every baseline recorded.
- Reversal: The 60-day check booked.
In weeks two to four, I recommend piloting a subtraction and redirecting the released resource into a selected capability. Protect compliance, service reliability and employee safety; review leading indicators weekly and outcomes monthly.
Connect OKR planning to changing financial assumptions. Jumpstart Partners on rolling forecasts offers useful context for keeping resource decisions current.
The Mid-cycle Review & Reset is a half-day session for teams 6–8 weeks into an OKR cycle. Its outputs are an OKR health assessment, agreed priority adjustments and blocker resolution actions.
Success means fewer low-value activities, lower avoidable cost, better chosen outcomes and a new capability with validated adoption, not four filled boxes.
I help leadership teams turn grid choices into executable OKRs, with clear accountability and capacity behind the priorities. If your next planning round already contains more commitments than people can deliver, book a conversation.