Crafting meaningful OKRs

Transcript

Cal: What’s the difference between a KPI and an OKR?

Boyd: For me, the KPI is the KR of an OKR. The distinction that I make (because I keep both) is that KPIs are things that I use to measure ongoing efforts. For example, all the maintenance that we do—we want to make sure that we’re doing enough security, those kinds of things–but those aren’t projects. They don’t have a distinct beginning and an end.

In reading the books, particularly Measure What Matters, what I found is that OKRs really have power when you are aligned with the product team. So, if you want to bring a feature to market—for example, my team right now is bringing static IPs to all of our customers—that will eventually end when we have it all rolled out. So, our Key Results are around what the business outcomes are for that project.

Of course, we’ll have to maintain those static IPs, so maybe we’ll have some KPIs around the ongoing maintenance for years to come.

Cal: What’s the business value for using OKRs?

Boyd: From my perspective as middle management, OKRs give me the ability to say “no,” and mean it, and make it stick. My leaders have agreed to a certain set of OKRs, so when the Good Idea Fairy comes along and says, “you should do this too!” I can say, no, that will interfere with me obtaining these objectives that the business wants and hitting these key results.

So, from my perspective in the middle, it really helps me to remind leadership of the cost of changing its mind. That’s not to say we shouldn’t change our mind; I think that often, without the discipline of OKRs, it’s too easy to not realize what choice you’re making in terms of what won’t get done and the value that may have had.

Cal: How do you set your OKRs for your department?

Boyd: I end up doing a lot of synthesis to figure out what the Big Idea (which comes from company leadership) might mean for the people who are doing the infrastructure work at Contrast, which is the cloud engineering team. What I’ve done over the course of eighteen months is, in Confluence, I’ll write out: I think this is what we should do, and I think this is who should be doing it. I’ll write this about a month ahead of the quarter beginning.

Then we have kind of a big brouhaha of, “hey, I think you should reword this,” or “that key result doesn’t really match what you’re trying to accomplish,” so the team gives me a lot of feedback. We keep iterating on them, and eventually they go into our OKR tracking tool, Reflektive, and that’s where we are looking at them once a week during one on ones.

Cal: How often do you set OKRs, and do you ever get halfway through and re-evaluate them?

Boyd: We plan quarterly, and that’s by edict. It drives me batty, because first of all, you don’t start something right at the beginning of a quarter, and second, a lot of things are, say, five months long not two weeks or three months long. So, the world doesn’t fit into these time buckets. But, would it be better-enough a different way to really jump up and down and make a change? Probably not. There is no perfect system.

Do we change them in the middle of the quarter? Yes, all the time, because that Good Idea Fairy does happen. You know, we had a huge customer come along and say, “I want X.” And it was a really good idea, not just for that customer, but for many other customers. But we were working on Z. But I decided it was a good idea, so I went to my bosses and said, we think we should do what this big customer wants sooner rather than later for these reasons. He agreed, and so we paused the existing OKR, and we wrote and started a new one.

Cal: How often do you check the progress of the key results against the objective?

Boyd: Ostensibly, that would be every week with each individual. But I’m horrible at that. However, once a week I build a table that shows me what everyone is working on and what everyone’s progress is. For basic things I use a kanban board on Jira. For other things, I work with my scrum master and project manager to say, hey, are we on track? Who needs help? What sort of help do they need and why? Can we get that help, or do we need to expose a risk to the business?

This ritual of using the OKR as a reason to check in often turns of problems which, when you bring them to your business and say, we’re running late because we’ve uncovered these risks, instead of people jumping up and down saying you didn’t deliver, they’re jumping up and down saying, how can I help? Which is a much more fun conversation to have.

Cal: Do you assign the key results to individuals or teams?

Boyd: At the beginning, any time we finish a project-type thing, we have a re-shuffle. I have some opinions about who should be what and where, because there are certain people that have a skillset that others don’t. Some people are really good planners, and some people are really good executors and horrible planners. So, making sure you have the right pairs at the right time is a good way to go.

So, from that perspective, I let people choose their own adventure, but I’m nudging them kind of where I want to go. So, it’s not really black and white.

Cal: How do you keep your OKRs in front of your team so they’re not out of sight, out of mind?

Boyd: One-on-ones, and we have rituals built in to our things that are project-level. When I say project, I mean that in a six sigma sense, like it has a beginning, it has an end, it has a scope, it has a schedule, it has resources. But, we’re managing and executing that in a very agile way. We’re straight kanban, and rather than setting scrum increments, we just try to figure out where business value drops can be. So maybe three weeks in we know we’re going to be able to give the business part of the value that they’ve asked for and this thing that they’ve asked us to do.

That’s a really good point for us to have a major check-in and say, how are we doing on these key results? And also to ask, do we have the right key results, now that we know more about what we’re trying to do?

So we have these organic, non-regular check-ins, and then I have the weekly ritual of checking everything and building a table for myself, and then I have the one-on-ones (that I’m supposed to be doing well, but I’m not).

Cal: What’s one thing that has changed for the better since you started setting and tracking OKRs?

Boyd: There are a lot of answers, but I would say the most powerful one was I had an engineer look at me and say, we need to get serious about this, because it matters. I believe that’s because as a team, we were making good attempts, but we weren’t really following through.

He said, we need to invest here. If we do this, we’ll be better at what we do. So we took that seriously as a call-to-action. We started investing, and we started seeing a bigger payoff.

What was really amazing about the OKR adoption to me was that once the individual contributors understood what it was doing and how it benefited them, they became really bought-in and wanted to drive it. In my mind, when change comes from the grass roots, that’s the change that’s going to stick. It’s the most powerful.

Cal: What advice do you have for a manager who is just about to roll out OKRs?

Boyd: Given that you have the level of self-determination that I did, I would say start small. I’m an incrementalist by nature, so my answer is going to be an incremental answer.

Write one team OKR. Make sure your key results really are key results. They’re not just blabber. They’re numeric, not just “did I do it or did I not, yes or no.” You can answer them as a percentage, ideally on an ongoing basis.

Then, get good at tracking that. Get good at talking to the part of the team that’s effected by that in front of the whole team. Because what’s happening is the people who aren’t directly effected are asking, well, how can I help you with that? And we can ask, how much effort did it take for you to pitch in on that objective? Because that’s going to help us tune when we add a second objective.

I was able to roll this out sort of step-by-step, and because of that we were really able to understand our capacity and our ability to say no. Because of that ability to say no, we’re known as a team that can deliver. We don’t overcommit. When we say we can get to that in a month, people believe us, because we’re reasonably predictable.

That’s not just great for my team, it’s great for the business. It’s lead to things that are almost unheard of. Now, Contrast is a rocket ship growing, right, but when the question comes along—”we’re going to grow, what headcount do you need?”—and I say two, the headcount sheet comes back and I have five positions. Why? They know I’ll figure out what to do with those people.

So, there are these amazing side effects when you work to get it right, rather than just work to get it done.