As a PM, I spend a lot of time talking to engineers about product and prioritization.

A common question looks something like this:

We want to spend more time refactoring, re-tooling, and working down debt. But it doesn’t generate revenue. How do you build a business case for this type of work?* What would your company pay to double its current throughput?

• How would a 50% reduction in throughput (less output) impact your company financially?
• Assume you’ll need to “hire up” in a non-linear fashion to continue your current growth trajectory. How much would that cost?
• How is the unmanaged complexity impacting you today? Is it lowering your ability to deliver quality product? Is it slowing you down? By how much? What opportunities are you currently foregoing due to current throughput? What are you spending to “make up” for the fact that you have trouble delivering validated impact?
• How long does it take to onboard new developers? What might happen if you could halve that time? What would happen if it doubled?
• How would a major production issue impact brand loyalty, renewals, and upsells?
• Etc. What you find — when you take these questions seriously — is that refactoring is extremely valuable. There IS a business case, and it is basically fraudulent to ignore those risks/opportunities. Product managers tend to be better at pitching the value of new work, but that’s because they spend all day pitching the value of new work.

What you also find (and engineers will hate me for this) is that without carefully collecting data on throughput, defects, and the impact of your work, you’ll have no data to back you your business case. Almost all problems manifest initially as lengthening lead times and/or defect rates. New “stuff” (unquantified shiny objects, even) will always beat nebulous “maintenance” when that maintenance is not quantified. A great example here is documenting unplanned side-work … if you don’t make this work “real”, there is no way to discuss it.

And then there is pride and ego. We tend to be pretty defensive about past architectural decisions. Admitting that some past decision is impacting the business today can be a tough pill (even when the decisions were perfectly valid at the time). Transparency requires safety, empathy, and humility. If teams are punished for “pulling the cord”, they’ll stop pulling the cord.

When the transparency, safety, empathy, and humility is missing, the tendency is to gloss over the drag. Which makes the “hit” — when the trouble really starts — all the more difficult to process, and difficult to manage.

So… build the business case. Do it. Measure and reflect. Pitch the value of craftsmanship.

P.S.: Product Managers! Encourage and teach your teams to think in economic terms. Take them seriously. Prioritize apples to apples. Foster a safe environment that’s friendly to discussing the economic impact of unmanaged complexity.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities. To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!