Full transcript below:

0:09 It's still a relatively new year and that means for a lot of us, we're setting goals for the next year, maybe next half, not just for ourselves but also for our products. And that's what we'll talk about.

0:38 Objectives and key results. A topic that has been talked about a lot, and I'm really excited about because I really believe that if they're done well OKRs key tool for setting your team up for success. They can be incredibly powerful and I want to go into too much detail right now about just how OKRs work and what they are. I will provide a couple of references in the show notes if you're not familiar with them yet. In a nutshell, it's a framework to set goals for your product team. They consist of your objectives, which goals for your product team, written down in simple human language, and which are supported by key results. Objectively measurable milestones you need to hit to make progress towards your objective.

1:37 Now, while they're incredibly useful, there are many pitfalls to setting, maintaining and meeting OKRs. So I wanted to summarize a few lessons that I've learned while dealing with them in the past.

1:57 Number one is sticking to the order of things. The hierarchy in which you are certain elements of objectives and key results is really important. And one key point of that is before you're setting the objectives for your product, if you're operating a large organization, make sure that the company or department has set the objectives and key results on the sort of next higher level. You need that in order to align your team and make sure that conversations don't go abroad, but also just to simply make sure that your objectives are actually helping drive your company forward in the way that you and everybody else around you once.

2:52 Then, next level down, you set your own objectives and then you look at your key results. Not the other way around, I think a problem that can often arise is that teams or you know, individual team members can come up with things that they think are important, and they're excited about, and then they try to sort of shoehorn that into some kind of objective heading. That's not the point of the exercise. It's very important that you get this order of things, right, and that the key elements trickle down throughout your company throughout your department, within your team and then to a person's individual tasks. If you don't work in a large organization, and you don't have any sort of dependencies and higher levels, like that, then make sure that you've done all the pre-work so that means things like setting a product mission, the line everyone on What you're fundamentally trying to achieve.

4:04 The next point is one that is written about everywhere, but not a lot of teams really do is that you're okay or should be set by the team that is responsible for themselves. It shouldn't be dictated downwards that has a couple of reasons. Again, it's covered quite well. It often has to do with making sure that they are actually achievable, that they're realistic, but also just to give the team accountability and share responsibility. And that goes a far way in making them excited and engaged in actually driving those objectives forward. Something that is superimposed from the top down is often running the risk of feeling like a burden rather than something exciting or aspirational to work towards. So make sure your team sets the OKRs themselves, and specifically, all the team leads for the various disciplines. So, for example, that might be the design lead, the tech lead, the product manager on the point of cross-disciplinary ownership. Another point is that owners don't have to own the key results that happen to mostly sitting in their domain. So what I mean with that is, for example, if you are a software developer, then you can absolutely on a marketing objective if you're in a small team, and you know that's most conducive, that's totally fine. Just because you own a key result doesn't mean that you need to actually execute all the work. It just means that you're the one who's responsible and accountable for making sure that it's being progressed, and that it stays on track, that you meet the relevant people, and that everything that needs to happen to drive this key result forward does actually happen. Just because you own a key result, you don't need to execute it. And so what's more important is that roughly the number of key results is divvied up by team members. So if you have, you know if you end up with 12 key results, and you have four members in the team, then everybody should more or less be accountable to three. And again, that's to encourage that sense of shared ownership and to make sure that everybody feels equally responsible for long term success of the product.

7:14 The next point is kind of on semantics. Words are really important when setting OKRs. You're trying to keep them really simple and the more simple you're trying to make something, the more work has to go into actually making it simple. Especially when it comes to objectives, make sure they're as understandable as you possibly can. objectives should be shareable across your whole company and everybody should be able to read them, understand them, make deductions as to how your objectives might relate to theirs, and that's why it's really important that if anyone without any further provided context reads your objectives, they need to be able to understand what this is about. Key results tend to be a little more technical, and that's more relevant for the execution side within your team. But the objectives themselves - you need to try to keep them as simple as possible.

8:19 You also want to make sure that they are actually outcome-focused and ideally about users. If you're attempted to set an objective, like drive adoption of product x or whatever, ask yourself why you would want to do that. Maybe a better objective might be something like improve your customers’ ability to perform a key business operation.

8:50 The last really important point is to maintain your rituals. One thing that is really common is that various practice This is are being read about and then maybe adopted or tried out and product teams, and just implementing a piece of software or a certain type of Kanban board or whatever it is, and they think that it's actually about the asset. But it's really not, it's equally about the rituals you build around them and making sure that you maintain all those things that you're creating in a way that it becomes part of your team's culture. So when you're getting started with OKRs, so maybe you've kind of dropped them a little in the past, it was probably because of this, that the rigour to actually go through with the rituals of sharing them publicly, soliciting feedback, reviewing them regularly, scoring them, all of those things that are part of the OKRs that they haven't been done properly. So maybe even before you finish your OKRs, set up those meetings, book those rooms, and make sure that those regular check-ins happen.

10:15 All right, and this is it already for today. As I mentioned before, there is so much more to be learned about OKRs. But I hope you found this little summary useful. It's just a couple of points that have come up. In my experience time and time again.

10:34 I hope you enjoyed this episode, please let me know what you think if this was useful, or if not, maybe I missed anything that's really important. Please let me know. You can reach me at Twitter @Thomas_Essl or by email at hello@thomasessl.com. Don't forget to rate and share this podcast I would really appreciate it and thank you very much for listening. Till next time!

Transcribed by https://otter.ai