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.
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...?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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...?