Understanding the Value of Dev Tools

I’m largely approaching this from the perspective of building an internal dev tool (since this is mostly where my personal experiences are coming from), especially if you’re someone who wants to build an internal tool but is having trouble framing it in a way where its value can be understood by the decision makers. I’m also excluding situations where you “have to” build certain tools to track certain information in order to comply with a legal requirement, since I don’t think that would be controversial to comply with. I’d imagine the framework for using an external dev tool, while similar, also poses extra complexity on paying vs building.

This is part of a series (The Opinionated Engineer) where I share my strong opinions on engineering practices.

Generally, the simplest way would be to calculate how much time is saved for an employee, multiplied by the cost of hiring the employee. This directly shows how much money the organization is saving by just having this tool around. Pretty straightforward, not a lot of controversy.

In organizations where engineering is considered a profit center, and not a cost center, it might make more sense to calculate it with the value generated by the employee against the time saved. That said, this is usually much harder to measure compared to the above, thus more uncommon unless the tooling itself is a direct value generator.

In a disaster recovery situation, the time is significantly more valuable than the average “engineering hours” since it’s directly affecting the bottom line of company profit or other top-line metrics (or even consumer trust of the product). Admittedly I’ve never figured out the perfect framing around this, but I’d reckon phrasing it as “used to resolve x, y, z incidents” (and if available, attach the severity level for each of the incidents to it) would suffice in clearly articulating this.

This is one of the more subjective measurements. While you can attempt to quantify it through things like survey responses, it’s important to keep in mind that the improvement will automatically become the new baseline. For example, an 8/10 last year will become a 5/10 this year, so you need to improve it even more to get that same 8/10 again this year. On some occasions, additional improvement will hit the point of diminishing returns and have very little investment value. It’s important to take notice and begin pivoting effort into better sustainability.

Depending on the level of effort, one-off use cases can be a bit of a dangerous misdirection / mismanagement of valuable resources (time). It’s sometimes hard to notice, but if it takes you longer to build the tool than to just do the work without it, or the tool provides very minimal value compared to the amount of work needed to build (and maintain) the tool, building them makes no sense. Generally, this is usually a rare problem and only exists for top-down asks because leadership might not understand the day-to-day workflow for impacted employees. Instead, we generally see the opposite where even the most valuable / impactful tools take a lot of work to convince leadership that they’re worth the investment.

Another common trap in building internal tools is the Not-Invented-Here Syndrome. This is especially true for mission-critical tools (alert paging, traffic monitoring, authentication etc.) where it would make more sense (for most companies / orgs) both financially and expertise-wise to outsource them to dedicated product experts in the market, making “buying” a better option than “building”. “Buying” here doesn’t necessarily mean monetary purchase either. For example, if your team begins scaling your code base and needs a large-scale cross-stack build tool, it would make more sense to adopt something like Bazel or Buck instead of building your own new build tool from scratch.

Understanding the value of dev tools requires matching your measurement approach to what resonates with your organization’s priorities. The goal isn’t just to justify building tools, but to build the right ones which can sometimes be as simple as buying an existing solution or accepting a manual process.