Defining OKRs is not enough: You’ve got to achieve them!
Everyone nowadays started using OKRs, yet few companies can say out loud that they are able to execute them properly, and achieve those dang key results.
If we look back, how many of us could say, deeply in our heart, that we have achieved our objectives for last year?
We are becoming more and more excellent at defining OKRs, but why is it still so difficult to achieve them?
Ultimately when setting OKRs, we are supposed to maximise the value we can generate to both our users and the business. And yet, many times, it’s not the case.
When I started to think about the issue I found out the problem was not a new one and could be traced back in time, in a different context and environment...
An inspiration from ancient times
At the beginning of the 19th century, Carl von Clausewitz, a Prussian general, wrote a book called “On War”. In it, he mentions that “external factors” are what makes the difference between war "on paper" and actual war.
These uncontrollable external circumstances cannot be predicted, and he describes how these factors are creating "gaps".
Essentially, gaps exist between our real intentions and what we plan; between these plans and our actions; and finally, between these actions and the desired outcomes.
They can be summarised as such:
- Knowledge Gap: “Our plans are imperfect because we lack knowledge.”
- Alignment Gap: “Our actions are not always aligned with our plans because it is difficult to align everyone at different levels towards the same direction.”
- Effect Gap: “Our outcomes are far from what we expected because our actions have had a different effect”
The same effects identified by Clausewitz have also been found in business (for more info on this, read “The Art of Action” by Stephen Bungay).
How can we solve these three “gaps” then?
Here’s how we decided to tackle it at PayFit in order to reduce the risks of failure.
Problem one: The Knowledge Gap
“Our plans are imperfect because we lack knowledge.”
First things first.
Gaining knowledge on the context and the problems we are trying to solve for both our users and the business, has now become a must for every product organization that wants to maximise the value that their teams are set to deliver.
There’s a vast literature on how to conduct the necessary research to discover the most impactful thing to build, before actually building it.
But few companies are focusing on the other aspect of this problem: the actual sharing of this knowledge, among different functions of the same team and across different levels of the organisation.
Teams are accustomed to work in silos, delivering their work, but without sharing the knowledge they have acquired while doing it.
Team topology has evolved over the years, as visually explained by John Cutler in his journey to product teams, in order to integrate more and more functions into the product development process, instead of just working in waterfall.
Here’s an infographic from his article:
At PayFit we have decided to create cross-functional teams where a Product Manager, a Designer and an Engineer are always collaborating together and sharing the acquired knowledge to their respective functional teams.
This Triforce thinks and acts as a single individual, being able to identify what is valuable for the business and our users while ensuring a high level of usability and feasibility across the different levels of the organization.
Rituals have also been adapted to foster this spirit of collaboration and make sure information is flowing in all directions.
An example of our rituals are:
- Triforce Sync - In which the members of the Triforce belonging to the same Squad (one team) or to the same Tribe (multiple teams), discuss problems and challenges, refine priorities, and share knowledge on best practices.
- Squad Sync - In which we share new insights we have identified, we challenge the prototypes we are working on, we test the working solutions and analyse together the results of past deliveries to enable the team to take autonomous decisions based on the context shared, and avoid the creation of a fixed list of requirements.
- Tribe Sync - In which we share the progress on the key results, we present the validated designs and we run a demo of the working solutions to share the success and inform everyone on the progress made.
Problem two: The Alignment Gap
“Our actions are not always aligned with our plans because it is difficult to align everyone towards the same direction.”
Aligning people intentions is probably the biggest challenge.
Each member of the team, no matter what their level is, should clearly understand WHAT we are doing and WHY we are doing it, in order to make the best decisions in their daily job.
Intentions should be clearly visible at least one level up and one level down.
This way, teams can find out on their own how to get to the final result.
A few months ago, I started using the following diagram to logically explain what and why our team was up to, to our main stakeholders.
What were my goals?
- Write down our intentions as new information was coming up.
- Align our intentions to an overarching goal.
- And also, have fun!
Through this diagram, we were able to:
- explain the reasons for our choices in a quite logical way,
- quickly align with stakeholders from levels up,
- align and empower collaborators levels down.
Problem three: The Effects Gap
“The outcomes are far from what we expected because our actions have had a different effect”
This may be the more creative problem to tackle.
The funny thing here is that even with the necessary knowledge and a good level of alignment, we can still fail. The effects of our actions are unknown, and increasing knowledge or alignment won’t reduce this risk.
In order to solve this, we ask our teams to iteratively solve problems that prevent us from achieving those goals. We cannot always avoid failure, but we can limit it over time.
The smaller the problem we are trying to solve, the sooner we realise if we are going to achieve the expected outcome with the ongoing iteration.
Thus, our teams are continuously working to identify those problems that are preventing us from achieving an objective, find the most suitable solutions to solve it, deliver it and eventually analyse their results, within a given timeframe.
Sometimes we succeed and we are able to move the key metric; some other times we don’t. But if we fail we get to do it fast (ideally every 2 to 4 weeks, depending on the velocity), and then retry, iterating until we get to the desired outcome in a continuous and lean product development process.
At every cycle, based on the key learnings, we are able to start off the process again, allocating time-boxed activities for each step and parallelising the continuous discovery with the continuous delivery, repeating it till the outcome has been reached.
Wrapping up
Defining OKRs is the first step, but creating and executing a plan to achieve the desired outcomes is another story.
The experience to get there is a journey that will need to be explored together with your team. Each member has different needs but you have to identify a pattern, extract it and provide your team with a framework to put it in practice.
It may not be always a success but I personally learnt from it and here are my key takeaways from building that framework:
Sharing knowledge is equally important as acquiring it
Talk with the business. Speak to your customers. But don’t forget to spread the knowledge among your team-members and across the organisation.
Align and share your intentions across all levels
Keep it simple. Be clear about intentions: what you want to achieve and why. Ask your team to tell you how they will achieve it.
Iteratively solve problems that prevent you from achieving your goals
You cannot predict the outcome of your actions. Do not try to do so. Define the approach that best fits with your team needs and iterate until you get to the right outcome.
Sharing knowledge, aligning intentions, and solving problems as they come.
It’s as simple as that.
If when reading this article you find yourself facing similar problems as those listed in this article, I encourage you to think about building your own framework. Gather the knowledge and involve your team, align everyone's intentions to come up with the solution that best fits with your team. Measure the results you obtained. Possibly, fail. Retry and iterate again.
Most importantly, building this framework should liberate you and your team, from any rigid constraints. Have fun, learn how your team works best, and good luck!
Photo by Isaac Smith on Unsplash