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...?
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.