OKR anti-pattern: reverse engineering key results to match your backlog

I work with teams around the world every day helping them implement objectives and key results. I’ve written about OKR here a lot over the last few years and now, as the goal-setting framework is catching on broadly, the anti-patterns have become increasingly obvious. One such anti-pattern I’ve noticed recently is teams reverse engineering their OKR, specifically their key results, to match their existing backlog. Instead of changing what they’re going to work on to meet the new goals, teams massage the goals to match what they’ve already got in their backlog. This is a clear case of the tail wagging the dog and symptomatic of at least three failures in the organization’s OKR rollout:

1. The rollout wasn’t sold effectively to the organization — Every organizational change has to come with a story. If you tell that story effectively, your teams will understand why you’re making the change, the impact it will have on their work and the desired end results and benefits of the change. Goal-setting changes are particularly impactful as it changes how employees are measured and rewarded. If leadership doesn’t sell the transition to objectives and key results successfully teams will assume that this is just another phase the org is going through. It will pass and we’ll just keep doing things the way we always have. In this scenario teams are highly unlikely to change the work they have already planned to match new goals so, instead, steer the process so that the goals reflect their current production efforts.
   
   
2. Teams are afraid to change their backlog — “I will literally get fired if we don’t ship this feature by the end of May,” I overheard an executive say recently. This is perhaps the biggest cultural challenge to successful OKR rollout and adoption. By their very nature OKRs force teams to reconsider what they’re building from an outside-in perspective. They are challenged to understand how to impact customer behavior rather than how to ship a specific number of features by a certain date. This customer-first lens explicitly means that any features that don’t positively impact customer behavior — thus pushing the team towards their desired key results — is discarded. If there is management blowback to removing items from the backlog those items will get developed regardless of their relevance to the OKRs. This renders the new goals irrelevant prioritizing, instead, features once again.
   
   
3. Incentives haven’t changed to reflect the new goals — This is always the last stone to move when it comes to cultural and organizational transformation. Process changes first. Team structures change next. Vocabulary gets adopted. The org chart shifts this way and that way. By the time teams get down to the day-to-day work they need to do, one thing hasn’t changed — how they get measured, rewarded and incentivized. Traditional manufacturing, which is still sadly how most software teams get managed, rewards production or output. If you’re implementing OKRs the reward should come when the consumers of your product or service change their behavior. This is not a factor of how much you’ve shipped but rather what you’ve shipped and how you’ve designed it. The only thing launching more software guarantees is you’ll have more software to maintain and more technical debt. Teams will optimize their work for what gets them paid. It’s imperative they get paid for making customers successful if we want OKRs to succeed. 

What other anti-patterns have you seen for OKR rollouts? How have your organizations overcome them? Leave a comment.