[tfrancisl]

My issue with the second one is that, as an engineer, I am almost never the one trusted with managing ROI. In r&d this just means your product people expect delivery earlier and earlier, and will accept lower and lower quality if they think it has some return for the product.

[cryptonector]

Exactly. For many software projects ROI is just not measurable the way it is for more pedestrian products. Sometimes you can estimate the cost of replacing one product with another, and then you can estimate the "value" of enhancements to the current product that keep you from having to spend the cost of replacing it. Other times you can measure happiness of your product's users but not the ROI strictly defined. Other times you can say "this project enabled _that_ project, and that project has a measurable ROI, therefore so does _this_ project". You just can't count on always having a measurable ROI.

So far the only metric I've seen that works is KTLO fraction, where lower is better, because that means with the rest of the time you can be adding value, and that value is socially determinable by asking your peers and users. KTLO fraction can't be gamed because your peer managers will call you out on it if you try to cook it. To drive KTLO fraction down you also have to address tech debt that cause high KTLO fractions, and addressing that tech debt enables value-add because between spending less time on KTLO and having a cleaner architecture/design you enable the addition of valuable features.