2 ms·

I'm not sure I agree. There's two key elements: 1. If you don't properly evaluate the work and be selective with what you work on, actual engineering time will

I'm not sure I agree. There's two key elements: 1. If you don't properly evaluate the work and be selective with what you work on, actual engineering time will be allocated to too many projects. People spin their wheels working on potentially insignificant things, which is a morale killer. So thinking about the business cases was a way of reducing work, not adding work. 2. I tried to emphasize that thinking about business cases is something product and engineering management/leadership need to own, not necessarily IC engineers. ICs can add ideas to the backlog and identify opportunity, and it is the job of PMs and EMs to evaluate those ideas and sequence them for being worked on, relative to other projects. The feedback loop that is important to ICs is the impact of their work in terms of user metrics and goals the project was supposed to accomplish. I don't want to get too heartfelt about it (because Capitalism, Yay!), but there's a difference between churning out features into a black hole and knowing how your deliverables affect the people for whom you build things, and letting that continue to inform your work.

cgio 4y ago
I think we are more aligned than what our exchange may superficially imply. But to clarify, from a value generation perspective, I don’t see tech debt as something whose payoff would generate any value other than in terms of technical flexibility and long term engineering resources availability. If a tech debt item is adding a feature then it’s not tech debt. Tech debt is born out of suboptimal support for features. So the feature is in place, but not in the proper technical way (I.e. against target architecture, held together with manual processes etc.). As such my approach with tech debt is realise the value by having cadence of paying tech debt off, not being afraid or thinking too much about the value of bringing things up to date. It’s more of a keep the engine running approach, at least in big engineering organisations where that makes sense from financial perspective as they resemble more a locomotive than a car in economics of restarting vs running ongoing. I am also confident both approaches may equally work or fail depending on organisation dynamics.

cgio 4y ago

I think we are more aligned than what our exchange may superficially imply. But to clarify, from a value generation perspective, I don’t see tech debt as something whose payoff would generate any value other than in terms of technical flexibility and long term engineering resources availability. If a tech debt item is adding a feature then it’s not tech debt. Tech debt is born out of suboptimal support for features. So the feature is in place, but not in the proper technical way (I.e. against target architecture, held together with manual processes etc.). As such my approach with tech debt is realise the value by having cadence of paying tech debt off, not being afraid or thinking too much about the value of bringing things up to date. It’s more of a keep the engine running approach, at least in big engineering organisations where that makes sense from financial perspective as they resemble more a locomotive than a car in economics of restarting vs running ongoing. I am also confident both approaches may equally work or fail depending on organisation dynamics.