Most advice about red amber green gets the job wrong.
It treats RAG as a reporting shortcut. A tidy colour in a dashboard. A quick way to reassure the board that things are broadly fine. That's exactly why so many OKR systems collapse into theatre. Teams learn which colour is politically safe. Leaders get a simplified view of progress. Nobody gets a reliable execution mechanism.
The problem isn't the colours. It's the passivity.
If your RAG model only tells you what happened, it's too late. If it depends on manager judgement, it's easy to game. If a Red item doesn't trigger a concrete response with a named owner, date, and decision, then your dashboard is decoration.
The better approach is blunt. Define RAG with objective thresholds. Review it on a fixed cadence. Separate whether work shipped from whether it worked. Treat every Red or Amber signal as an operational trigger, not a status label. That's how leadership teams close the gap between strategy and execution.
Defining RAG Thresholds That Drive Action
Set the thresholds before the quarter starts, or your RAG system will collapse into opinion.
The failure pattern is predictable. A Key Result slips, the owner calls it Amber to avoid escalation, and leadership wastes time debating the colour instead of fixing the problem. If you want RAG to drive execution, tie it to objective progress against a planned trajectory. Do not tie it to confidence, effort, or how persuasive the update sounds.
A practical model is simple:
- Green means the Key Result is tracking against its expected path.
- Amber means the Key Result has drifted enough to require corrective action.
- Red means the Key Result is materially off track and needs escalation or a reset.
Use this visual as the operating baseline:
Stop rewarding safe targets
If Green means 100% completion, you are training teams to sandbag.
In OKRs, Green should represent strong progress against a stretch target. Once leaders equate Green with perfect attainment, teams respond rationally. They lower ambition, write safer Key Results, and protect their status instead of pursuing meaningful outcomes. The dashboard improves. Execution quality does not.
Use a threshold range that reflects ambition and trajectory, then score consistently. If your team needs a cleaner method, use a standard OKR scoring model and document exactly how Green, Amber, and Red map to progress at each point in the quarter.
Practical rule: Green signals credible momentum on a stretch goal. It does not mean the work is finished.
Use one scoring language across the business
Every function should be able to read the same colour the same way. Product, sales, operations, and executive teams do not need custom definitions. They need a common operating language.
A simple version looks like this:
| Status | KR progress signal | Leadership meaning |
|---|---|---|
| Green | Strong progress and still on expected path | Stay the course |
| Amber | Progress is slipping and needs correction | Intervene early |
| Red | Outcome is materially off track | Escalate and replan |
The exact tolerance can vary by metric. The rule cannot. If one team marks minor variance as Amber and another hides major underperformance in Green, leadership loses the ability to compare risk, direct support, and make trade-offs across the portfolio.
Make the trigger explicit
Colour alone is useless. The action attached to the colour is what makes RAG work.
Define the response in advance. Green means continue with the current plan. Amber means the owner brings a recovery move, with dates, dependencies, and support needed. Red means a leadership decision: reallocate resources, remove blockers, change scope, or accept that the KR will miss and replan accordingly.
This approach turns red amber green into an execution mechanism. It also sets up the next distinction leaders need to make properly: delivery RAG asks whether the work shipped, while performance RAG asks whether it produced the result.
Building Your OKR Governance Cadence
RAG fails in companies that treat it as a dashboard. It works in companies that treat it as a management system.
The cadence is the mechanism. Without a fixed review rhythm, Amber sits too long, Red arrives too late, and Green gets reported without scrutiny. Review OKRs every two weeks. That interval is short enough to correct course before a quarter is lost, and long enough for real movement to show up in the data.
What the meeting is for
Use the meeting to make decisions, clear blockers, and force trade-offs. Do not use it to read out status updates that already exist in the tracker.
A good cadence meeting focuses on four things: movement since the last review, current risk, dependencies that could stall progress, and actions due before the next check-in. If every KR is Green, finish quickly. If several are Amber or Red, spend the time where intervention will change the outcome.
Keep attendance tight:
- Objective owners who carry outcome accountability
- Key Result owners for any item in Amber or Red
- Cross-functional leads for dependencies and shared commitments
- A decision-maker who can resolve conflicts, shift resources, or reset scope
A practical 30-minute agenda
Run the same agenda every time. A consistent agenda is more effective than a creative one.
-
Pre-read submitted before the meeting
Teams update KR scores, current RAG status, movement since the last review, and the next material risk. Keep it brief and written in plain language. -
Green items checked fast
Confirm that progress is still real. Then move on. -
Amber items handled as recovery discussions
Ask what slipped, what changes now, who owns the fix, and when the next proof point will appear. -
Red items handled as leadership decisions
Identify the blocker, the consequence, the owner, and the intervention. If no decision gets made, the meeting has failed. -
Cross-team conflicts surfaced explicitly
Delivery usually slows down at the seams between teams, not inside a single team. Peer-team alignment conversations must be built directly into the OKR planning and review calendar to catch those conflicts before they become quarter-end surprises, as outlined in this guidance on OKR planning.
One more rule. Separate the question of whether work shipped from the question of whether it produced the result. A feature can be Green on delivery and Amber on performance. If your cadence blends those into one discussion, accountability gets muddy fast.
The best cadence meetings feel slightly uncomfortable. That usually means real risk is being surfaced early enough to act on.
What to ban from the room
Bad governance is easy to spot. It sounds busy and achieves very little.
Ban these habits:
- Slide decks that repeat what the tracker already shows
- Round-robin updates from every team regardless of risk
- Amber and Red items with no recorded owner action
- Late data updates that force people to rely on memory
- Status debates with no decision, escalation, or next step
If leadership needs a model for the rhythm itself, use this guide to meeting cadence for OKR execution before rollout.
A good cadence turns RAG from reporting into execution pressure. That is the standard.
A Leadership Playbook for RAG Conversations
Most leaders make RAG worse.
They say they want transparency, then react badly when a team reports Red. They ask, “Why is this off track?” in a tone that sounds like prosecution. Teams learn quickly. Amber becomes the safe colour. Green becomes the aspirational fiction.
A Red status should trigger support, not blame.
What leaders should ask instead
The quality of the conversation determines the quality of the data. If leaders punish honesty, they'll get polished nonsense.
Use questions that move the team towards action:
| Status | Bad leadership question | Better leadership question |
|---|---|---|
| Red | Why has this failed? | What's the bottleneck, and what support do you need now? |
| Amber | Are you sure this is a problem? | What needs to happen to get this back on track before the next review? |
| Green | Great, anything else? | What's working that we can repeat elsewhere? |
This shift matters because status is not the point. The next move is the point.
Red needs diagnosis and intervention
When a Key Result turns Red, leaders should stop asking for reassurance. Ask for precision.
What has changed since the last review? Is the issue capacity, dependency, decision delay, or flawed strategy? Who owns recovery? What can leadership remove today?
That approach creates psychological safety without lowering standards. Teams still need accountability, but accountability means owning reality and driving action, not pretending a weak quarter is still “manageable”.
Leader's script: “Don't defend the colour. Tell me what changed, what's blocked, and what you need from us.”
Amber is where execution is saved
Amber items deserve more attention than many executive teams give them. This is the recovery zone. If the organisation responds quickly, the objective can still finish strongly. If it drifts for another cycle, it usually becomes a leadership problem.
Ask for a short recovery plan, not a long explanation:
- What is the specific risk?
- What action will happen before the next check-in?
- Which dependency could stop that action?
- Who owns the fix?
That's also where ownership needs to be explicit. If no one person is carrying the Key Result, progress stalls in committee. This is why strong OKR accountability matters more than motivational language or better templates.
Green still needs scrutiny
Green is not a free pass. A healthy RAG review asks whether the result is on track or merely reporting progress on activity. Leaders should use Green items to identify repeatable practices, sharpen forecasting, and spot where one team has solved a problem that another team is still wrestling with.
Good RAG conversations don't make the room more comfortable. They make execution more honest. That's a better trade.
Common RAG Anti-Patterns and How to Fix Them
Most RAG dashboards lie.
Not because the data platform is broken. Because people are. Teams protect themselves. Managers avoid escalation. Leaders reward certainty. The result is a dashboard full of colours that look tidy and tell you almost nothing useful.
The two biggest failures are RAG masking and Greenwashing.
RAG masking
RAG masking happens when teams label a problem Amber because Red feels too risky. It's the corporate version of saying, “We're monitoring the situation,” when everyone knows the situation has already gone bad.
Data from UK PMOs shows that 34% of Amber flagged projects are Red in reality, and this kind of masking leads to a 50% increase in unexpected delivery failures because leaders don't intervene with enough urgency, according to Wellingtone's analysis of Microsoft OKRs and governance pitfalls.
The fix isn't motivational posters about honesty. It's governance.
- Define objective thresholds so managers can't argue from mood.
- Require one named owner for every Key Result before the cycle starts.
- Ask for actions and dates on every Amber and Red item.
- Reward early escalation instead of treating it as personal failure.
Greenwashing
Greenwashing is different. The initiative shipped. The team completed the work. The project tracker says Green. But the business outcome hasn't moved.
Leadership teams fall for this constantly. They celebrate launch milestones, feature releases, campaign go-lives, and process completions while the KPI that justified the work remains weak. That's not execution success. It's administrative success.
If the outcome hasn't moved, Green on activity is often just expensive noise.
The hidden cultural issue
A weak RAG model usually points to a cultural problem, not a tooling problem. Teams don't trust that candour will be met with support. Leaders don't want to hear bad news until it's unavoidable. Functions optimise their own scorecard instead of the company objective.
You can see this when every team is “mostly Green” and delivery still feels slow, conflicted, and messy. The status model isn't helping because it has become performative.
A useful reset looks like this:
| Anti-pattern | What it looks like | What to change |
|---|---|---|
| Amber by default | Teams avoid escalation | Tight thresholds and explicit triggers |
| Activity reported as success | Work completed, impact unclear | Tie status to outcomes, not outputs |
| Shared ownership | Everyone contributes, nobody owns | Assign one accountable owner per KR |
| Late escalation | Problems surface after the window to fix them | Review on a bi-weekly cadence |
If your organisation recognises itself in this list, it's worth reviewing these common OKR mistakes before you redesign the dashboard. Most RAG issues begin upstream in goal design, ownership, and review discipline.
Separating Delivery RAG from Performance RAG
Most OKR systems get exposed here.
A team launches the feature. The campaign goes live. The training rolls out. Everyone marks the work Green because the plan was executed. Then the outcome misses. Adoption is flat. Conversion doesn't move. Retention stays weak. The KPI remains stubbornly Red.
That happens because organisations blend two different questions into one status.
Two statuses, two truths
You need delivery RAG and performance RAG.
Delivery RAG answers a narrow operational question. Did we do the thing we said we would do?
Performance RAG answers the strategic question that leadership cares about. Did it produce the result we needed?
A critical and often missed distinction is separating these two tracks. 4 out of 5 UK organisations fail to distinguish them, which leads them to celebrate Green project completion while business KPIs remain Red.
What this looks like in practice
Take a common scale-up scenario.
The product team commits to launching a new onboarding flow. The work ships on time. Delivery RAG is Green. But the activation metric doesn't improve. Performance RAG is Red. If you only track one colour, leadership gets a false signal that the initiative succeeded.
The same happens in commercial teams:
- Marketing launches a campaign on schedule. Delivery Green. Pipeline quality weak. Performance Red.
- Operations implements a new process. Delivery Green. Cycle time unchanged. Performance Red.
- People teams complete manager training. Delivery Green. Manager effectiveness still inconsistent. Performance Red.
This is not semantics. It changes how leaders respond.
Different triggers for different reds
When delivery RAG turns Red, the response is operational. Remove blockers. reset sequencing. add support. fix dependencies.
When performance RAG turns Red, the response is strategic. Revisit the hypothesis. challenge the metric. test whether the initiative was ever likely to move the outcome.
That separation stops teams from being punished for the wrong issue. A team may have executed well against a poor assumption. Or the strategy may be sound, but delivery quality may be weak. If both sit under one colour, the diagnosis gets blurred and the wrong people get blamed.
One status tells you whether work happened. The other tells you whether the work mattered.
For leaders trying to design this properly, this guide on how to measure delivery and performance separately is a practical next step.
If you want red amber green to improve decision-making, this split is not optional. It is the difference between reporting motion and managing results.
From Reporting to Execution Making RAG Stick
Most OKR programmes don't fail because leaders dislike goals. They fail because the system never becomes operational.
Research indicates that 73% of organisations abandon OKRs within the first quarter because they fail to create specific and measurable outcomes, turning ambition into untrackable activity rather than measurable business impact, as highlighted in this OKR adoption insight.
That's the lesson for red amber green. The colours only work when the mechanics work.
What has to change
A workable RAG model has a few critical components:
- Objective thresholds so status reflects evidence, not confidence
- A fixed bi-weekly rhythm so issues surface while there's still time to act
- Leadership behaviours that treat Red as a trigger for support
- Separate delivery and performance views so execution doesn't hide weak outcomes
If you're using digital workflows or automation to support this cadence, it also helps to connect AI agents to tools that can pull updates, route actions, and reduce admin around status collection. The point isn't automation for its own sake. It's freeing leadership time for decisions instead of chasing inputs.
Better RAG creates better execution
This isn't about building prettier dashboards. It's about changing what happens when a signal appears.
A good RAG model shortens response time. It sharpens ownership. It exposes cross-team friction early. It stops leadership teams from mistaking activity for progress. Most of all, it forces strategy into the operating rhythm of the business.
If your current red amber green process feels polite, slow, or strangely optimistic, it probably isn't working. A functioning system creates clarity. Sometimes discomfort. Always action.
If your leadership team has clear strategy but patchy execution, The OKR Hub can help you build the operating rhythm, governance, and accountability needed to make OKRs work in practice.