Dave Mangot

Dave Mangot

I help private equity portfolio companies maximize growth during the holding period using their technology organization.

An incomplete list of costs for maintaining marginal products that are not easily measurable in dollars.

With recent bear market dips, it’s a good time to shut down marginal products rather than maintain those which generate little revenue/are not the future of the company.

Often finance sees revenue, and some bills, this is what they don’t see.

  • The delay in adding the new hire to the rotation because they have to learn the oddball system.
  • The cognitive load of being on call for something that is barely tested or maintained.
  • The activity to patch and deploy something that is hard to build and scarcely tested.
  • The periodic fires that need to be put out when a customer does something unexpected or we’re the subject of a Denial of Service attack.
  • The cognitive load on the security folks for a product with known XSS, CSRF, etc. vulnerabilities that they know no one will patch.
  • The time it takes to run security scans and tests just so they are documented, not because they will be fixed.
  • The additional burden on the one SRE who still understands something about the marginal system because they’ve been around the longest.
  • The cost to bring in a developer contractor to perform one-off fixes on the legacy product because it’s been “unstable lately”.
  • The load on the project manager who still has to report on the status of the marginal product because if she does not, people might forget that it exists.
  • The additional attack surface the company is vulnerable to for a product that barely makes a profit.
  • The time customer success spends on calls for the marginal product instead of developing stronger relationships with high value customers.
  • The context switching staff must do when paged about the oddball product which takes them away from high value work.
  • The toil (deleting files, growing partitions, adding resources, etc.) that must be performed to keep the site up and running as no software runs forever without intervention.
  • The multiple contracts that must be maintained for legacy software tools (licenses, etc.) that are needed to support the legacy product.
  • The exceptions that must be carved out in new platforms and processes to account for a system that will not be modified because of the difficulty in doing so.
  • The different meaning of this term or that term in the marginal product because it was either brought in via acquisition or named before the rest of the company had standardized.
  • The additional difficulty it takes to troubleshoot problems with the product because it doesn’t use modern or standard company tooling and everyone who’d developed it has left.
  • The efforts, contracts, and manual work it takes to maintain this one product in a data center when everything else has moved to the cloud because “our monthly data center bill is cheap!” If it stays within its power and cooling allotment, of course.
  • The stress on the VP of Engineering when they hear that Shonda has been interviewing and she’s the only one who still understands that system.
  • The promise Engineering gave to the company that they would sunset the product in 3 years, but 3 years later, they are finally beginning to make progress, and it will only take 3 years (from now).

What have I left out?

Inspired by An incomplete list of skills senior engineers need beyond coding by @skamille.