OKRs from a development team’s perspective

This is interesting. I wonder how much of a depressing effect throwing away the backlog every time will have on contributions from people on the team who have good ideas but are not super vocal, e.g. "what's the point of saying my ideas when they'll just be thrown out next time we do planning?"

Yeah, this wasn't at all what I thought it would be about, which is the difficulty (impossibility?) of measuring developer impact against key results.

When you're a salesperson, you don't have to agonize over how to illustrate that you've "Decreased Customer Churn Rate by 10%". When you're an assembly line worker, you don't have to find a way to figure out how you contributed to "produce 15% more widgets". You either accomplish these things or you don't - they are literally descriptions of your performance in your job. Either way, nobody cares how you did (or didn't) do it.

When you're a developer, how are you supposed to show that you've helped "increase customer value from $N to $N+5"? Because "shipped the new version of the message queuing system" is not in anyone's list of key results.

OKRs feel like "organized SMART goals", and so I have the same criticism of them as I do of SMART goals: they're just another way of conceptualizing goals around things that are already easily and directly measured. No one has made any progress in quantifying the contributions of roles that don't have direct percentage impacts on dollars earned or dollars saved.

> 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.

Most design decisions you make as a developer affect the value users get from your product, and therefore the churn rate. Sure you can get more useful data by talking to customers, and you should seek it out. But even lacking that, it's up to you to put yourself in the place of a user and make the most practical decisions available for their benefit that your powers of intuition allow. You don't get to say, I don't have the best possible data for that choice therefore it's not my problem. It's still your problem.

Leadership is hard. Gaining alignment around goals is hard. Even if you state a goal, getting timely execution is really hard. OKRs are great in that they are specific and measurable, so you can have a concrete conversation on if performance is adequate.

The problem with OKRs is goals can be hard to quantify, so it's attractive to simply make OKRs out of things you CAN measure. This is why we get companies that optimize for clicks at all costs, and twitter accounts that buy followers.

If you're thinking about backlog bankruptcy, it's probably because your team is considered to be struggling. If so, it's attractive to think the process of delivering on the OKR is the problem. However, in my experience the real problem is that leadership hasn't done a great job of defining OKRs that properly align teams on the mission at hand.

But good luck telling that to leadership.

I work at at company that does OKRs as well. I think I've viewed both the symptoms you described and the common pattern described in the article of fitting an existing backlog to OKRs.

I think one observation that I have is that OKRs are really a framework to help teams understand what direction/goal to head to and understand progress toward that goal. And really, this mindset needs to be adopted not just by the development teams-- it needs rigor and consistency from leadership as well.

For example, the leaders are accountable for setting direction and describing what they think is important. If they then start asking you for things that aren't tied with an OKR, it's a perfectly fair question to ask leadership "Why are you asking me to work on this when you indicated it's not important to our company strategy?" If the team feels like they're going to be working on something unrelated to their OKRs, that's symptomatic of leadership not sending a consistent message on strategy or prioritization.

I've also seen it from the other side as described in the article. I've seen development teams really struggle to initially understand OKRs and the value. As mentioned earlier, it's really designed to help clarify direction and progress-- if a team is ignoring the OKR and fitting their backlog, that's symptomatic that they're really not trying to understand the direction leadership wants to head.

What I like about the author's suggestion is that it really forces the team to understand the problem the organization is trying to solve and think up solutions how to achieve it. Backlog bankruptcy is one way to do it, though there are likely some items that can still solve the problems outlined in the OKR. Those items just shouldn't automatically be transferred over without verifying they solve a problem that needs to be solved.

Teams shouldn't be fitting problems to work-- teams should be fitting work to problems.