A lot of stuff this week seemed to be about drawing mental boxes to put things in or out of. Kind of a conceptual tidy up, which among other things included…
Wrote an audit report for how we’ve been using OKRs. That was fun.
Our product director presented a shorter version of his talk about decision stacks. It’s an interesting concept for helping product managers frame their remit, but like so many frameworks it says nothing about the environment necessary to make it a success.
Ran a workshop with some of the product managers to discuss what we do but shouldn’t and what we don’t do but should. My aim is that together we figure out what we’ll need to change about the environment we’re operating in and start same safe-to-fail experiments that help others understand what product managers do and why it’s important.
Chatted about the vision for campaigns on our communications automation platform. It helped me think more deeply about that aspect of the product and how it might affect user outcomes. One of the challenges we’re trying to figure out is how users have a coherent experience of communications when every user journey is unique, and I think the vision for campaigns helps with this.
Started conversations about how we achieve data maturity as our product scales. Without the data we can’t do anything and I’m not comfortable waiting to see what goes wrong, I’d rather we start improving things now.
Mapped out two version of the same ‘thing’, one as a product (long-lived, cross-functional team, empowered to meet user needs and responsible for outcomes) and other as (hierarchical, functional team, centred around technology, briefed to meet stakeholder needs and responsible for outputs). It helped me think more about how to define what a product is.
North Star Workshop
I joined John Cutler’s North Star Workshop, which was full of thought-provoking advice as you’d expect. He talked about thinking of north star metrics as a constellation of connected metrics where “Great thing… is a function of… what the different teams input” and how the north star metric is a leading indicator of sustainable success (because revenue is always a lagging indicator). North star metrics very much fits the positivist ontology, which I’m still not entirely sure I agree with. I think the ‘product’ bit of ‘product metrics’ is fundamentally constructivist as it’s about user’s, their behaviour and how they construct their reality around the product. One day I hope to have the time to properly explore this.
Continuous learning
Signed up for all of Teresa Torres’ email courses. Now I just need to find time to read them and see what I might want to apply.
And I read/watched:
Beyond Team Topologies towards Continuous Stewardship
Sketches of future digital services in government
This is very cool. This is what blogging was made for. And Steve mentions our own Kate Ivey-Williams, which is nice too.
The Service Organisation
Started reading Kate Tarling’s The Service Organisation. I haven’t got very far yet but it sparked a thought about the units of analysis that are available for this kind of organisation transformation work (individuals, teams, organisations, products, services).
And I thought about:
pics or it didn’t happen
Documentation is great, but it’s only useful if people keep going back to it. And we know that most knowledge is tacit and can’t be documented explicitly anyway. Talking about the same things again and again keeps them alive.
Risk analysis
Thought about a different way to analyse risk. Rather than the traditional seriousness and likelihood, I wondered if we could use ‘time-to-fix’ as the risk measure. So, for a financial risk, how long will it take us to replace the money we spent if it turns out to be a waste? And for reputational risk, how long will it take to gain user’s trust if we get something wrong? Knowing how likely a risk is might be useful, but it doesn’t really help us decide if the risk is worth taking. Making the consequences of risks tangible might help us make better decisions about which risks we accept.
Homonyms, huh?
I remember being in a show and tell once where the question, “what is service design?” was asked. As the conversation progressed, an IT colleague said that IT had been using the concept of service for a long time. The conversation ground to a halt because it was clear that although they were using the same word, they were using very different meanings. This is the problem with words like service, product, etc.; they have multiple meanings, none of which are wrong, but which no one can agree on. That doesn’t mean we should stop discussing them, but we have to accept and make clear to everyone that to have useful conversations, we have to accept that there isn’t a single definition to be reached. And as always, we should start with understanding what we’re trying to achieve anyway. If a definition of ‘product’ is the solution, what’s the problem…?
Most of my work this week has been over there in the Later space, a bit for what’s Next, and only checking in on the Now work as the team don’t need me there, which is great. Among others things, that meant I…
Started trying to understand the Service Standard and map our work to it. Getting advice from the product leaders chat group was really helpful for thinking through how it works in practice.
Did an ‘Intro to OKRs’ presentation for the marketing team. I really enjoyed it. Sometimes I hate presenting and sometimes I love it and get a lot of energy from it. Perhaps I need to think about what makes situations different and change the energy sucking ones.
Had a chat about responsibility, accountability and other vague terms. My thoughts are you can’t say someone is responsible for something unless you also say, “what do we need to provide for that person to be successful in being responsible”.
Designed a workshop for product managers to analyse their day-to-day activities and understand whether they should be doing them and whether there are things they should be doing but aren’t. I’ll be delivery it next week so we’ll see how far we get towards our goal of narrowing the gap between how things are and how the team want them to be.
Had some thinking time on what success looks like for an organisation-wide capability product that is never finished. My first thoughts are a balancing of user outcomes & OKRs to show we’re working on the right things, delivery status to show how much is done, service standard assessment to show the quality, and financials to show ROI.
Had one of those last-thing-on-a-Friday-afternoon meetings where lots of things click into place and become clearer. It’s going to be on my mind for a while.
User-centred prioritisation
Went to Product Leader’s discussion on prioritisation where the main theme was around helping people have good conversations because prioritisation is really just negotiation. It’s interesting how we use things like prioritisation frameworks to distance ourselves from those conversations, to make things seem objective and ‘fair’.
I read:
Scoping and Shaping For Success
John Cutler’s mini-book is a collection of thought experiments, mental models, reflection questions, and actionable activities. And it doesn’t contain the word “briefing” once.
Succeeding with OKRs
Read a bit of Allan Kelly’s, Succeeding with OKRs after I’d done my presentation to try to validate how I think OKRs might be best used.
Agile Time Machine
I love stuff like this Overview of the pivotal moments and momentous ideas worth spreading again, and a general feeling of the original essence [of agile].
Better decision making
Top insight for product managers is when Annie is talking about parenting. “Nevertheless…” is a better response than “No”.
I thought:
Some problems aren’t worth solving
In an ideal world we’d be able to make everything perfect, but over here in the real world we have to accept that is never the case. This is where, I think, we sometimes get confused when we talk about prioritisation. There’s a big difference between choosing which problems are worth solving and which order we’ll work on the solutions. If we mapped problems on an Impact/Effort grid rather than solutions, I think we’d see that lots of problems fall into the low impact/high effort (which, in my experience, no solution ever does because people are already invested in it).
Messy maps
Carrying on the theme of imperfection, I like the idea of imperfect, incomplete, messy roadmaps that are closer to the reality of our understanding, rather than the perfectly polished, everything-fits-neatly-into-quarters roadmap. Not sure anyone else would agree.
Better questions
That thing about leadership being about asking questions rather than telling people what to do was on my mind this week. But asking good questions is a real skill. Questions can do so many things; lead people to reach their own conclusions, draw out information, make sense of things. And bad questions do a lot too, they can create confusion if they are vague, out of context or badly timed. Asking better questions is number two on my list of leadership behaviours (after having more conversations with people below their pay grade).
A short introductory session to Objectives and Key Results.
What does OKRs stand for?
Orca’s Keep Rollin’ – watch out for those aquatic mammal gangstas.
Organophosphate Keratinization Roentgenography – I don’t even know what that is.
OK, Roger – Yeah, whatever, move on.
Or is it Objectives & Key Results?
Yep, you guessed it, OKRs stands for Objectives and Key Results. So if you’re here for the talk on Organophosphate Keratinization Roentgenography, you’re in the wrong meeting.
Objectives & Key Results
OKRs are a goal-setting method that enables teams to focus on what matters most, and make changes when they don’t yet know how to achieve the goal.
There are two important bits to remember there:
Focusing on what matters, and not knowing how you’ll achieve the goal.
This is what makes OKRs different to other goal-setting techniques, and what we’ll revisit a few times in this talk. OKRs aren’t about recording and tracking all the work your team is doing, only the most important work, the stuff that contributes to the big OU strategy and priorities.
And they aren’t about defining the work you’ll do upfront, when you know least about how you might achieve the goal you’ve set. You should figure out the work later, and be open to changing what work you do to achieve your objective.
History of OKRs
OKRs were introduced to Intel in the 1970s.
And Google adopted them in 1999, and has been using them ever since.
They are also used by LinkedIn, Twitter, Uber, Microsoft and thousands of other organisations around the world.
Why does this matter? So you know that OKRs aren’t some funky new fad. They have a long history, and have been developed in lots of organisations. Books have been written about OKRs. There are OKR conferences (mostly for people who don’t get out much). They’ve been shown to be a useful technique for aligning teams with what the leaders of an organisation are trying to achieve, but doing it in a way that recognises things change, we learn as we go, and we need to be able to adapt.
Why use OKRs?
Align priorities
We use OKRs at OU to help teams align their work with organisational strategy. In large organisations in particular, the day-to-day work of the teams can get disconnected from the bigger priorities of the organisation. OKRs give us a way to leapfrog over the hierarchy of the organisation and directly connect what the team is trying to achieve to what matters most for the organisation.
Have two-way conversations
OKRs provide a means for two-way conversations between teams and leaders about the priorities for the organisation and how the work the teams do contributes them. OKRs don’t work without those conversations and the shared understanding that comes from them.
Give teams decision-making autonomy
We want teams to make the decisions about what work will achieve the Objectives, after all you all are the experts in what you do. OKR’s do this by separating the Objectives from the work to achieve them.
Track the things that matter
And they focus on tracking the outcomes that matter to the organisation, not the deliverables which may or may not contribute to the goal.
What is an objective?
An Objective is an easy-to-remember, qualitative descriptions of what you want to achieve.
It’s that simple. It doesn’t need to be complicated. It doesn’t have metrics or timeframes, it doesn’t say who is responsible. It just needs to express the most important thing the team is working on in a way that anyone can get.
Example objectives
Improve the quality of leads contacting us
This is a pretty good example. It’s easy to see why it would be the most important thing a team is working on, but it does require a bit of specialist knowledge to know what leads are, and maybe what a quality lead is.
Increase revenue by 20% in 3 months
This is a pretty poor Objective. It’s too specific and includes measures. And, although challenging Objectives are good, it’s probably unachievable.
Grow email subscriber list
This is a good Objective. It’s short and easy to remember, easy to talk about with people who aren’t specialists, and easy to see what it’s important.
When writing Objectives, it’s best not to over think it, don’t try to cover every caveat or be super specific. It’s much more important to have an easy-to-remember description of what you’re trying to achieve.
What is a key result?
A Key Result is a specific, measurable metric that shows movement from what it is now to what you want it to be.
They are always quantitative and need data to report on that movement.
Example key results
Increase form submissions from 5% to 10%.
Pretty good, tells you what the form submission rate is now and where you want to get to. Could be a bit more specific about which forms.
Motivate employees to enhance customer service.
Isn’t measurable, doesn’t show how motivated employees are now or what the change is.
Decrease user journey drop-off at step 4 from 25% to 20%.
This is a good Key Result. It’s specific about where the change will happen, and the direction the change will go.
Have a go
Write an Objective and a Key Result. It can be about anything. Work. Personal life. World peace, if you want.
Try to make your Objective easily memorable description of what you want to achieve.
And make your Key Result specific, measurable, and that shows movement from how things are now to towards achieving the objective.
Here’s mine.
Objective: Run five miles without stopping.
Key result: Reduce the time between stops from every ten minutes to every twenty minutes.
What did you notice?
Writing OKRs is easy right?
It’s often much easier to write the objective if you are clear on the bigger picture, and almost impossible if you aren’t. So, my objective of running five miles without stopping only makes sense if I know the bigger picture of wanting to take part in a marathon. Without that, it’s kind of a bit random and isolated. So, when you’re writing Objectives with your team, it’s important everyone has an understanding of the bigger picture of organisational priorities.
Key Results are often much harder. They need to be able to tell us that we’re making progress towards the Objective, not just tell us whether we’ve achieved it or not, and not just tell us that with completed steps along the way. So with my running objective, I wouldn’t want my Key Results to be ‘Go to the gym five times a week’, as that’s a done/not done task, and doesn’t tell me if I’ll ever be able to run five miles without stopping. My Key Result of reducing the time in between stops tells me if I’m getting closer to being able to run five miles without stopping because I know that distance is going to take a certain amount of time, and so if, each week I can run for longer without stopping then one day I’ll be able to run five miles without stopping.
We haven’t mentioned anything about the work we’ll actually do to achieve the objective.
OKRs is a goal-setting technique that doesn’t focus on, in fact doesn’t even mention, what work you’ll do to actually achieve the goal. And there are two good reason for this.
When we focus purely on what we’re delivering, and not on what we’re trying to achieve, the work can easily become disconnected from the goal. We could be doing the wrong work and never know it. Or we could carry on delivering more than we need to after we’ve already achieved the goal. OKR’s help us avoid that.
And, when we specify our goals as delivering pieces of work, it assumes we have a crystal ball and know that particular work is definitely going to achieve the goal. Instead, OKRs allow us to deliver a piece of work, use the Key Results to learn that it didn’t help achieve the Objective, and so change to delivering a different piece of work, all without changing the original Objectives.
What OKRs aren’t
Deliverables or initiatives
Getting a campaign or a web page live is a deliverable, it might be an important piece of work to do, but it isn’t an OKR Objective. OKR’s don’t specify the work.
Everything you’re working on
OKR’s should focus on only the most important things the team is working on, those things that achieve organisational priorities. We’re all busy working on lots of different things, but we wouldn’t put all of that work into OKRs.
KPI’s or other metrics and measures
OKRs don’t replace KPI’s and other metrics that your team tracks. Those other ways of showing performance and progress are equally valuable.
What makes a good OKR
You’ll know if you’ve got a good OKR if you can answer Yes to all of these questions.
Can everyone in the team see how our Objective contributes to an important org priority?
Organisational strategy is only achieved by the work teams do. Being able to connect the work you do directly to the big organisational priority tells you it’s important work.
Have leaders and teams talked about the Objectives?
A good OKR is one that has been well thought through, socialised, agreed and accepted. Remember our earlier definition of an Objective? It should be easily memorable. Anyone in the team should be able to say, “Our objective for this quarter is to improve the quality of leads contacting us” without even thinking about it, and definitely without having to look it up in a slide deck.
Is it within the team’s control to achieve this Objective?
If achieving the Objective relies on lots of other teams to do things that might not be a priority for them, or needs someone who’s going to be on leave, or depends on a system that isn’t set-up yet, then the team’s chances of achieving their Objective are affected by things outside their control. You don’t want Objectives like that.
OKRs are really simple, but…
OKRs are really simple, but some organisations like to make them complicated.
So, things to watch out for…
Demanding team’s set OKR’s every quarter, even if the team isn’t working on something that contributes to an organisational priority, or the work the team is doing doesn’t generate any measurable Key Results. OKR’s aren’t the only, or always the best, way to show what a team is achieving.
Objectives are cascaded down and team’s told what their Objective should be, or even worse what they should deliver. Talk to other teams and leaders about teams having the space to figure out for yourselves how best to contribute to organisational priorities.
Retrofitting work that has already been lined up into OKRs. Sometimes this can be ok, simply speaking work can be converted into an Objective by asking ‘why’ are we doing this work. But it’s a bad habit to get into as it means the team is getting locked into delivering a piece of work that may or may not achieve the Objective.
OKRs in practice
Some tips and tricks for getting the most out of OKRs:
Start small, learn as you go
Start small and learn as you go. Each time you think about OKRs, you’ll come up with more questions; how many OKRs should we have, how long should we have the same objective, what if the results only show in the future, etc., etc.? You’ll figure out the right answers for you by discussing those questions together.
Impact is better than perfection
There’s no single ‘right’ way to do OKRs. If the way you’re doing it means you’re talking to leaders to get aligned, focusing on your most important work, and measuring the results to know you’re making a difference, then that’s great.
Avoid lots of process
Avoid having lots of process around OKRs. You don’t want to create an industry around managing OKRs. They are meant to help your team focus on what matters most, not become lots of work to administer. So, if you find yourself spending more time updating slides about OKRs than learning from the Key Results, then you probably should change that.
Getting started with OKRs in six easy steps
Set the objectives
Teams and leaders talk about what’s important to the organisation right now, and what the team’s objective(s) should be. The team should write an Objective they think will contribute to that priority.
Set the Key Results
Teams figure out how they can measure the change towards the Objective.
Often the data is imperfect or not available, don’t let this stop you. Try to find some data. And use this to help you identify how to improve the data so that tracking gets easier in the future.
Do the work
Teams decide what work they’re going to do to affect the Key Result. Often you won’t know for sure, but that’s the point of OKRs, they help us deal with that uncertainty, but use your expertise to come up with a hypothesis about what work you think will achieve the Objective.
Share the Key Results
Sharing the Key Results with others helps everyone ask questions.
If they didn’t change, the team asks, did we pick the right Key Results? Did we pick the right work?
If they did change, the team asks, have we done enough to achieve the Objective or is there more we can do?
Review and learn
This is the important bit. Don’t miss it. This is the team’s chance to think about the work they did and whether it was the right work to affect the Key Results.
OKRs are a powerful tool for shifting teams from focusing on deliverables to focusing on having an impact on the things that really matter, but that only happens if you are regularly asking questions and learning what it takes to make that shift.
Repeat
Next quarter, start with the Objective again. Ask, is it still the right objective or should we have a new one. If you achieved it last quarter, you’ll definitely want a new one, but sometimes organisational priorities change so always start there.
