Becca Sweetman
OKRs are not one size fits all
Snapshot
Company: Kano
Stage: Seed → Series B
Role: VP Operations
Team size: 15 → 60 people
Introduction
In 2015, Kano was a VC-backed startup making computer kits and software that inspired children to create with technology rather than just consume it. We were growing fast and with over 30 employees we needed a system to support our planning and prioritisation process. We chose OKRs and followed best practice, but quickly realised that for them to be successful we would need to adapt them to suit our size, stage and culture. I still find the lessons I learnt at Kano helpful today.
Problem and Context
Kano grew from 15 to 30 people in my first year as VP Operations. During this time we had a singular goal - manufacture and ship the first production run of 18,000 Computer Kits to our Kickstarter backers in 86 countries around the world. When it came to the planning process I had a pretty good understanding of everyone’s priorities and workload, so when new things came up it was relatively easy to work out how to reprioritise and reallocate responsibilities.
However, following that launch, the level of complexity increased. We now had customers to look after, as well as new products to design, build and sell. We were about 30 people and had a growing senior leadership team who wanted to be involved in the planning process. We needed a system.
We chose OKRs, Objectives and Key Results; an approach that was originally documented by Andrew Grove at Intel and then popularised by Google. The principles of this approach made a lot of sense. In essence, there are Company OKRs that flow down to Teams (and potentially to Individuals), and writing them provides a moment to sense check the plan before proceeding:
- Does the sum of the Team OKRs equal the Company?
- Are there any extra team OKRs that don’t align with the company OKRs?
- If Team A needs support from Team B, does Team B have this included in their OKRs?
- Is there any duplication between teams?
So, how do you go about implementing them? We quickly learnt that one size doesn’t fit all.
Lessons learned
Quarters turned to Acts
When we first introduced OKRs we did them quarterly. However, we quickly noticed a problem:
Looking at the annual roadmap, we had 4 key milestones - May was a product launch, August/September back to school, and then we had Thanksgiving and Christmas in November and December. When you cut this up into traditional quarters the milestones don’t align.
We first noticed this in Q4 - 80% of our annual sales happened in the 6 weeks before Christmas, and then thousands of kids were unwrapping their Kano Computer Kits for Christmas - peak period for our customer care team - at the same time as staff were taking their Christmas holidays. There was no way we were going to take time as a leadership team in December to step back and sort out our Q1 OKRs.
Instead we used the opportunity to adjust our operating rhythm to 3 Acts of 4 months each, starting in February. The name “Acts” was chosen as the CEO had an interest in improv theatre.
This did require a more formal mid-Act review, as 4 months is a long time in the startup world, however, it meant that every Act built up to key milestones in the annual plan.
Lesson: Design your operating rhythm to suit your company, quarters aren’t for everyone.
How involved should employees be?
At the start the team really wanted to get involved so we blocked out time for the whole company to get involved in writing OKRs. Failure…. Lots of complaints that ‘This isn’t my job, I just want to be coding / designing, rather than writing OKRs’.
For the next iteration we swung too far in the other direction. The leadership team wrote the OKRs. Failure…. ‘I’ve got insights and opinions about the strategy, why do the leadership team get to make all the decisions’.
The next iteration the leadership team came up with DRAFT OKRs, and DRAFT was written everywhere possible. Teams were then given time to review and provide feedback. Success… Well, mostly. Some people still wanted to be more / less involved, but it felt like the right balance.
Lesson: It’s not possible to keep everyone happy when it comes to providing input to the OKRs, so aim for optimal - this may also differ by team - and be ready to iterate over time.
Choosing the right targets?
One of the hardest things about setting OKRs is choosing the right level of stretch for the Key Results. Google’s philosophy (at least at the time) was to set a figure that encouraged teams to try and exceed their targets, so 80% was actually success.
It felt too confusing though to have different numbers in our OKRs than we had in our strategy and budget. However, we still wanted to keep the concept of encouraging teams to exceed targets. We did this by adjusting the measurement system.
When the OKRs were reviewed and progress updated (typically monthly) we used the following system, initially just with words and then later with the traffic lights:
Traffic Light System:
- Exceeded expectations (bright green traffic light)
- On track (green traffic light)
- Off track, but we have a plan to get back on track (amber traffic light)
- Off track and we don’t currently have a plan to get back on track (red traffic light)
- Change of plan (grey)
There are a few things to call out in this:
- Traffic lights made it possible to quickly see the status of each team and identify the priority areas to focus on
- “Exceeded expectations” allowed us to both encourage and celebrate teams for achieving more than we thought was possible.
- “Change of plan” ensured that we kept ourselves honest. At times employees felt that we were constantly changing the strategy and so this was a way to ensure that we had a process for acknowledging and communicating if a decision was made to make a change. In the end it also helped us to demonstrate that our strategy remained relatively stable.
The other thing we started to do when setting OKRs was to ask each team for their level of confidence in hitting their OKRs. In general we were looking for ~80% and also looking for consistency across teams. If, for example, Team A consistently set OKRs that they were 95% sure of hitting and Team B set OKRs that there were only 70% sure of hitting then we could find ourselves regularly celebrating Team A, when actually Team B had set themselves a harder target to hit.
Lesson: Checking confidence levels when setting OKRs and your choice of measurement system can help you to create the right balance between setting realistic targets and encouraging stretch.
Conclusion
OKRs were an effective tool to decide on and align priorities. The regular cadence of setting them created a moment for the leadership team, and the rest of the company, to check in on the annual strategy, as well as to adjust and realign our priorities as needed. They created motivation towards shorter term goals, particularly in a business that had a strong annual rhythm, with the bulk of sales around Christmas time. Also, having clearly communicated key results helped to empower delegated decision making. Finally, they helped to speed up the process of onboarding new employees as going through the OKRs was a quick and effective way to communicate the team structure and what everyone was working on.
However, they aren’t one size fits all. It was really important to design the operating rhythm, measurement system, and process to suit the size, stage, and culture of the company; and be open to changing them as we grew.