OKRs - How’s it going?
Frameworks are always a hot topic in the product community. Every week there seems to be a new one recommended as the best way to build products. I’m a big fan of trying to work in new ways, it can provide a bit of a reset and re-energise the teams to help focus and optimise the way they collaborate. On that note I wanted to write up and share my thoughts and experiences of using OKRs over the past few years….
It’s worth stating upfront that Which?, where I have worked for the past 5 years, has a diverse portfolio of products and services. It is a not for profit organisation that has a commercial arm who’s activities fund our charitable mission. As the UK consumer champion we need to ensure we are focusing in the areas that will drive the most impact for consumers.
Year 1
Our first foray into using OKRs started over 3 years ago when at a Product Team level we introduced OKRs to help us focus on the right outcomes (over outputs) and align around what would drive the most impact for the user and business. As a team, we felt empowered. We’d written some strong outcome focused objectives and developed metric based Key Results to measure progress. Colleagues outside the Product team all agreed that the focus was right. We thought we’d laid the right foundations to build out from. However, we found in reality that mindsets are hard to shift, there was a fear of letting go that made people resistant to change. We’d made an assumption that we’d be given the space to problem solve. Additional requests, features and deadlines started heading our way and we’d quickly reverted back to being measured on our outputs and not those key outcomes we were trying to achieve.
Later on that year, OKRs went up a level and were set at an organisational level. The Leadership team had bought into the model and had a crack at focusing the whole company on specific areas. The intent was there, however we hadn’t got into the cadence of creating quarterly OKRs that supported those annual OKRs, so that we can easily track overall progress and make any necessary adjustments based on in year learnings.
Year 1 learnings
My learnings were that in order for OKRs to be useful, you needed alignment that the OKRs were the most important thing to be focused on. It’s all well and good waxing lyrical about OKRs and goals, but that’s only one part — We shouldn’t have taken it as agreed that the OKR WAS the priority and not just words on a page. More importantly, the team needed to be given the space to discover and decide how to achieve what had been set out.
Overall though I believed we’d made great progress on trying to focus but needed to develop Key Results that had the right indicators to keep us honest on our pursuit of driving the right outcomes over the course of a financial year.
Year 2
In the build up to year 2 we made some big operating changes to the Product and Tech teams. We’d introduced our own version of the Squad model, taking some of the principles and attributes and adapting them to suit our needs. Squads with long term missions and owners of digital spaces that were acknowledged as strategically important and backed with ongoing investment (more on that in a future post).
Each Squad was empowered to set their own quarterly OKRs that laddered up to the annual OKRs AND were given the space to decide how to best achieve their metrics.
Now squads weren’t the only delivery mechanism in helping the org to achieve its objectives. There were other groups made up of different disciplines collaborating on ideas to move those metrics forward. It was great to see lots of people around the business getting involved in OKR work, after all we’d committed that these were the most important things to focus on. However, what we’d got wrong in my opinion is that rather than starting off small and slowly rolling out OKRs to more teams, we took the Big Bang approach which resulted in a cosmic amount of OKRs being set at a team level that meant focus was impossible. We’d reverted back to type and were trying to do too much and not prioritising effectively. We’d ended up in a situation, where non product and tech delivery teams were committing to delivering OKRs in a quarter with no means to deliver the work.
We’d also introduced an OKR tracking software to provide a consistent and transparent way to update all employees on progress and to help ease the burden with reporting. We wanted to share how the squads and other delivery groups were delivering against those Org OKRs. The trouble was, there were just too many of them making it really tricky to interpret what was happening where and what was driving the most impact.
This is going to sound harsh, but the OKR framework was being broken. We had too many team level OKRs. And those OKRs in lots of instances were merely task lists of what teams were going to be working on. There was a perception that everything that was being worked on had to be an OKR or it couldn’t be worked on. This made reporting unwieldy and as a result it was hard to connect with what was happening week by week. At this time squads were being really scrutinised about what they were working on. To me this spoke volumes about the challenges we had. There were many other delivery groups out there doing their day to day job with no issue, Squads however really had to work hard to align on what they were working on. Now, I know Squads are expensive and that’s one reason why they’d have a spotlight. I believe the other reason was because it was recognised that they were the main delivery mechanism to helping the org achieve their OKRs. Other Delivery groups had the best intention, but with no means to deliver the ideas they’d generated what hope did they really have.
Year 2 learnings
Starting smaller with rolling out OKRs would have been sensible. Only use OKR tracking software if it is actually providing value. If not, a simple spreadsheet is just as effective and chances are you won’t have to spend a small fortune on platform licences. My final learning is related to the point that not everything has to be an OKR. If what is being worked on doesn’t support actually moving those top level OKRs forward, then it doesn’t need to be written as an OKR or reported through the framework. That doesn’t mean it can’t be worked on (assuming you have the time). And that’s the message I’ve been trying to land across the business for a while now.
Year 3
I’ve spent the last 6–9 months working with our Squads on OKR development. Really getting them to think about the outcomes they are trying to drive. Where there is some lift and shift migration type work, thinking about why they are doing it. What are the customer benefits, maybe it’s performance related meaning our customers find the answer to their question faster.
E.G
Objective: Successfully migrate website x
Key Result 1: Improve page load speed by 20%
Key Result 2: Reduce bounce rate by 5%
Key Result 3: Reduce the time it takes an Editor to published content by 50%
There is a craft to developing OKRs, they are incredibly simple but also annoyingly difficult to get right and it takes practice. Lots of practice. Making sure they are well written (spending the right amount of time) and having feedback loops in safe spaces. But for me there is a fine line between spending time on well crafted OKRs and metrics versus actually working on them. If you get to the end of the quarter and haven’t achieved the desired outcomes, maybe you spent too much time crafting those OKRs and trying to pinpoint how much you were going to shift that metric. On that note I’m super keen that Squads demonstrate to the rest of the organisation what good looks like.
OKR setting is getting stronger and quicker each quarter. Each Squad has regular forums that are open to all employees to hear what’s being worked on and why. There is a simple one page dashboard that is regularly updated, with:
- OKR progress
- Priorities for the next two weeks
- Talking points / Decisions needed
- Squad Health
And at these check-ins Squads are able to confidently talk to their OKR progress. What they learnt over the previous two weeks and what they are intending to learn in the upcoming fortnight. What insights they are drawing from and what hypothesis and experiments are being run in order to build up their OKR confidence.
Year 3 learnings
I introduced a quarterly OKR review meeting with the Squad Leads, which was a real step forward and promoted a collaborative approach between teams. I set it up as a safe space for Squads to talk through their thinking for the upcoming quarter, get some feedback and make any necessary improvements to their proposed areas of focus. From my perspective, it provided a neat way to get an overview across the portfolio and identify any gaps or dependencies that might need attention. On top of that it’s a great way for me to give feedback on OKR setting and to ensure that Key Results are outcome focussed and measurable.
In summary
The OKR framework really does work. It really does provide a way for any organisation to focus on what’s important. To galvanise a whole business on a small set of problems to solve that will drive the most impact for its customer and commercial ambitions. My recommendation really is to start small. Demonstrate the value they bring in an incremental fashion, take the time to learn and explain how OKRs work and what are some of the anti patterns that you should try to avoid. Have a mixture of leading and lagging indicators, to balance real time insights with longer term change in behaviours.
My last thought is that change is always hard and it does take time. Don’t beat yourself if things don’t go the way you planned. Things are very rarely perfect and will often go wrong, but that’s how we learn and for me, that is one of the best things about working in Product Development.
Look around for some case studies, or feel free to reach out to me for a chat!
If you are wanting to find out more about OKRs, here are some excellent resources:
