> good luck as an engineer explaining how and when exactly your investment in developer tooling is going to make the company $10M in Q2. My experience is that

> good luck as an engineer explaining how and when exactly your investment in developer tooling is going to make the company $10M in Q2. My experience is that most engineers don't try, because they don't tend to speak finance. A lot of developer tooling is roughly quantifiable; this tool saves X minutes while doing Y, do a little survey to see how often people do Y, multiply Y and X to get time saved per year. Divide X*Y by the number of work minutes in a year, and you have the number of man-years saved. Multiply that by the average salary of an engineer, and that's very roughly how much the dev tooling is "worth". It's not a precise answer, because 50 employees saving a couple hours of time a week isn't the same as having another employee, but it's a workable approximation. > the solution was to invest in the problem proactively starting 2 years earlier, and now that you're so late it's going to take 4 years to solve the problem because you have to first deal with all the debt you accrued. This can also be roughly quantified. Get rough numbers on the resources required to fix the problem now. Look at what's coming for the next year or two in terms of projects and infrastructure that will exacerbate the issue, figure up roughly how much effort it will take to fix those. Convert that effort number into salaries, and you have a rough idea of what the cost of delaying the fix is. If you're worried about tech debt causing a catastrophic failure, figure out what that scenario looks like, calculate up the concrete costs of the failure (SLA violations, refunds, etc), then have another column for potential costs like regulatory fines, and a third column for things that have costs that the finance people are better suited to handle (what's the cost of reputation loss?). Again, it's unlikely to be completely accurate, but it gives you a data-based platform to speak from. Even better is to engage the finance department to help draw up those numbers. Money is their forte, and calling them in to help with money questions is the same as calling in the frontend people to help with React or whatever. I think sometimes we engineers spend too much time around other engineers and get too comfortable speaking in terms of engineering priorities. Those don't extrapolate; finance and legal don't give 2 shits about "flaky unit tests". We have to convert those engineering priorities into other teams' priorities if we want them to care. Finance cares about money, so rephrase the engineering problem into a money one. Legal cares about liability, so rephrase the problem into a liability.