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.