OKRs from a development team’s perspective
zafulabs.com
OKRs from a development team’s perspective
1–10 of 125 posts
Re: OKRs from a development team’s perspective
#2We've been doing OKRs at my employer for a while. It's always really difficult for the development team to come up with ideas because we know that there's a higher than average chance that we'll get pulled to work on something that's unrelated to the OKRs we've come up with; and while everyone says we're not being judged on our OKRs, _someone_ is keeping track, otherwise they're not really useful.
I'll be reading and re-reading this article for a while.
Re: OKRs from a development team’s perspective
#3Man I wish I had read this seven years ago! We tried doing OKRs on my team and it never seemed to work. We ended up just throwing it all away at the end of the quarter and listing what we actually accomplished.
And I think it was because we were doing what the author says and shoehorning in our backlog into the OKRs!
I was really soured on OKRs because of it. Now I want to try again doing it “the right way”.
Re: OKRs from a development team’s perspective
#4We've been doing OKRs at my employer for a while. It's always really difficult for the development team to come up with ideas because we know that there's a higher than average chance that we'll get pulled to work on something that's unrelated to the OKRs we've come up with; and while everyone says we're not being judged on our OKRs, _someone_ is keeping track, otherwise they're not really useful. I'll be reading and…
Thanks for another example of how OKRs aren't working for devs. A part of the inspiration to write this was that I noticed most developers feel that something is wrong with the OKR process, but they can't put their finger on exactly what.
Re: OKRs from a development team’s perspective
#5If the items in the backlog aren't related to the OKRs, then it's possible that they should be thrown our with the new cycle like the author says, but I wonder if it could mean that the OKRs need to be changed in certain situations as well. If there are things the teams value in the backlog that aren't part of any OKRs, and the dev teams are in some sense closer to the product than upper management, then that input should be filtered back up to be considered by upper management since the teams "on the ground" might be seeing information that the management doesn't have.
Re: OKRs from a development team’s perspective
#6If the items in the backlog aren't related to the OKRs, then it's possible that they should be thrown our with the new cycle like the author says, but I wonder if it could mean that the OKRs need to be changed in certain situations as well. If there are things the teams value in the backlog that aren't part of any OKRs, and the dev teams are in some sense closer to the product than upper management, then that input s…
Great point. Could definitely point to leadership being out of touch with what really needs done.
Re: OKRs from a development team’s perspective
#7Man I wish I had read this seven years ago! We tried doing OKRs on my team and it never seemed to work. We ended up just throwing it all away at the end of the quarter and listing what we actually accomplished. And I think it was because we were doing what the author says and shoehorning in our backlog into the OKRs! I was really soured on OKRs because of it. Now I want to try again doing it “the right way”.
Would love to hear if you're able to make it work by adjusting the details of how it's carried out.
Re: OKRs from a development team’s perspective
#8We've been doing OKRs at my employer for a while. It's always really difficult for the development team to come up with ideas because we know that there's a higher than average chance that we'll get pulled to work on something that's unrelated to the OKRs we've come up with; and while everyone says we're not being judged on our OKRs, _someone_ is keeping track, otherwise they're not really useful. I'll be reading and…
This seems like there isn't buy-in to the OKRs across your employer. My company does OKRs and it's taken seriously by VPs as well as the devs. Here, it's very reasonable to say no to something (and have that be respected) because it's not contributing to your team's OKRs. If it's a VP or something and insists it needs to be done then that means the OKRs need to be updated to reflect the nature of this work.
Re: OKRs from a development team’s perspective
#9This put my thoughts on OKRs into words better than I ever could. At my last two companies, I've been beating the drum that the closer to an individual level you get the less useful OKRs are. The backward process of, "we know what we are going to do, how to we make it fit the OKR formula" drives me insane.
Personally, I actually like OKRs at the organization or large sub org level. I think they are great at getting everyone moving in the same direction and letting everyone know what matters. My problem is that as you drill down into an organization you need to switch from the "Why are we doing this?" and "What are we measuring?" questions and instead as "Exactly how are we going to do this?" which doesn't really fit into the ORK structure. Personally, I find that once you get down to a group of about five people or less, creating a list of tasks is far more affective than OKRs.
Re: OKRs from a development team’s perspective
#10> Objective – Increase Customer Retention
> Key Result #1 – Lifetime Customer value increase from $N to $N+5
> Key Result #2 – Decrease Customer Churn Rate by 10%
I'm a developer on a team. How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I don't have a deep relationship to know how to add value to them.
Someone needs to do the research, analysis, and leg work of finding potential areas to exploit. And then someone needs to have at least some amount of vision or inspiration about how to solve that problem. Or do whatever trendy new "design sprint feedback loop" brainstorming session someone is tweeting about. This is the kind of stuff I hear designers and "product people" talking about wanting to do.
If you want to do that work and then loop in the engineering team to talk about feasibility and planning that seems fine, but the last time I worked in an environment with OKR no one seemed to have any brilliant ideas about how to, you know, actually achieve the Key Results.
(Until these questions can be satisfactorily answered to developers, OKRs are going to be perceived as a buzzword, flavor of the month process air-dropped in because someone saw a blog post about it)