Wall Street has awakened to the importance of developers in tandem with enterprises falling in love with software.
Wall Street can’t seem to get enough of-oriented businesses. Whether it’s Fastly, MongoDB, PagerDuty, Elastic, Twilio, or even Amazon, backed by its profit engine AWS… they’re on fire. Not so long ago, “developer tooling” was anathema to just about anyone. “There’s no money in developer tooling,” the received wisdom went. “Developers don’t spend money,” they’d continue, while pitching me on the latest, greatest replacement for legacy data warehouses. “The money is in IT.”
History hasn’t been kind to this line of thinking. It’s not that these people were dumb—it’s just that they didn’t see how much technology would pervade all businesses, requiring enterprises to get serious about maximizing the productivity of their development teams.
Looking for spare change in developers’ pockets
I’ve been involved with open source for nearly two decades, but at each company we largely eschewed trying to sell to developers (MongoDB being the exception). Why? Because while it was easy to find the budget within IT or some other functional area (Marketing, Sales, etc.), digging into developers’ pockets was generally a waste of time, or seemed so. We were early in recognizing developers as influencers on deals, but across the industry virtually no one wanted to try selling to that apparently impoverished bunch.
SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)
Developers were doubly pesky because, as then MySQL CEO Marten Mickos once said, “There are people who will spend any amount of money to save time, and there are people who will spend any amount of time to save any amount of money, and those are developers.” You could sell developers a product, but as often as not they’d try to build their own (which may be one reason we have roughly 10.2 billion different content management systems…).
Something changed, however.
That something was that “software started eating the world,” as Marc Andreessen once famously quipped. Software had always been useful for tallying up expenses, keeping track of employee reviews, and more, but a few years ago it started to gain currency as an enterprise’s most important differentiator. Or, rather, the means of expressing that differentiation.
As Lenny Pruss wrote back in 2015, “with technology now table stakes, the developer is the organization’s top power broker.” Or, as the Redmonk analyst firm might style it, “Developers are the new kingmakers.” Developers, once the pizza-eating also rans within an enterprise have become its most critical constituency, building the future with code.
Then, as now, developers are inclined to build their own tooling if they can. But now, much more than then, the pressure to deliver “right now” is intense. As Bessemer Venture Partners Ethan Kurzweil, Jenny Gao, and Sakib Dadi write of the new “developer laws,” two things conspired to convince developers to cough up cash. The first is open source:
The adoption of open source technology within enterprises translates to more teams building custom workflows and using open source software as building blocks to construct their infrastructure. As a result, we’ve seen a lot of commercial open source software companies successfully sell enterprise editions of their product that largely replace the internal work of teams that maintain open source infrastructure or build bespoke tools.
In other words, developers get moving with an open source project, but to scale it (or manage it in some way), the enterprise steps in to buy an upgraded, proprietary version so as to ensure that developer productivity isn’t lost. The second is also driven by open source, but in a different way:
Companies that build developer tools around new technologies such as Kubernetes, GraphQL and new ecosystems may find themselves selling into the broad “digital transformation” project budget instead of a clear existing budget line item. As distributed architectures become more complex, budgets for developer solutions are less about replacing exact existing line items and more focused on helping enterprises get the most out of their engineering resources, advancing innovation in the process.
In these and other ways, vendors have figured out ways to maximize developer productivity for an enterprise, with those enterprises happy to pay. Importantly, while everyone is talking aboutand more people are willing to acknowledge the importance of developers in that process, we’re just at the beginning of the developer revolution. As such, we should expect far more developer darlings to go public and make a splash on Wall Street.