I recently had the opportunity to run “retros” (retrospectives) for a couple of our clients who had reached significant milestones in their use of OKRs. Unfortunately, due to NDAs, I can’t name names but what I can say is they are both in business of software development with distributed teams across many time zones.
I’d been with them from day 1, guiding them through the design of their OKR structure, system, routines and coaching them on crafting their early stage OKRs. Fortunately, because they are using agile methods to develop their software, they already saw the value in running retros on the process to see how they could work better in their next sprint cycle. When I recommended they schedule them in quarterly to focus on improving their OKR processes, they signed up right away.
Let’s look at what came out of client #1
They had just completed their first three-month cycle and had already learned much from it. Their frame of mind was ideal going into their retro – “We know we didn’t get everything right first time, but we’re willing to reflect, learn & adapt so we’re better next time.” I believe this is really important as I’ve come across people who expect perfection first time around. That simply won’t happen and expecting it leads to disappointment, frustration and often blame.
So, what did client #1 learn? First, when planning for the next quarter, it is absolutely worth getting the level 2 management team (direct reports to the Exec) all together to help build up the OKRs. The Exec had tried to do this in isolation and then just cascade. What this did was create very “functionally” aligned OKRs which, while sometimes might be needed, it was recognised it didn’t make it easy for cross-functional OKRs to be created and they wanted to encourage those to avoid silo working.
Second, they decided they had created too many OKRs in their first quarter and they decided to become more disciplined in their prioritisation, which will sharpen their focus and also make aligning/updating/reviewing slicker. This is a very common conclusion I see drawn in retros – especially early stage ones. I always recommend applying ambition to the OKR itself, rather than the number of OKRs however, I also believe that, while I can advise clients on this, they have to work out the limits of their capacity for themselves.
And client #2
They were further down the road as they had completed their first 12 months of OKRs, so they had more to reflect on. They too came to the conclusion that less-is-more and decided to become more ruthless in the 12-month OKRs they were due to create for the year ahead. They also made another very interesting decision: to only have 11 months of “live” OKRs in the year. This meant the first month became “month zero” and the first quarter just had two months.
They chose to do this because they wanted to give themselves more space for strategy/planning/alignment. I commend them for this. By giving themselves more time, they are recognising the importance of it, prioritising it and are far more likely to make better quality decisions as a result. (Incidentally – week zero is a principle used in agile development where the team takes the first week to plan out their work)
Sure, business didn’t pause while they worked through their month zero, but what did pause was OKR activity. Their outline for the month was:
- Week one – strategy development & testing
- Week two – 12-month strategic & 3-month tactical OKR building
- Week three – Brief out on strategy/OKRs & start alignment activity
- Week four – conclude alignment and load up OKR ready for go live
I think this is a really interesting approach, and one I’m even considering adopting in There be Giants.
This is the thing I love about OKRs, as long as you test/analyse/learn/adapt they can bring true agility to both your planning and how you deliver against it.