Making OKRs Lean Again - Part 2
Welcome to the second installment of Dave’s story as he embarks on his OKR journey.
“I want to be able to manage all of these goals,” Mary told him. Dave did a quick search and within no time, he was able to select software that supported his needs. The nice part? The tool also supported the annual performance management AND they offered OKR training. “Isn’t that great?!,” Dave exclaimed, while showing the tool to Mary. The next day, with the approval of Mary, he purchased the OKR software tool. Based on his previous experience with performance management, he understands the importance of such a tool. It should not only help to keep track of people’s goals but also to maintain the transparency of OKRs (which he had learned was vital to the process).
The lovely people working for the OKR software tool company suggested getting some employees “OKR certified” to smoothen the OKR process. He quickly found some volunteers. The marketing intern, the Agile coach (because they are the company-wide “facilitators”, right?) and an engineering manager. They were sent to a one-day OKR training and within a week, all three received their certificate of completion.
“We are ready to start implementing OKRs,” Dave said to Mary. “Next week is the week before the quarter starts. Let’s set the OKRs then.”
Setting OKRs
It’s the following Monday and Dave is really excited about launching OKRs. The CEO gathered all senior management and announced that “...from now on, everybody needs to create OKRs in order to boost employee engagement. Not only will OKRs improve our low employee engagement score, but it will also help with alignment and focus”. She looked at James, the CTO, who is always a bit reluctant to new company changes, and continued: “We have trained some of your colleagues in OKRs and they are now certified internal coaches. They will be helping everybody to set their OKRs.” With a stern tone, she wrapped up by saying: “And I expect each of you to deliver your OKRs before Friday.”
And so it happened. Everybody in the company started to set OKRs. The executing team set OKRs first, then managers set their OKRs, then those same managers set OKRs for their departments: Marketing, Sales, IT, Customer Service, Operations, Engineering, R&D and UX. Then each team was asked to set OKRs, connecting to the department OKRs. And finally, every individual team member was asked to set OKRs themselves.
During the OKR setting process, people had figured out quite quickly that they could transform their current goals to fit the OKR template. So, the Sales teams changed their sales targets into OKRs, Marketing created OKRs for each campaign, Customer Service changed their “Time on the phone targets” to OKRs, Ops their “Uptime targets”, Software engineering their “roadmap items”, UX their retooling goals, and even HR re-wrote their “new hires targets” into OKRs. The leadership team did the same. Revenue, customer satisfaction and EBIT numbers got transformed into OKRs. Even each individual team member converted their personal development goals into OKRs, too!
This resulted in five OKRs at the company level. Five OKRs per department and manager, three to five OKRs per team and the same for each individual. It was as if they were sprinkling some magical OKR fairy dust over all of their existing (and mundane) goals. Lucky for them, they had the OKR software tool to help them manage all of their OKRs.
Dave was in charge of coordinating the OKR rollout, but after one week it was already apparent that not everyone was happy with the changes. He heard complaints from multiple people, such as “OKRs simply don’t work here”, “We also have other work to do, we’re drowning!”, “We already do Scrum, so why do we even need OKRs?” Dave was able to placate them by replying: “I hear what you’re saying but we really need to improve employee engagement and therefore OKRs are necessary”. It is worth mentioning, not everybody was unsatisfied with the changes. Some were quite happy that their leaders took action based on the employee engagement survey result, so they gave the leadership room to try OKRs out and proceeded without too much resistance (something that isn’t always the case in other companies).
During the Quarter
After all the OKRs were set, people got to work. They continued working on the tasks they were assigned to. Developers continued working on the features they received from product owners. After all, the Objective was to “Deliver awesome UI to customers.” UX kept working on the designs for the UI and handed them over to the engineering teams. However, they couldn’t deliver as fast as usual because their OKR was about converting their existing UX designs into a new tool, which took up a lot of their time. Marketing couldn’t make any progress on their OKRs either. They couldn’t launch their new marketing campaign because they depended on engineering to deliver the new UI. At the same time the Engineering team finally received new UI designs from the UX team, the company welcomed a new “big whale” client. The Sales team was on a roll to move the needle of their KRs. This required at least five software teams to pay attention to delivering on this.
At some point, the management team took a look at their OKR software tool and noticed that there was low progress on most of the OKRs. So, they decided to put some pressure on the Ops and software teams to deliver on time. Because the Operations team didn’t have time to automate their own work, they had a hard time with this new customer coming on board. Some teams were working overtime to deliver before the due dates of their “epics”.
The pressure seemed to work. The teams did some amazing work. They were able to push out the UI changes and a new feature before the deadline. “These OKRs work great!” some senior manager boasted over lunch.
The team moved back to working on features for this new major client. Meanwhile, there were new bugs coming in because existing customers were also using the new UI. Some software teams couldn’t focus on the OKRs or the major client anymore because of customer issues. “Maybe next quarter we can set OKRs for reducing bugs and do a big refactor project”, one of the software architects cleverly thought up.
Weeks went by and little progress was made on their OKRs as they worked to keep their heads above water.
In my next post, we will learn more about Dave and his bumpy start with OKRs. Until then, can you predict what the end of the quarter is going to look like for Dave’s company?
Now Available!
