This approach flattens the complexity of bugs into a single value, then measures the importance of bugs by a loosely-correlated, highly-noisy signal: time in qu

This approach flattens the complexity of bugs into a single value, then measures the importance of bugs by a loosely-correlated, highly-noisy signal: time in queue. This is also why a recent client dumped a decades-long vendor in an enterprise setting that by proxy implemented this approach through a newly-offshored support team that didn't understand the product and stalled on difficult bugs until the bug reports died on the vine even after repeated executive meetings. Ask the account executive how they felt about losing out on an easy seven-figure annual renewal to a rival who won't likely come up for displacement until after the account exec retires. To add to the sting, the displacement came at a time that the role of the software product was planned for a big expansion. The tab for more licenses and the work was so high but close enough between the incumbent and challenger that it opened the door...and there went an 8-figure year for the incumbent's account executive. Decades of brand-building and relationship management down the tubes all so some support department head can show off on their scope's bottom line. We understood these were challenging problems to solve, were patient, and willing to put in the significant person-months of time it would take to help solve them. Client leadership however, was not willing to just get indefinitely shuffled onto the bug queue. We're not stupid. We know what being blown off looks like. We know when we're talking with a Regex Support organization versus a Semantic Support organization. The lag time between realizing that and acting upon it might take a few years, but once it happens in enterprise software, vendors rarely get another shot within another decade.