Focusing on goals through OKRs
How the implementation of OKRs helped to maintain focus (and control) on the team’s goals.
“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” — Jim Barksdale
I took Management 3.0’s Foundation Workshop in September 2019 and it opened my mind to a universe of possibilities for the improvement of my team’s productivity, engagement, and unity. So one thing I wanted was experimenting with OKRs.
Experiment #1: Creating an OKR for the team
After a mapping process of what motivated each team member through Moving Motivators, I defined the inclusion of a quality-oriented OKR as an action plan.
I started conversations with the team to set the goal so we could find out what would help us to achieve it. It had to be challenging, yet doable. It should create discomfort if it was not met.
The topic was very well received by the team and we managed to set our goal based on the proposed ideas.
Objective: Improve the quality of the team’s deliveries.
We identified two key results (KR)from the goal that would lead us to it:
KR1: A minimum of 30 days without new bugs reported in the production environment;
KR2: Having a maximum of 2 bugs reported during a release flow in non-productive environments.
That was our goal for the next quarter!
The first KR was challenging for the QA analyst (tester), as his mission is to not let bugs pass through to production.
The second KR was challenging for the developers, who should improve the quality of the climbs to non-productive environments when they were already on the release train.
The goals were challenging but possible.
Key Results Measurement
KR1: as it is measured daily, I made a panel available to be updated next to our kanban. The information was visible to everyone and nobody wanted to be responsible for resetting the counting!
Panel translation:
WE’VE BEEN WORKING FOR _ _ DAYS WITHOUT BUGS IN PRODUCTION. OUR RECORD IS _ _ DAYS.
KR2: For the KR control of bugs in non-productive environments I used JIRA x Confluence (tools from Atlassian), measured and reported weekly to the team, breaking by technology and sprints:
Outcomes
The day after we made OKR official, the team was already thinking differently:
- There was a concern with the correct classification whether a situation was an error or an improvement;
- The developers did not want the QA analyst to find bugs in the features that they made available for testing and the QA analyst did not want to miss anything.
During the first month, our “We are x days without bugs in production” counter hit a record of 20 days. It was sad when we identified a bug in production and had to reset the counter…
The goal of maximum bugs in non-productive environments was easier to achieve. This means that this goal must be more aggressive.
All results were consolidated monthly in our Confluence space and grouped by quarter:
This content was presented to management, who liked the switch from KPIs to OKRs.
Lessons learned
Despite the actual improvement in the quality of deliveries, I realized that the team’s concern was with the goal.
“When a measure becomes a target, it ceases to be a good measure.” — Goodhart’s law
I should change the approach when it comes to OKR and metrics, so that the means used to achieve the numbers and not the numbers, are the goal.
Experiment #2: Creating OKR for a product
In 2020, still in the same team, I was challenged to create an OKR for the “Negotiation” product. It was a subjective and difficult to measure product.
The first step was to discover the product’s goal as a whole and then set an improvement target.
For that, I pulled some discovery sessions for an existing product, but it was not so clear to the team.
The first question I asked the team was “What is important for the success of a product?” and the result was the following Word Cloud:
I was satisfied with the team’s general concern with “quality” right away, a positive point for 2019’s OKR!
Then I pulled paulocaroli ’s IS-IS NOT-DOES-DOES NOT (Lean Inception) dynamic so as a team we could map what the “Negotiation” product was:
During the dynamic, it was possible to understand the product’s purpose and visualize a goal to achieve, which was in line with the company’s strategy: to disable the “PCOMM” sales system in stores, leaving only the “Via+” sales system.
Objective: Via+ be the preferred trading channel for Via Varejo stores
The next step was to identify what would lead us to that goal and which metrics would help us to map those results.
Defining “Key Results”
There was a very illuminating approach to metrics in Thiago Brant’s Management 3.0 Metrics and OKRs’ Workshop, in which the rules below were detailed:
It helped me a lot to figure out what to measure and how, especially the rules below:
- Measure for a purpose: measure what makes sense for the objective;
- Seek to improve: don’t measure vanity metrics, think about stats that tie to tasks to improve and to the goals of the business;
- Don’t connect metrics to rewards: People should like to achieve results on their own. Never forget that it’s just a means to an end!
So the key results for the next quarter was born:
- Key Result 1: Have all PCOMM payment methods on Via+ by June/2020;
- Key Result 2: Have 100% of the negotiations with new payment methods (from KR1) being carried out on Via+ instead of PCOMM;
- Key Result 3: Don’t release any bug in production.
Outcomes
Key results were measured weekly and reported monthly. KR2 was the most challenging and despite not having reached 100% of the goal, it made me see gaps in the product that I had not noticed and that allowed me to develop an action plan to achieve my goal.
Lessons Learned
It’s really hard to think about KRs that are not actions! When I look back to my last OKR I realized that the KR1 was actually an action to be measured by KR2, and KR3 was an action too.
Despite this, I can give some tips to help creating an OKR:
- Know the company goals
- Know your product’s purpose
- KRs are measurable, not actionable (repeat this as a mantra)
I’ll use these for my next OKR experiment. Oh yeah, I won’t stop here.
“Não é sobre chegar no topo do mundo e saber que venceu
É sobre escalar e sentir que o caminho te fortaleceu.” — Trem-bala Ana Vilela
Translation: “It’s not about getting to the top of the world and knowing you won. It’s about climbing and feeling that the journey made you stronger.” — Bullet Train — Ana Vilela
Find out more about OKRs at Management 3.0 website:
References:
- Menti (Word Cloud): https://www.mentimeter.com/
- Mural (IS/ IS NOT/ DOES/ DOES NOT): https://www.mural.co/