3 ms·

All of these product management processes seem to assume there's no underlying maintenance or tech debt that needs some level of attention. And there almost alw

All of these product management processes seem to assume there's no underlying maintenance or tech debt that needs some level of attention. And there almost always is, but it's really hard to measure impact because it's usually "hidden" (that is, it's not a direct impact, but it ultimately affects velocity, on-boarding, developer happiness, etc). So with "tricks" like this they get relegated to "low impact", while "high impact" (typically "user facing features") get prioritized. And there's lots of other things that have hidden or very difficult to measure impacts. These often revolve around developer happiness and growth. For example, ignoring a complex, bugging and/or aging codebase can affect attrition (among other things), which will quickly get _very_ expensive: as a team starts losing developers, the remaining developers have to carve out more and more time to interview and onboard. Not to mention the direct company costs of turning over employees. And trying to find quality employees who are willing to work with in that codebase. And maybe this sort of thing should be addressed "out of band" - ancillary to the product management lifecycle. But that's really hard to maintain in most orgs.

tylerrobinson 5y ago
This is where trust between Product and Engineering is critical. Engineering must be given some "out of band" capacity as you put it, which is locked down and kept available for Engineering to perform maintenance _as they see fit_. > But that's really hard to maintain in most orgs. For engineering teams with an embedded Product Owner, this is where a good PO can really shine. Show, don't tell, the value of all your maintenance work. Yes, it's hard to show to a nontechnical audience, and yes, it's supposed to be a "safe zone" for engineers to have discretion. But you will lose your maintenance capacity if you don't show nontechnical people the value they're getting out of it. Business leaders understand productivity trends, feature cost, time to deliver, support ticket counts, and aesthetic improvements. Use this to your advantage to communicate in the language they understand, and keep your maintenance capacity.

tylerrobinson 5y ago

This is where trust between Product and Engineering is critical. Engineering must be given some "out of band" capacity as you put it, which is locked down and kept available for Engineering to perform maintenance _as they see fit_. > But that's really hard to maintain in most orgs. For engineering teams with an embedded Product Owner, this is where a good PO can really shine. Show, don't tell, the value of all your maintenance work. Yes, it's hard to show to a nontechnical audience, and yes, it's supposed to be a "safe zone" for engineers to have discretion. But you will lose your maintenance capacity if you don't show nontechnical people the value they're getting out of it. Business leaders understand productivity trends, feature cost, time to deliver, support ticket counts, and aesthetic improvements. Use this to your advantage to communicate in the language they understand, and keep your maintenance capacity.