MOKRs weeknote – 2

Project vision

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. 

Our users are..They need..We will..So that the Council will..and our residents will..
An objectives story

What we did

Matt Ballantine saved this week. His podcast on OKRs came at just the right time to give me the focus I needed. We’re using OKRs a bit differently with our missions doing the heavy work of setting the aspirational goal, but the lessons are still transferable. It was useful to hear that Google aim to meet 60% of their objectives whilst other companies aim at nearer 80%. It gives us confidence not to aim for 100%. 

I wanted to develop a formula for writing objectives which was as simple as a user story and, like a good user story, helped provoke a conversation about whether we’d understood the need, whether the activity fitted the need and the goal fitted the activity. 

I wouldn’t claim to have achieved something with the simplicity and elegance of a user story. But I had three opportunities to test the formula. A small group of us used it to test a way of expressing an objective for the Space Bank project. It provoked exactly the right sort of conversation and following that, I made a tweak to distinguish between how our residents and the council will benefit. 

The second opportunity was working with the leaders of our infrastructure team. Lindsay and Mal found the distinction in the ‘so that’ useful. It was particularly good to hear them say that they wanted to capture the benefits to residents as well as to the council and its staff. They also had a head-start on OKRs because they’ve thought really carefully about planning their work. They’re hoping we, as DMT, will help them decide what not to do so they can work at pace, better.   

I also had a good session with Tony in print. I’m really keen that MOKRs works as well for services orientated towards BAU as it does for project teams, so was pleased to have the chance. We identified 8 areas for potential objectives and Tony will now use the template to work with some of his team to frame these as objectives.    

Next week

I’ll be designing the workshop for team leads to come together and scrutinise the objectives. We’ll need to avoid the trap of covering ‘everything’ or doing so little in detail that some teams are short-changed. 

I hope to provide more direct support to teams as I did for infrastructure and print. 

And, if there’s time, I’d like to produce a prototype of the tool we’ll use to communicate our objectives to colleagues in other services. This may even slot in with the presentation I’m giving to housing senior management on Friday. 

MOKRs weeknote 1

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. 

Project Vision

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. 

Next week

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.  

7 reasons I love the Summer in Hackney map

We launched the Summer in Hackney map this week. Here’s an ode to why it might already be my summer highlight.

1. It came from nowhere

I first heard of the Summer in Hackney project in its first weeknote. I was surprised and delighted: it’s not often we do something that I haven’t heard of beforehand. So it was liberating to read a weeknote and then see a Show & Tell. That’s why we ask the team to ‘fail in a fortnight’. 

2. There was more vision than definition

The project began with a vision for what we could achieve for users, rather than a clear definition of how we’d do this. We need to start more projects with a goal in mind rather than a thing we want to do. 

3. It was a team

The GIS team worked with user research, our designer and front-end developer to prototype and build a product. The team worked together, testing and re-using components (including our front-end patterns as well as things like the research pop-up banner). 

4. We did our user research

It would be easy to have done the Summer in Hackney map because we thought it was a good idea. We didn’t. The team did user research, together, to find out what users need.  

5. It blends tactical and strategic

The team described Summer in Hackney as a side-hustle, which sounds cool but is a bit unfair. It helped us learn about new ways of working and experiment with a different approach to delivering GIS data to users. 

6. The team delivered

We shouldn’t take for granted that a piece of work that began in July, delivered whilst it was still summer – and before the peak of summer. But we’ve also delivered a tangible improvement to residents. 

7. We’ve created components for re-use

The team did the work in a way that means we’ve learn about a pattern for how to provide maps and developed re-usable components for future maps – reinforcing how this project is a nice tactical intervention providing a strategic opportunity for change. 

From this:

Summer in Hackney - old

To this:

New summer in Hackney map

Working in partnership with suppliers

We hosted a small, open breakfast event for suppliers as part of the Hackney fringe for London Tech Week to discover how we can make HackIT a great place to do business. Hackney Council has a clear commitment to in-sourcing and it’s important we get value for money from commercial organisations and have clear accountability in contracts. So why the breakfast?

We can make things better for residents if we do the best possible work in the most efficient way. We’ve put a strong emphasis on partnering with small businesses to help us learn new skills and adopt new ways of working. Working with a range of businesses gives us access to the best talent and a diversity of experiences and skills. Many of these businesses are local and we can use procurement to encourage them to provide job and training opportunities for our local residents. If we make it more costly to do business in Hackney, then ultimately that cost will be passed on to residents.

Today’s breakfast was targeted at businesses we’ve not yet worked with, or not worked with as often. We want to ensure that the best people want to work with us and show that working with Hackney Council could be rewarding. But we also wanted to test our thinking so that we avoid unintentionally excluding some suppliers from our procurements. Sometimes it can be more efficient to have a standard way of doing things but if you are too specific, you increase the barriers to working with new suppliers which narrows the advice you receive.

We focused the discussion on two topics: How we buy things, and How we create opportunities. It was reassuring to hear that attendees felt that we are right to use the government’s Digital Marketplace by default. It is cheap for suppliers to participate and the marketplace is refreshed frequently.

Our standards

We had a useful discussion about how we see Service Standard assessments. It’s a key frame of reference for the ability of the supplier and event in our project lifecycle. We could do more to show that we’re aligning to the government Service Standard and that they aren’t conducted as a confrontational gateway but as an honest assessment of what’s been done and what needs to be done next.

We’ll consider how we can provide reassurance to suppliers about how and why we conduct Service Standard Assessments. We’ll also explore how we might engage our supplier community more broadly in assessments


We discussed the balance between user research and service design, and development. Our experience has been that an agency tends to be better at one than the other but both are key enablers of delivering the right solution for residents. But we’re also interested in how behavioural science, ethnography, data science and devops can add new disciplines and perspectives on our challenges.

We’ll consider how we can reflect when we believe a team needs a blend of skills or when a task is better-suited to a stronger design or development skillset.


We had feedback from a couple of agencies that had worked with us that we face challenges ensuring that our own staff are sufficiently focused on the project. We know this is an important issue for the team, too. We explored how agencies manage these tensions – and we could learn more still rom software suppliers who manage bugs and incidents alongside software improvements.

We’ll explore how we can ensure we’re providing the right team with sufficient time to make projects successful.

Early thinking

We then explored how we create opportunities, shared our current approach and discussed what more we could do. We built our projects pipeline in the open in response to a previous supplier event so we wanted to know whether we’d made progress. The reassuring news was that nobody else was doing it better. But it was evident that we could be more open in order to learn more from suppliers. We explored whether an ideas wall would help suppliers spot forthcoming plans and whether service mapping would help suppliers tell us about components that might accelerate our plans.

We’ll experiment with different ways to share early-stage ideas so that suppliers can plan for forthcoming procurements and share what they know.

The breakfast was a sufficiently useful event that it re-doubled our commitment to holding these more frequently. We’ve got bold aspirations and sometimes we’ll fall short, so it’s important to be challenged by suppliers in a non-competitive environment. We’ve made some good progress, and helped demonstrate that Hackney is a rewarding place to do business. But there’s more to be done.

When HackIT met the venture capitalists

I’m participating in a programme to explore the concept of responsible leadership – simply, helping people and their organisations make decisions which take account of the interests of all stakeholders. One of the ways the programme does this is by connecting you to people and environments that are unlike your own.

I had a conversation with the partner of a venture capital firm exploring what might a local authority IT team (us) learn from the way that they analyse investment opportunities? And what might our thinking help them understand the diversity of the needs and abilities of people they don’t normally meet.

On Thursday, five of our projects presented to a panel of people from Hambro Perks, a venture capital firm that specialises in growing technology businesses – including brands that we’re familiar with – Laundrapp and What Three Words.

We chose projects that represented larger and smaller investments for us, and products that were already achieving a return on investment and those that were early prototypes. Each team explained the problem to be solved, their vision, the current stage of development, what was already available on the market and what investment they needed next and what they’d seek to achieve with it. They were then subject to (the nicest) challenging questions about the market, the strengths and weaknesses of the product and the potential roadmap.

Across the five presentations, there were some key themes that we need to consider:

  • Are we really understanding and solving problems, or are we just improving existing services? We need to do both. But it’s easy to start with a problem / opportunity and then rapidly find yourself iterating to a point that’s an improvement on today but doesn’t make a
  • Have we understood our users well enough – in particular, using quantitative as well as qualitative techniques to understand the size of the ‘addressable market’, likely digital uptake and how we support digitally excluded people.
  • Do we understand the ‘competitor set’ well enough? This matters in terms of other software that already performs a task but also entrepreneurs, social enterprises, charities who are trying to solve the same problem. Discoveries don’t typically begin with analysis of think tank reports, but perhaps some should.
  • How are we marketing the product or service? We’ve had some tangible benefits of ‘organic’ uptake of some of our products and for others, we’ve got a captive audience. But our marketing ideas could do with further work.

All of these are questions of responsible leadership: do we understand our context, situation and system well-enough to know whether we’re doing the right things in the right way.

The teams found the exercise sufficiently useful that we’re now experimenting with how we might re-create it to inform the way that we initiate new projects. Our next Dragon’s Den event will be in mid-June.  It will be important not to create governance processes that work in parallel to our existing forums, but it was sufficiently worthwhile to give it a go.

Importantly for me, the exercise gave me a real energy boost. I felt significant pride in hearing Andrew; Soraya and Guy; Philippa and Richard; Rashmi, Selwyn and Mirela; Daro and Anna present confidently and clearly about our work, handle the challenge well and to see that our work stood-up to external scrutiny.