As a middle manager at a high-growth startup in ~ 2018, I remember being told that, actually, yes, I should take charge of the negotiation of a multi-million dollar software contract that my team needed for our work. When the sales rep I was working with learned this, his eyes lit up because he foresaw a nice fat deal with good terms [1]. Far from being unusual, this was very much the norm, and in fact, the contract was straightforward compared to the ones my peers managed that were far larger. Internal guidance at the company was that if a particular software was seen as making it possible to hire fewer engineers or unlock productivity, it was likely a sound investment. In the second decade of the 2000s, when money was cheap and tech was booming, engineering bandwidth was the most significant constraint. Engineering salaries were high, hiring was competitive and had all of its associated costs, and the engineering function was often the most expensive line item in a SaaS business's budget. In this world, investing in everything that made engineers more productive and required hiring fewer engineers made sense.  This sales motion, where engineers were directly sold to, was extremely common.

To summarize, in the ZIRP era, the adoption process for new developer tools was often as follows: A motivated engineer investigates a good tool, evangelizes it internally, and, with sufficient interest, it gets adopted and slowly works up to an enterprise license tier. The engineering champion ropes in someone with the authority to negotiate and sign off on a contract, but adoption is typically controlled entirely within engineering, with finance providing light oversight.

Product-led Growth (PLG) is a strategy that works particularly well in this environment because the users, champions, and buyers substantially overlap. ZIRP was great for many reasons, but it was particularly good for developer tools.

Metrics for startups have changed

The primary rule for all venture-backed startups in the ZIRP era was growth at all costs. Margins were a factor, but only if growth was starting to plateau. The rule of 40 was something you needed to get close to only when heading toward an IPO. Particularly if growth numbers were very healthy, investors would be willing to overlook this. In this era, the rule of 40 is gaining more ground for both private and public companies. It’s no longer either but “both,” growth and healthy margins. A new metric that is emerging is the Rule of X. 

Developer tools in the post-ZIRP era

PLG and selling to developers still exist in post-ZIRP. But there are many more checks and balances. Depending on the contract size, you are no longer selling only to the engineer but also to all the layers of their management and the head of finance. Customers must be nurtured for longer sales cycles, and products must truly stand out in the market for users to incur switching costs. A new product must often be both cheaper and better than an incumbent to allow a switch. Today, every CFO has already looked at all the scattered spending across their organization and asked teams to consolidate to fewer and cheaper software contracts. This pressure is not going to let up any time soon.

These are things that make sales harder for dev tools in this environment.

1. Availability of a viable open-source version, i.e. free. The change in macroeconomics means open source is undergoing its own massive shift, and it remains to be seen how it will shake out. However, engineering teams will be asked to use software that still has a viable open-source license before trying a paid version.
2. The tool directly affects the buyer’s margins, i.e., it counts towards the Costs of Goods Sold (COGS). Usually, development productivity tools are not counted towards margins, but anything that helps put your product in users' hands counts towards COGS and Margins. In this category, the growth of the cost of this tool matters. For example, a line item that grows faster than user growth is entirely unsustainable. 
3. Distribution pressure: If your competition is a good enough tool that is sold as part of a bundle or a platform, sales are much harder. This matters more when selling to a function such as finance, which will find it easier to negotiate better discounts and manage bundles of tools and is less likely to want to manage a long list. No one gets fired for buying IBM (today, it’s usually AWS, Microsoft, etc.).

Where can value still be found?

I’ve talked previously about the great unbundling of the cloud. There are many companies that are yet to be built that will provide enough clear value and differentiation as part of that unbundling that aren’t beholden to the constraints I mentioned above. The area of automation of engineering operations is particularly rich. Engineering velocity matters even more now in a world with a push to do more with fewer engineers, teams are tightly constrained, and margins even more so. Building software that absorbs undifferentiated toil will be more valuable than ever. In developer tools, AI's infrastructure, security, and compliance applications are emerging and promising. Engineers still do a lot of manual toil in these areas, requiring a lot of pre-existing context. There are a lot of startups in the space, so I won’t try to name any particular one or make any bets. But it’s still a great time to build in the infrastructure and development tools space if you adapt to the new reality.

[1] In this case, I was determined to prove the sales rep who saw me as an easy target wrong, so I negotiated hard for a pretty competitive deal .