OKRs Gone Wrong Case Study – Common OKR Mistakes

If you noticed that the featured image at the top of the page says OKR CRASH, that was intentional. Most of the articles you read describe the victories that were achieved. This is not one of those articles. This is real-life and this sort of thing happens more frequently than most people would like to admit.

I almost didn’t publish this section because I don’t like to air out people’s dirty laundry but I decided that as long as we keep the names and identities confidential, everything should be fine. Plus, my jope is that this article will keep others from making similar mistakes when designing their OKR programs.

An organization I worked with, let’s call them Duck Corp, began implementing OKRs about 3 months before I got there. Duck Corp had hired a big-name management consultant to help them design their Agile roll-out and OKRs were folded in. This all sounds great, but as we all know, execution matters A LOT! If your culture is broken, a simple tool or technique will not solve your problem. You need to dig deeper and find the root cause.

It did not take long to see that the OKRs were a bit… off.

First, there were WAY too many. You should have no more than 3 objectives at any given level of the organization. The folks I was working with had about 10 teams and they had at least 7 Objectives and often more. Each objective had about 7 Key Results. Doing some quick napkin math, that comes out to… a metric shit-ton of key results.

The group had so many OKRs because they were developed bottom-up. Each team was asked to submit their list of OKRs for the quarter based on what they knew they had to do. Rather than looking at the list and culling it to a reasonable size, middle management would simply compile the list then ADD their own pet projects.

The teams were writing their key results as tasks or deliverables which further contributed to the large number of Objectives and Key Results. Each thing a team was supposed to deliver in the quarter would be turned into a key result. This was partially due to a lack of guidance and understanding of what an OKR was supposed to be and partially due to the fact that each team was responsible for coming up with their own objectives. When teams create OKRs indepenendetly, people are not comfortable writing higher level Objectives or Key Results because doing so would require committing to things they cannot control. I tell you from experience. At Duck Corp, I tried repeatedly to get teams to shift. I was about to get a couple of highly forward-thinking people to consider the idea and test it but they soon gave up because of the organizational gravity holding them back.

So, what do you think happened during the quarter? Teams frequently complained about not getting the support they needed to reach their goals, development was inefficient (this was a software organization), very little progress was made, and at the end of the quarter, people cut the OKR list down to make it look like they had actually accomplished a higher percentage of what they set out to do. Nobody would say it in public but in private team members frequently voiced their frustration with the ineffective processes and deemed them a waste of time. After OKRs were written, most teams would not even look at their OKRs until the end of the quarter when it was time for OKR grading. Essentially, OKRs became a burden that took a significant amount of time to develop and added no discernable value.

When I personally raised the issues to the main consultant from the big-name consulting company, he assured me that he had done implementations of OKRs at dozens of organizations. I was assured that the methods being used were “standard practice”. I wish you could see the shock on my face even as I am writing this. Rumor around the office was that this company was getting $1,000,000 (yes million) per year per consultant and this was the results they were getting? I would say sign me up by my morals prevent me from stealing from my clients. (Yes, there is a little bit of judgment in this bit)

The root cause of the issues at Duck Corp was in the culture and leadership of the organization. It was a highly top-down culture but nobody in management seemed willing to take responsibility for getting real results and management refused to create the high-level objectives. Departments were disjointed with each group trying to hit its own targets without regard for other areas of the organization. the lack of cohesion was the result of a combination of factors including promotion and compensation methods (the good-ole-boy system), and people’s prior experiences with management. Their choice of management consultant was also driven by personal relationships in the upper echelons of the organization (the CEO had worked for the big-name firm earlier in his career) and prestige and not by merit.

OKRs could have been a powerful tool in shifting the culture but they were not used that way because the organization’s leadership wanted things to be the way they were. Most management gained their authority by mastering the existing system and if things changed, those managers may have lost their positions or had to take on more risk. It was safer to maintain the status quo, even if that was not the best thing for the company. Further, most of the people in management positions actually seemed to believe they were doing things the right way, despite continually poor results in terms of product quality and customer satisfaction. It was the way things had always been done and most managers had been around for 15+ years. That amount of conditioning can taint anybody’s view.