I encounter many organizations that use OKRs. Too many of them have this crazy matrix where the high-level OKRs – those that aim to achieve the organization’s strategy – map to too many teams/functions in the organization. This creates a need to cascade the OKRs, create sub-OKRs, or other techniques which eventually create a larger and larger distance between the OKRs at the team level and the strategic OKRs. While this at least creates transparency of who’s involved in executing each aspect of the strategy, we can and should do better.

One key thing that unlocks agility and value is to “Organize around Value”. Scrum talks about each team having ONE Product Goal they focus on. SAFe has a specific principle of “Organizing around value”.

If you’re using OKRs One question to ask yourself is what is the relationship between OKRs and teams/teams of teams? If most OKRs require a multitude of teams across the organization/portfolio to achieve them, this will require a lot of coordination.

Try reorganizing into a value stream network/topology/team structure that aligns with your OKRs – where each team/team of teams can focus, and where there is clearer accountability around which team/group owns a specific high-level OKR.

Yes, you can find OKR and Agile management tools that will let you deal with complex networks of cascading OKRs, but Simplicity FTW…

Too many OKRs

Another symptom I’m seeing way too often is too many OKRs. Some of that is related to the OKR matrix I mentioned above. Some of it is just plain old push vs pull and classic wishful thinking at all levels. What could we do about that? Do we have a proven approach that can help? mmm…

Maybe we should visualize the FLOW of OKRs through the funnel of considering them, prioritizing/refining, committing to them, working on them, reviewing, achieving…
How about LIMITING and REDUCING the amount of OKRs in progress across the organization at any point in time – the alignment that OKRs promise relies on focus rather than trying to boil the ocean
Next, let’s manage the flow of OKRs proactively. Maybe even use some metrics like OKR cycle time, throughput, WIP, and aging.
Let’s inspect the flow from time to time. We might learn a few things. Maybe we should adopt the definition of how these OKRs flow and how we’re managing them.