I find many senior software and IT folks don’t know how to talk about the value of tools. I frequently get asked by peers, inside my company and outside it, why I can successfully get tool expenses approved when theirs get rejected.
This is my framework for justifying expenses to build or buy tools that “improve efficiency” for a team. Stuff that saves time and/or increases “quality of life” for individual contributors is challenging to quantify exactly, but my argument is simple: Just estimate.
Disclaimer: You need to have a relationship with your finance folks or whoever is controlling spending. This is probably easier to do in smaller companies like I tend to work in, but I don’t think it’s unsolvable even in a larger corporate setting, it’s just more complex.
There’s two rules I use for figuring out ROI of tools.
- Assume US tech labor is $100/hr. (The point isn’t accuracy, it’s a convenient conservative estimation.)
- Estimate how many hours is spent on the task / topic over the course of a year in your company (that would conceivably be saved).
Yes, it’s fine to guess! This is a business hypothesis, not an academic paper. Now you’re ready to answer core value questions:
- Is this new software subscription saving you money?
- Is the work of automating this task worth it?
- How does this effort financially compare to hiring someone to do it?
When you can confidently answer these questions and talk about your underlying assumptions, you immediately earn respect and trust from the finance & operations folks. Labor is usually the top cost of any business organization by a wide margin, so demonstrating your understanding of that and what you’re doing to conserve it means you are speaking their language.
Next, what tools did you inherit (or allow to linger) that DON’T pass this test? If you preemptively kill the tools / costs that are no longer serving their intended purpose (or that never generated the ROI you hoped) you unlock the next tier of trust. If you’re auditing your own systems, they don’t need to! You should absolutely kill the underperforming tools so that you have the credibility to ask for the new ones your team desperately wants to improve their performance.
Finally, this is how you can create very loose estimates of ROI on building new product features. Now, insert every caveat here: Everyone estimates badly, it’s always 30% more than you thought, etc etc. But at the end of the day, if you think something is going to take your team of 6 engineers an entire quarter to produce, that’s a good starting point for what sales (or retention, or reputational) expectations need to be to justify the effort. It anchors the discussion so that everyone has realistic expectations to start, even if you end up drifting from it as the situation develops and requirements evolve.