Introducing OKRs: A Lesson in Compromise

Problem

I was heading a team that suffered from a lack of focus that impacted various aspects of the technical quality of our system, and I was certain that streamlining our focus would help us with the performance. The team consisted mainly of first-time managers who didn’t have the skillset to perform as expected, and the team wasn’t accustomed to using any goal-setting framework. In the past, I mostly worked with the OKR framework that proved to be highly effective in streamlining focus. I decided to give it a try and introduce it to the team.

Actions taken

I knew too well that if I would just announce the change and have it implemented immediately, I would face resistance. That is a natural consequence of hiring a great number of fairly opinionated, smart, and talented individuals. Promotion and evangelizing of new ideas prosper best when based on trust and understanding.

Therefore, I approached the team, asking them what they think we should do to improve our technical quality and how we would know that we are successful. Through an intensive exchange of ideas, the team came up with their own goal-setting system, quite similar to the OKRs. My role was to ask questions, particularly tough questions, and delve into details of alternative proposals, but let the team choose what they thought was the best solution. During the process, I would often contradict, be a devil’s advocate or provide comments that would result in pushbacks but with an intent to align their efforts with our business goals. By doing so, I was able to drive the agenda and steer the team in the right direction.

Their system resembled the OKR framework but was less solid. Objectives were a bit vaguely defined, and key results were not always measurable. I faced the dilemma: I wanted key results to be quantifiable and easily measurable, but I understood that the company culture was somewhat laid back.

I decided to go for a compromise. A suboptimal solution supported by the team that would be affected by it would be far superior to the perfect solution imposed on the team. We set off with this imperfect system, and we were able to improve our stability and quality metrics significantly. One year later, the new goal-setting framework -- though not ideal -- became the team’s second nature, and they embraced it without hesitation.

Lessons learned

• Strong relationships, collaboration and teamwork, are at the cornerstone of any successful project implementation. To secure the team’s buy-in, I encouraged collaboration and gave the team a sense of ownership. The final outcome of collaborative solutions would always be better than of a rigidly imposed and proven textbook solution.
• While most people ask for autonomy and seek to be empowered, in reality -- especially when it takes a considerable effort -- they tend to shy away from it and step back. Some are not accustomed to it; others are merely reluctant to take on more responsibilities. Helping people grow and become more autonomous individuals is often a long journey, and you need to support and guide people all along the way.
• When people are doing something for the first time, they need more than encouragement. I got straightforward feedback from my team that they need me to decide on things. As much as you want to stay away from micromanaging, you should become involved in decision-making if that is what is needed. In those situations, your decisions should be based on a clearly defined “why” that would allow the team to gradually take ownership.