OKRs: It’s about the struggle. Embrace it.
At Gtmhub, we’ve been doing OKRs for over 3 years now (duh!). We help a lot of our customers with advice and experience – so, one would think that we never struggle with OKRs.
And, one would be wrong.
The struggle is the point
Today during our weekly OKRs retrospective meeting we started a discussion about this particular objective.
- Objective: Scale the engineering team
- Key Result 1: Onboard 5 new developers
- Key Result 2: Ensure a transparent and clear process for the engineering team
The reason we focused on that objective is that it was still at 0% attainment one month into the quarter. The short discussion ensued, where it was speculated that OKRs don’t work in this case. We went through all the arguments and frustration you have certainly experienced.
But, then we’ve realized something important.
What is successful onboarding, anyhow?
The discussion led us to several important, albeit tough, conclusions.
- We have a process for onboarding people, but we don’t know what it means to successfully onboard someone (lack of transparency)
- Once we’ve started to discuss how does a successful onboarding look like, we went into yet another rabbit hole of different opinions (lack of alignment)
Fast-forward fifteen minutes and we’ve started to come up with a set of criteria that we were agreeing on. We’ve all agreed that a successfully onboarded software engineer would be able to write some documentation articles (easy), write some automated tests (a bit harder), fix some bugs (even harder), implement simple features (pretty hard).
So, we went ahead and rewrote this particular objective as follows.
- Objective: Successfully onboard new developers
- Key Result 1: 30 documentation articles to be written by new team members
- Key Result 2: 200 automated tests to be authored by the new team members
- Key Result 3: 40 bugs to be fixed by the new team members
- Key Result 4: 5 simple features to be implemented by the new team members
We then broke down this objective into individual objectives for each of the new team members and aligned it with the overarching objective of the engineering organization.
Throwing OKRs under the bus
OKRs have a tendency to uncover unpleasant things within an organization – this is what makes them simultaneously hard and powerful. It has never dawned on us to define what makes a successfully onboarded engineer. It should have, but it did not.
When we struggled to come up with a good OKR for this, our instinct was to blame OKRs; blame the framework. This, however, is akin to dismiss the concept of traffic lights, because often, they are red.
We were able to solve several important problems today, which would not have surfaced for a long time were it not for OKRs.
- We have set clear criteria for new employees, but also their managers – what it means to successfully join the team. While there was implicit, even tribal, knowledge on this – it was not clear to everyone and most importantly to our new colleagues.
- We all got on the same page when it comes to actual criteria. As we had people from other functions, we took some ideas from the sales team and how they onboard SDRs.
We all often struggle with defining our OKRs. We’ve been all trained to think in terms of output, where it is really outcomes that we should be pursuing.
Switching from “I will do this” to “I will accomplish this” is a rough ride and it forces us to have a deep and clear understanding of what is it that we are doing and why.
In a way, OKRs are like working out. If you don’t feel the pain, you are not doing it right.