Has anyone used a three-tier OKR structure (Goals→Ideas→Work) instead of linking OKRs/Work directly?

[Ted Henry]

In most demos I’ve seen, Work is directly linked to Goals. However, many of the clients I speak with don’t have mature processes, and this approach comes with risks:

• Delivery tickets often lack broad context. Unless teams write summaries/descriptions with a wider audience in mind (which is rare in my experience), key strategic context can get lost.
• Alignment and evaluation become harder. Different teams work in different ways, making progress evaluation across an organization unreliable/inconsistent.
• Reporting is less reliable.  Virtually every dashboard I see has a %-complete box based on "work done" which for my clients would basically never be accurate.

An Alternative Approach: Goals → Ideas → Work

For enterprises that need more structure—or frequently need to answer “Why are we doing this?”—another model could introduce an intermediate layer between Goals and Work:

• Goals (Outcomes) → Define what success looks like.
  • Ideas (Options/Intent) → Possible ways to achieve the goal.
    • Work (Execution/Delivery) → Tasks and stories that fulfill an idea.

Why?

• Clearer Strategic Intent – A concise way to express how you intend to achieve a goal, in what order, and over what timeframe.
• Dual Evaluation – Separately assess:
  • Did our Ideas help us achieve our Goals?
  • Did our Work effectively deliver on our Ideas?
• Better Traceability – Work items often don’t directly relate to outcomes. Instead, work items fulfill an intent (or just a part of it), while its the fulfilled intent that achieves the outcome.
• Better bottom-up alignment - Surfacing work through Ideas that embody intents makes it easier for non-technical stakeholders to understand progress, even if ticket descriptions vary across teams or are highly technical or both.

Has anyone tried this or something like it?  Would love to hear how others approach this!

[Sara Beyer]

I've been using this structure - similar to what you're describing:

Goals → Epics → Work

• Goals → Owned by exec members. Something we want to achieve in the org and the key results that define what success looks like are in the description. Pretty broad.
  • Sub-Goal → These are owned by senior leadership members. These are more specific ways of how we will help the org arrive at X.
    • Epics → Smaller chunks ways to achieve the BU level goal. On Epics, I have the Goals field visible so all teams can see how the work they're doing rolls up.
      • Work → Tasks and stories that help to achieve an Epic.

For us, this has been working very well. Goals get updated quarterly. Sub-goal (just the one level) gets updated monthly. Then, I've created different views using the #tags so that the updates can be easily consumed. Additionally, I have a plan created that shows all the Epics in the org that have a Goal attached so we can easily see all work across the org that rolls up into each goal.

There are a few improvements I'm hoping to see with Goals in the near future:

• The ability to prioritize goals from the Plans view - now they just show in alphabetical order.
• The ability to view more than just the Goal name in the Plans view - status, target end date, owner, etc

[Varun]

Informative

[Andrew Zimmerman _Appfire_]

I've never tried or seen an approach quite like this. While I've seen three (and more) tiered approaches in terms of hierarchy, it usually equates to the level of abstraction and drills down into sub-categories, each more and more detailed. So more like Goal>Sub-objective or initiative>feature or capability>key result/deliverable>the tasks and work items that deliver the key result. It's just a work breakdown, but without the clarity of the idea/intent you mentioned.

I really like this approach of placing an idea or intent between the work and the goal. I can totally see how it can serve as a sort of bridge that aligns the Work to the Goal.

In contrast, what I've often unfortunately seen is an Objective treated more like a "Categorization Bucket" and work is identified and tracked that "just needs to get done" and so it's placed under and attributed to whatever "Goal" it's most thematically related to.

Of course, this is super wasteful, because that's probably going to result in lots of work that has little value or impact. I love that the "Idea" intermediary serves as a validation step to sustain the alignment back up to the Goal. "Here's an idea we think might help accomplish that goal, and here's how we can deliver that specific idea."

I think having this intermediary tier would definitely help identify wasteful work earlier, and remove it from the plan before allocating resources to it. I also love the dual evaluation approach you summarized.

Great question/discussion @Ted Henry. 

[Lisa Yeager]

I so appreciate the focus on meeting clients/stakeholders where they are knowing where they are from an organizational maturity model in order to design the best approach. 

I can't say that I've tried quite the approach you are describing, although we are in the midst of implementing for a clinical-trials focused org, with the highest level of work being the service catalog, with the mandated deliverables and activities lined out below those. 

[Ted Henry]

Thank you Lisa.  Do you schedule deliverable work directly?  My clients tend to do this for deliverables that take a long time and then run into trouble maintaining focus downstream.  The trouble they run into has to do with competing priorities and its impact on resource availability.  In practice, they wind up with a decent looking gantt charts at kick-off followed by weeks/months of day-to-day struggle to keep them on track.

I'm wondering if it might help to build schedules and track progress around near-term objectives instead.  Something more like tracking work against a roadmap or milestones than a WBS.

The deliverables themselves wouldn't change of course, just how you wrap the work tasks in Jira.  This would require PI-like planning between Program/Product/Project managers and delivery teams, but would hopefully make both planning and progress reporting simpler and more reliable.  It could also help manage competing priorities to always plan around what can be accomplished in the near-term given everything else going on.

Otherwise, a few months go by and there are alot of tasks in the done column but it's not so obvious what has actually been accomplished.  That, and certain tasks are easier to put off or de-prioritize in favor of something else when the near-term context is lost.