OKRs from a development team’s perspective

Joe Cannatti on May 24, 2019

Most of the companies I’ve worked for in the last 5 years have used the OKR system. Although this system was invented in the 70s, it has more recen... [Read Full]
markdown guide

I don't have much experience with OKRs, but I'd be curious how to handle technical debt / refactoring tasks?
Often times I think management wouldn't care for this, but let's imagine a scenario in which they do.
How would one integrate this? Does anyone know a way to measure technical debt?


Tracking tech debt and other work that is driven by engineering is sometimes handled as a separate channel of work. For example, I've seen places where 70% of work went towards business goals and 30% towards tech debt and engineering goals. All that business really needed to know was that 30% of effort was going towards future tech stability.


Hm... Seems like a hack to me.

Shouldn't the reduction of technical dept and "future tech stability" be a business goal as well? This agreement seems to be for ease and removes some potentially valuable communication, I'd think.

Let's imagine a scenario in which the engineers want to do some big refactor, to be able to do future tasks easier, faster, more secure (add some more things if you want). Ideally, this wouldn't have to be done in 30% of the work-time but get more attention. Of course I'm not saying it should occupy 100% of efforts, but maybe raising it to 50% or 70% (depending on the refactor) might be good. And if there's fitting OKR, it would be really hard to argue for this, although it might actually be the right move to do. What do you think?

I dig it in principal and I have seen it work fine that way when companies are smaller. That approach seems to stop working as companies get bigger though. It typically gets very difficult to make the case heads up between direct business features and tech improvements. The 30% thing is sort of like a correcting function. To push things back into balance as the company grows.

While I totally agree that it's highly unlikely it'll work in a bigger company, that still means it's a workaround. I'd like to know a way to incorporate technical debt and refactoring into OKR principals (with the assumption that all parties involved understand the importance). Of course we can find workarounds like the 70-30-rule (which actually sounds reasonable, I think), but I still think there's value in trying to find a way of adapting it into OKRs in an ideal scenario, as to learn from it and maybe actually implement it at least in some way somewhere.

I personally have trouble finding a metric to measure technical debt by, so I'm curious whether anyone knows of a good one to use...?


I am in love with the idea of just dumping the backlog (or at least shelving it) when it’s time for new OKRs. In my experience an existing backlog often serves to muddle the narrative that the team is trying to form. Or worse, the backlog items often just end up languishing forever.


I encounter this same problem. My teams do OKRs but they always end up using it as a way to confirm what they wanted to work on. In fact if something they wanted to work on is not reflected in the OKR, they modify the list of OKRs.

I like your suggestion. I’ll add one more, if management incentivized achieving business goals instead of project metrics (eg velocity, on-time delivery), then I think OKRs would be much more meaningful.

code of conduct - report abuse