I’m writing a weeknote about how we’re developing our MOKRs (4-year Missions, 12 month Objectives and quarterly Key Results). We’re doing this to help evolve how HackIT works from start-up to scale-up. By writing a weeknote, we can share what we’re doing, what we’re learning and how we’re evolving the technique.
We have bold missions for how residents benefit from public services fit for the internet-era and we manage our work in small chunks so that we’re able to course-correct and we do that in a spirit consistent with our values.
Goal for the week
Develop a clear process for how we’re going to develop our objectives so that managers can lead.
What we did
Write a long-form project brief. I thought it was important to record what we’re doing, why and what we do and don’t know, so that we had a point of reference. We will need to hold ourselves to account and be clear about the ambition so that when things happen that we don’t expect, we can ask whether the initiative is worth it.
We explored the project brief as a management team and honed the success criteria, reading for sharing with managers.
I led a briefing for 11 of our line managers to explain how we were going to develop our objectives, what we expected of them and which bits we might find hard. It was also a good first test of our thinking. The plan largely survived first contact, but I did a small amount of tidying-up before re-sharing the presentation with them.
We also created a Sheet for teams to start populating their objectives. We’ve structured this around the five missions rather than teams, to try and support collaboration – but it may be too hard. Some teams have already made a good start with their objectives, so we shouldn’t be far off a long-list.
I then drafted a slide presentation for the strategy show & tell that Rob led to explain our thinking to the whole team.
So now we’re pretty clear who needs to do what and by when. I even developed a (not particularly good) gantt chart.
I’d like to design and test a formula as simple and easy to use as a user story to see if that helps us write good objectives. As David Durant reminded me, it’s important we’re clear about the user need, they need to be specific enough that teams know what it is we’re doing and the outcome needs to be clear enough we know why we’re doing it.
There are one of two other things that I could also do (I’ve probably not got time for both). We’re running cross-team workshops to review the objectives and develop the key results – and I need to design these. We also need some sort of visual representation of the objectives so that colleagues in services can see what we’re doing and check that it aligns with their expectations. We’ve had enough efforts at developing and maintaining roadmaps, that we know it isn’t simple.
There are a couple of related projects that will support our OKRs. We’re finishing a review of our manifesto which spells out the culture in the team, and this will help us ‘do’ OKRs in the right spirit. Secondly, we think we need a consistent way that we do people planning across our teams to make it easier to start projects, ensure the right people are involved and spot blockers. There’s a draft brief which we need to agree and then discuss with the potential project team.