6 Common OKR Challenges and How to Avoid Them
Many teams run into challenges when trying to adapt and scale OKRs across their organization. These pitfalls result in poorly implemented OKRs or failure to adopt OKRs. Below are some of the biggest OKR challenges we’ve seen teams struggle with.
1. Not understanding outcomes
Many teams try to implement OKRs, but their objectives and key results are still focused on outputs or solutions. For example, objectives like “launch a new website” or “deliver feature X” are outputs. The problem with this approach is that you don’t know if you’ve delivered the right solution. You might have delivered it on time, but you don’t know if it made any impact. Outcomes are a measurable change in human behavior. The whole goal of using the OKR framework is to track changes in human behavior to see if you are moving toward achieving your objective. This will help your team measure the impact of the work you’re doing. If you need help writing good OKRs that are outcome-focused, check out our post How to Write Good OKRs.
2. Too many key results
We’ve seen teams who couldn’t align on key results end up with 10+ key results. Too many key results adds complexity and makes them too hard to track. You want to aim for 3-5 key results, so your team can actually measure and track progress. We’ve also seen teams write OKRs for every feature they’re working on—again, this adds too much complexity. Your product team should write OKRs for your product or area of focus, and all of the work your team does should align to those OKRs. If you have OKRs layered on top of OKRs you won’t be able to track all of them, and you risk over-optimizing one feature and actually harming your bigger picture goals. The idea is that we’re shifting from the “feature factory” mindset and thinking in terms of outcomes and holistic experiences.
3. Not including stakeholders in planning
Not including stakeholders to align on a shared objective and key results puts you in the position of trying to sell or convince stakeholders. If they’re not aligned and bought in, you will continue to deal with requests that may or may not align to your objectives. The behavior shift from outputs to outcomes takes time. If you bring your stakeholders along for the ride and get alignment from the start, you will be more successful in shifting the culture. You will probably still get feature or solution requests from stakeholders, but aligning from the start will help you shift conversations. If a stakeholder asks your team to build a new feature, you can ask them what problem the solution is solving for, what success looks like, what would people be doing differently if you solved that problem—this allows you to have a conversation about how this aligns to the agreed upon objective. Ideally, in time, stakeholders will come to your team with problems and opportunities—not solutions—and the team can collaborate on identifying the right problems to solve for and the right solutions for those problems.
4. Not sharing key results between teams
Organizations are complex with teams and products/experiences that overlap. Writing OKRs in a silo for your product, team, or area of focus puts you at risk for over-optimizing the experiences within your area and possibly harming other experiences. You want to take a step back and look at journeys holistically as a system. This requires transparency when planning and writing OKRs and aligning between teams. As Conway’s Law states, organizations will design systems that copy their communication structure. These internal silos can lead to fragmented user experiences and journeys. If teams work together when planning their OKRs (and in turn when planning their work) they can develop shared key results and collaborate to figure out the right features or solutions that will help achieve those results. We recommend running alignment and check-in sessions after teams have defined their OKRs to see where teams can align on shared key results and to make sure one team isn’t over-optimizing and hurting another part of the end-to-end experience.
5. Defining roadmaps before OKRs are set
Your team probably already has a huge backlog of work and maybe even a roadmap for the upcoming year. If teams have already decided what to work on before setting OKRs, you run the risk of continuing to build things that don’t make an impact, and building things that might not align to your company’s high-level strategic goals. If you write OKRs to match what you already have in your roadmap, it’s defeating the purpose of adopting OKRs (the goal is to shift from outputs to outcomes.) As Sun Tzu said “Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.” Your strategy and tactics should complement each other. Ideally your company has decided on high-level strategic goals (where to play, how to win, how you know you’re winning/impact metrics) and then each team writes OKRs for how they believe they can help the company achieve those goals within their area of focus. After your team has written OKRs and set goals, you can figure out the right initiatives to help achieve those goals. There are many different methods you can use to determine the right initiatives to help achieve your objective (and some of the initiatives in your backlog or roadmap could help you get there.) You can read about a couple different methods in these posts: OKR Process: How to Adapt and Operationalize it, Impact Mapping Workshop.
6. Not tracking progress
OKRs are not a one time set and forget! Key results are leading indicators that help your team measure progress toward achieving your objective. They help your team become more agile by continuously measuring progress and allowing you to learn early on if the work your team is doing is making an impact. If you discover that you’re not moving the needle, you can change course and try something different. We’ve seen many teams set their goals for the year and forget about them—never tracking or measuring progress. We recommend setting a cadence for tracking key results (monthly, quarterly, etc.) and regularly reviewing as a team. This will allow you to see the impact that your work is making (or not making), and pivot if needed.
Avoiding the pitfalls
There is no one-size-fits-all solution when it comes to successfully adapting OKRs for your organization. The culture shift from outputs to outcomes takes time and experimentation. Hopefully the challenges we’ve observed can help your team avoid some of the common pitfalls as you learn to adapt OKRs for your organization!
COMING SOON! Adapting and Scaling OKRs Course
We are working on an easy-to-follow course that covers the OKR framework and challenges you may encounter trying to adapt and operationalize OKRs.