Team Success: OKRs & KPIs

[00:00:00]
>> So let's dive into going back to 101 of Jim setting us up for that first 30 days, maybe picking it up around the 60-90 days, maybe it's within that first year of being a manager. You've kind of got the lay of the land, I'm saying kind of because you don't know everything.

[00:00:17]
But you have enough to start to think about, how do I help set my team up for success? I like to think about that in a couple of ways here, is, you're probably thinking about what's the vision for my team, like what are some of the high level goals that I should be thinking about?

[00:00:35]
And then obviously very tactical roadmaps, there's work getting done. So maybe it's you're planning for quarterly plans or you're executing on sprints, but you're thinking about the work and planning around that. So I wanna think about team vision, I think about this at a very high level. It outlines your goals and really, why do you exist as a team?

[00:01:01]
It's not getting in the weeds of well, we build this feature or we own this product. It may touch on that a little bit but it's meant to be very high level. So the people on your team know why you exist, even your partners, they know why you exist.

[00:01:19]
It should be really clear and concise at a high level, and this helps really articulate what the type of work that you do on your team. Whereas the roadmap, it's so much more detailed, it's done more often, maybe it is that quarterly time or maybe it's two-week sprints, but it's getting very practical on the actual work that you are doing.

[00:01:42]
You're outlining milestones, hopefully timelines, engineering is hard to estimate but hopefully you're able to put timelines to when things are being delivered. Who's owning it, which engineers like running that project, you're thinking about those types of things. And it does lean on the vision like what's your goal as a team, you're breaking that down into smaller chunks, and that's where I see the difference between a vision and a roadmap.

[00:02:11]
So how do you measure impact on, not as being a manager, but like even on your team's work? Ultimately, we're not just creating cool tech and features, there's a reason, there's a business, we're making money at some point in time. And so you wanna know how is my team's work impacting that business metric.

[00:02:35]
A lot of companies are using OKRs. Show of hands, who's aware of OKRs? Okay, it's few people, that's good. Who's using them in practice at their company? All right, it's a little bit, some, all right, okay. OKRs are interesting way to break down some of the work and think about it to be more measurable.

[00:02:58]
Essentially, you have an objective and then KRs, which are key results. So, for an objective, it's a little more of that high level, it's an aspirational goal. It's typically not tracked like every couple of weeks, it's a little bit longer of a term, maybe it's quarterly or yearly that you're thinking about this objective.

[00:03:23]
It's trying to help provide a direction, like a strategy that your team should be going after, and then it will be followed by key results. And the key results are breaking down into like specific, measurable time bound outcomes. And that helps track progress on how are you achieving those metrics.

[00:03:43]
You can be wrong, you might say that we're trying to make something perform 10% better and you're trying to strive for that. And you're gonna watch that metric over time to see if you're actually incrementally making it better. These key results can often change for the objective, it doesn't have to be yearly, it might be at more of the quarterly or sprint planning and that you're tracking it over time.

[00:04:08]
And each objective can have multiple key results. Mark.
>> One critique of OKRs is they're overly focused on measurement.
>> Yes, I'm actually glad someone called attention to that. That's often been my problem with it, is sometimes teams get really prescriptive or thinking about how do we measure it.

[00:04:29]
And I think there's a lot of things you should be measuring, but there are times where you're just throwing metrics for metrics sake, and that's not great. It doesn't really make sense, it's eating up a lot of your team's time and you're trying to just basically provide. It feels like process for the sake of process, and so I'm glad someone called that out because that is something that I've often struggled with, we don't need an OKR for every single thing we do.

[00:04:57]
I do wanna provide a bit of an example, especially for some of the people who are maybe not as familiar with it. I'm gonna kind of focus on one that I think is always easy as a user of an application. Performance matters, I don't want things to load slow, and I think as we're building products as engineers we don't want it to be slow for our customers.

[00:05:19]
So maybe your objective is that you wanna enhance the application performance. Pretty high level, it's not very specific, but that's what you're wanting to achieve. So you wanna then have KRs, how are you gonna measure that? Maybe you're reducing the average application loading time to under 2 seconds, right?

[00:05:39]
Something that's measurable, you can monitor that, maybe it's at 5 seconds right now, and so how are you reducing that over time? Maybe it's decreasing the error rate to less than 1%, definitely could help. And maybe you're just improving the response time on the server, maybe it's 95% of the requests served in under 100 milliseconds.

[00:06:01]
And so you can look at baselines of what's happening now, and then as you're working towards that objective to reduce or improve the performance. You can see this over time and monitor this and are we actually effectively making change. So some of the things, yeah, you can absolutely measure, but don't overdo it.

[00:06:21]
Another metric that I like is KPIs, which is Key Performance Indicators. Show of hands, who's familiar with this one? All right, are you using these today? Okay, so some of you are, that's great. They're usually ones I think about as something that you're tracking for a longer term.

[00:06:40]
It may be just something that you're paying attention to as a team for a long term. They're very specific, quantifiable metrics that measure maybe its performance or progress in a particular area. They're often tied to those operational or broader objectives, and, like I mentioned, they're on an ongoing thing, you're looking at it.

[00:07:04]
Maybe it is that you wanna keep that speed at 100 milliseconds and you do not want to exceed it. So an example, application response time. Maybe you wanna target that to maintain an average spot time from under 500 milliseconds for all critical user actions. So maybe you don't care as much for something like the account settings on some product, but you care about that first load, and you're gonna monitor that over time.

[00:07:35]
And as you're shipping new features, you don't wanna exceed that. And if you are, maybe you're going back to the drawing board of talking about how do we not do that, and that's kind of putting that baseline that you don't wanna exceed. The important one on this one is this is not something me, as a manager, think about some of these things, and maybe have suggestions on what to measure or what I think is important for the team.

[00:08:00]
But with OKRs, as well as KPIs, I wanna involve the team. Maybe there's ways that I'm not thinking about to back to be OKR, we need to improve the performance, well what are things that we should be doing to do that? Obviously engineers are gonna have better insights than me, and so I wanna include them on that, I want them to be bought in, too.

[00:08:21]
I don't wanna come top down and say this is what we're doing, people aren't gonna be as bought into that, and also they have really great insights to share.