Build or Buy. Grind or Automate

One thing I like to ask in diligence is how people in engineering and product judge the value of third-party software purchases. Sometimes these are buy vs. build decisions, but in others an engineer sees an opportunity to save X hours of time per engineer per month for $Y thousand dollars per year for the department. It will pay for itself many times over, and the question is, "Is your team is too scared to ask to buy the tool?" 

Although this exists in every company to some extent, it can be especially dangerous for companies that are facing a cash crunch or have just come out of one. It takes conscious reflection to unlearn the panic-avoidance of saying "no" to purchases based on price-tag alone, and to move towards also considering the benefits that might come from such purchases.

Engineers, and engineering managers who come from engineering backgrounds by and large have no training nor innate understanding of how to calculate the return on investment for a major tooling purchase. Engineers are just people. They will default to the patterns they're familiar with. Absent of conscientious coaching by the business side of the house the framework they will fall back is often the same one they'd use at home:

• Cheap enough to buy without asking my partner/spouse.
• As expensive as my last big hobby purchase or my laptop.
• As expensive as my car - I'm not even going to bring this up unless we've been talking about how broken down my car is for months, and it's getting more expensive to have it repaired every month than it would be to pick up a new car payment.

In any case, without another frame of reference to work off of, anything over about $1,000 is a "big purchase" and anything over $35,000 is a "major purchase," and the bigger that price tag is, the more people discount the benefits to match their anxiety about asking for that much money. Because of this, there's a good chance you have engineers right now spending time and energy on problems that have already been more than adequately solved by someone else.

I'm not suggesting engineers and engineering managers become spendthrifts, but let's look at our hypothetical $10,000/yr tool. First, a principle: if a tool saves engineering time, the saved time should be spent towards useful work. If it saves time but creates more work, then it has to balance out somehow or all you're doing is transferring cost between centers. But let's assume to continue our example that our $10k tool saves 8hrs net per engineer per month, and that we're using a standard American work-week of 40 hours:

• A fully burdened mid-level software developer is, let's say, $165,000/year or about $80/hr.
• To pay for itself therefore the $10,000 tool needs to save 125 hours per year total for all users.
• At 8hrs a month that's 96 hrs/year per person.
• That means that if the tool costs $10,000 for 2 engineers it's is a net positive.
• If it costs $10,000 for 22 engineers you've saved an entire FTE worth of time. In other words, the productivity gain should be like having a whole extra person on your engineering team.

It won't really work out quite that neatly. Dividing hours up over that many people leaves a lot of room for messiness, but the principle is still sound. If you can find the $10,000 anywhere, spend it. More importantly, teach your engineers how to evaluate the ROI on a purchase and make it embarrassment- and penalty-free to ask about a purchase.

If you have 22 engineers on your team, that's 22 people who spend a few minutes out of every hour of the day browsing the web being exposed to new ideas, tools, frameworks. Even passive research on improving engineering will yield benefits as long as people don't feel like they're painting a target on their back for making a proposal.

The other side of course is that engineering managers and directors need to be diligent about measuring the benefit of purchases or agreements. If they buy the $10,000 tool to save 8hrs of time per month per year and they're not measuring that, even indirectly, then your engineering subscription bill is going to look like a deluxe cable TV package from the early 2000's.

Factoring in opportunity costs.

The cut-and-dry calculus above is great if you have it. I remember when we went from using a homegrown and hand-maintained Jenkins setup to Gitlab. Yes, Gitlab costs money, but the engineering time that saved went directly into scaling and hardening our product, which was worth more to the company than the money we "saved" by rolling our own CI/CD system and keeping it from burning down every time our system went up a tick in complexity.

If a purchase – even a yearly subscription – is a one-time improvement instead of an ongoing one, then ask yourself whether it opens up long term gains. Take something like a charting/dashboarding library with a yearly subscription. If you saved the time of implementing a more complex open-source one, or (god forbid) rolling your own, and then you used that either to get to market earlier than a competitor or to make your MVP feel more premium on launch date, then it was probably worth it.

Even if it costs as much you expect to make in the first 18 months with the new product, you can get out there and start making revenue and eating free market-share instead of paying more to get market share from the competition. Then after launch you can pay the cost of moving to the cheaper solution.

If you're a business person, all this is obvious. If you're an engineer it probably isn't.

The only good reasons in a software company to roll your own anything vs purchasing it off the shelf are:

• It's core to your product experience.
• An adequate off the shelf solution doesn't exist.
• You can do it better, and doing it better matters to the success of the business.
• Factoring in all the costs of implementation (that means the cost of the headcount that will be dedicated to it and the cost of not dedicating that headcount towards something that's potentially more profitable) you can do it cheaper or finish it faster.
• The company selling the product is shaky or new, and you'd introduce operational or product risk if that company fails.
• You literally cannot find the cash on hand.

I might be missing one, but you can see the shape of the reasoning here.

The point of all this is that if you're reading this post from the business side of the house you may not realize that none of this is obvious to the tech side. If you're on the tech side of the house and it is obvious, consider that it might not be to other individual contributors or managers. Understanding how to account for ROI is important in all places in the business, and it's an art that people don't just "pick up" from being in the position to make decisions.