There’s another round of backlash against the ‘Objective Key Results (OKR)’ framework, including from people I admire. I’ve been working with OKRs over the last five years with a degree of success, so wanted to share what I’ve learnt.
I introduced OKRs to Hackney Council in 2019 (or thereabouts). I read most of Andy Grove’s High Output Management beforehand to check it was the right thing to do. But having previously written about the importance of clearly defining ‘now’ and ‘future’ but being relaxed about the bridge between those two moments, I already had a bias towards the concept.
We tried OKRs in Hackney for two reasons: I wanted to create some shared goals that brought together different teams across IT. I thought that OKRs could encourage cross-team working by showing both run-time and project teams what mattered. Secondly, I wanted to give our teams a clearer idea of why things mattered, supporting a language of outcomes for our users.
We didn’t get this all right. We tried to align the objectives to our missions. But they weren’t mutually exclusive so it became a complex mapping progress.
We set objectives at departmental level. But these didn’t easily translate to the work that people did in teams. So teams started doing their own. And some teams were better at it than others. The initiative failed to achieve its purpose in full. It faded out some time after the cyberattack and I suspect left completely when I did.
But that didn’t make it a failure. Teams spent some time each quarter planning. And could reflect on whether they had achieved their goals each quarter. This isn’t ‘A Bad Thing’.
Within days of arriving at the CPS it was apparent we needed something similar. Initially it was even more counter-culture. So we started doing it at a departmental level. Each department had too many, and they lacked an over-arching framework. But we kept iterating. And unlike Hackney, we have an effective meeting of department heads to agree the OKRs across the directorate.
We have avoided nesting OKRs more deeply (eg into personal goals). But we have developed a model for each OKR to be sponsored so that it has leadership.
There was briefly concern that OKR development could ‘turn into an industry’. It’s currently half a day a quarter to plan the goals and then an email exchange a month to provide a RAG update (which we communicate more widely in our monthly Strategy All-Hands). I’d argue that 4 hours a quarter for planning the work of 280 people is as ‘minimum viable’ as it gets.
Inspired by a tip from a Harvard Business School class, I’ve now taken to using our quarterly OKRs as my background on Teams meetings. I don’t know whether it helps remind my team what’s important. But it has stimulated helpful conversations with colleagues across the organisation and with partners across the criminal justice system.
We haven’t ‘got there’ in terms of expressing the business outcomes. So we’re iterating the approach further. We’ve now asked ‘how might we’ questions and the quarterly planning meeting frames the OKRs as answers to the questions so that we spend the time on the ‘why’ and ‘how’ rather than the ‘what’.
None of this makes OKRs management magic. OKRs don’t make you Agile. Setting good goals isn’t easy. Getting the right mix of planning, validating and doing requires judgement, the right context and culture as well as process.
But OKRs done well can support working back from business outcomes, business agility and cross-functional collaboration.
Recent Comments