VC Perspective on Developer-First Companies
Ep. 8: Tyler Jewell, Managing Director at Dell Technologies Capital
Moesif’s Podcast Network: Providing actionable insights for API product managers and other API professionals.
Joining us is Tyler Jewell, a Managing Director at Dell Technologies Capital. Before that he was the CEO of API Management platform company WS02. As an investor he’s placed almost $150M in DevOps companies and is a self-confessed geek in dev tools, devops, infrastructure and dev platforms.
Tyler gives his perspectives on investing in developer-first companies, what single trait most successful companies share, why developer joy is important and many more.
Derric Gilling, Moesif’s CEO, is your host today.
Listen to the episode on SoundCloud above, download it on Apple or Google, or watch it on YouTube.
Table of Contents
- 0:37From BEA to Dell Capital
- 3:17A Trillion Dollar Ecosystem
- 5:35Open Source Project Experience is Key
- 7:05Different Metrics for Cloud vs On-Prem
- 8:00Continuously Build Relationships
- 9:51Authentic Developer Experience
- 12:00Aim For Emotional Dev Responses
- 13:30Dev Tools Cycle Every 15 Years
- 16:50APIs Disrupt Brick & Mortars Like GameStop
- 20:43Plaid Wanted Out
- 23:13Contracts Beats Pay As You Go
Derric Gilling (Moesif): Welcome to episode eight of Moesif’s APIs over IPAs podcast network. I’m Derric Gilling your host today and the CEO of Moesif, the API analytics platform. Joining me is Tyler Jewel, the Managing Director at Dell Technology Capital. Before he was the CEO of API Management Platform company WS02. As an investor he’s placed almost $150 million in DevOps companies and is very focused on developer-first companies out here. Happy to have you here today.
Tyler Jewell (Dell Capital): Good afternoon Derric.
From BEA to Dell Capital
Tyler is a 25 year veteran with expertise in enterprise infrastructure, operations and investment experience, and joined Dell Capital to focus on investing in developer-first companies
Derric: Cool. Well just to kick things off, would love to hear your story from starting off as CEO of WS02 to managing director at Dell Capital.
Tyler: You know, I started in the software industry about 25 years ago as an engineer and then moved into product at some large publicly traded companies, BEA and Quest Software. Along the way I got opportunities to run companies as well. You do the big company leadership thing and then you have some ideas and you go off and do some startups. I was CEO of a small media company that had been started by Ed Roman. And then eventually got bought by TechTarget, that was in 2004. And then, after my second stint a large publicly traded company, I started my own company in 2011 called CodeEnvy. CodeEnvy was a cloud IDE, cloud developer workspace, at a time when it was not really a well regarding category. We grew that business over five years, and that was acquired by Red Hat.
One of the investments I had made in 2009 was WS02. I had been on the board for a number of years and that company had grown up pretty nicely, and the founders asked me to come and become their CEO. So I took over the reins and was CEO for a few years. I took that company to scale and made it profitable, with over 600 employees now around the world, it’s one of the largest open source companies by revenue. All along the way I’d been doing investments either as an angel or as a VC, been invited to participate and made about a dozen investments all in developer related businesses - Sauce Labs, WS02, CodeEnvy, InfoQ, CloudInt, APPHarbor, ZeroTurnaround and bunch of others as well. And then Dell came knocking. They were a really well regarded VC unit, who had been looking to expand the partnership. They were looking for somebody who had expertise in Enterprise Infrastructure, had been an operator and had investment experience. And so it was just a great combination and then a super group of people, and so I decided to make the leap.
A Trillion Dollar Ecosystem
Today there’s 900 developer-led or developer-focused companies generating revenue
Derric: Super awesome to see having that operator experience, along with an investing site, even from your personal angel investing. We’ve been noticing that pushed out this new developer-lead landscape back in 2020, what was the motivation behind that and can share some of those insights?
Tyler: So, I think early on in my career 20 years ago, when I was starting to work on developer tools and in and around developer businesses, the common refrain was that there’s no money to be made in in developer-owning businesses. I still think that that’s probably a common attitude that a lot of people have about it. And so, I’ve always been on this march towards getting the broader investment business and technology ecosystem to have a stronger appreciation for the value that developers, and developer based businesses, can bring to the table. And in order to do that I think that a lot of people just don’t recognize how how big that market space is. And so, as part of my just kind of daily reading routine I’ve been slowly collecting all the products, at least commercial-based products that I think fits somewhere into this landscape, that were developer led or developer influenced, and I had been building that up for over a decade. And I finally said “hey, might as well publish it”, and I bet you people would get a lot of value in seeing just the raw number of companies and products that covered this ecosystem.
It turns out it’s about 1,200 commercial-based products that generate revenue in some form or fashion. Most of those are probably across 900 or so companies, all of which have raised venture capital, or you know, in some cases bootstrap themselves. And it’s generating almost across all those products together about $40 billion in annualized recurring revenues. And so, if you think about all those businesses that are either started by a developer or they make products bought by developers or heavily used by developers, just the raw influence of the developer ecosystem is really significant. It may now account for well over a trillion dollars of value out in the marketplace. So it was just an exercise to get the rest of the ecosystem to see the world, and have a positive affiliation to it, the way that I have.
Open Source Project Experience is Key
Venture capitalists often look for open source experience in the founding team, i.e. maintaining and growing a community in and around an open source project, since it’s comparable to having commercialization or classical go-to-market experience
Derric: Oh, over a half a trillion dollars in value that’s a quite a bit. When we look at Twilio itself that’s half a billion dollars. When it comes to looking at founders, is there anything that you notice different in terms of developer-first companies versus more traditional sales company?
Tyler: Well, you know develop-led businesses are almost always started by engineers. That engineer may or may not have commercialization experience, go-to-market experience. So, you have to work a little bit more to you help them build a team that’s going to be able to balance out the strengths that they bring. Now what’s interesting is that a lot of developers that are starting businesses today, they may not have commercialization experience, but they do have open source maintenance experience. A lot of the process of maintaining and growing a community in and around an open source project, is very similar to the skills necessary to building out a commercial organization as well on that front. So, the balance is increasingly there on that front. And you know that’s kind of the biggest components of what you see.”
Different Metrics for Cloud vs On-Prem
Focus on the business metrics pertinent to your type of business: if you’re building a cloud-based product, focus on SaaS metrics, or if you’re building an on-prem product, focus on classic ARR, quota coverage, CAC
Derric: Does that mean you think about acquisition and go-to-market strategy differently when you look at these different companies, or is it roughly the same metrics like ARR and sales funnel?
Tyler: The metrics that are appropriate for a business depends upon the type of business that they’re building, not all businesses are the same. So if the developers are building a cloud-based business, yeah you might work with SaaS metrics on that front. But if it’s an Open Source business or Open Core business, there might be other metrics that aren’t so much SaaS metrics but related to classic ARR, quota coverage, cost of customer acquisition, things of that nature that are a little bit more oriented to that on-prem sale. Along with recognizing that both of the open sources is the top of the funnel and so there’s a whole series of DevRel, developer relationship, metrics that you’ve got to incorporate as well.
Continuously Build Relationships
If you want your company to be successful really invest in networking: for engineering talent, to acquire early customers, or for business development opportunities, and don’t obsess over inward issues like product or hiring.
Derric: When we look at the consumer world, the Hotmail hack where something’s sent from Hotmail or something’s sent from my iPhone, have you seen any go-to-market hacks that have worked in the developer landscape?
Tyler: You know I don’t really think there’s anything you can do to hack. What I will say is that, regardless of whether it’s a developer-focused business or anything else in the enterprise-software space, a lot of the difference between the companies that are successful and those that aren’t, is the ability to network and hustle on behalf of the founders — whether it’s networking with amazing engineering talent, or networking to potentially acquire early customers, or networking on a business development front. Those founders who really invest into continuously building relationships have a tendency to perform better than those that obsess about just product or just obsess about hiring their people and kind of have a little bit of an inwardly view.
Derric: That’s a really good point. It’s easy to get buried into product itself and think about developer experience, but people are still people, even if you’re a developer. So how you make those relationships and push forward is always important.
Tyler: Yeah, I think that it’s very rare for somebody to get inbound interest for something. Innovation and interest in what you’re doing tends to come from people just knocking on a lot of doors and sharing what they’re doing, and then finding people who share the same values. And people who share the same values have a way of gravitating towards each other. But then you’ve got to nurture that and then grow that, and grow that, and next thing you know you’ve actually got a legitimate business there. But, that basic exercise is something that founders have to learn if they don’t have.
Authentic Developer Experience
Provide an authentic developer experience by transparently blending your service into their existing workflow, without forcing them to learn something new
Derric: Definitely. And when you think about things like developer experience and being empathetic towards developers, how do you actually get it right. Sometimes we see companies that did just get it somehow and then there’s another company that’s not really developer first.
Tyler: The thing about developer experience is that it all comes down to engagement and loyalty from the developers, and developers will give you engagement and loyalty if you give them an authentic experience. So everybody goes “okay, well what’s an authentic developer experience”, and the thing is there’s no way to measure that, it’s not scientific, it’s part art it’s part science. But, what I can tell you is that developers know right away when something isn’t authentic. I’ve tried to do my best guess at kind of describing what makes something authentic and it’s any sort of you solution that blends itself into an existing developer workflow. So if you have a developer and there’s something that they’re doing on a regular basis, while they’re writing code or another part of a task that they’ve got to do, if there’s a way for you to just transparently blend in to that and then still deliver your solution through that without forcing them to learn something else, that tends to be a great authentic experience and then that drives a lot of value.
We saw that with Heroku, you know Heroku was just to Git push, so were you already using Git, so you just blended into that. We saw it with Snyk, you still do a pull request, you don’t have to change that, but Snyk started adding a lot of static analysis and upset testing capabilities. Even to a lesser degree VS Code, VS Code made the plugin model just so transparent that you don’t even have to know that you’re installing plugins, it’s just kind of starts adding these values as you start writing code because it can infer what you want from that. So those are really great examples of how engineers were really thoughtful about not not bending the existing experience too much and adding value at the same time.
Aim For Emotional Dev Responses
Look for developer joy, where developers talk about your product emotionally, as a measure of your DevEx. More contributions or downloads of your project are usually just an early indicator of good DevEx.
Derric: Funnily enough, I was just going to ask how do you actually measure this developer experience and, you’re right, it’s hard to measure. Is there any high level things that you can be looking at to just get a sense or a pulse of developer experience?
Tyler: Look, there’s the obvious things of which projects are getting more contributors, which projects are getting more downloads and stuff like that. I think that’s a proxy, maybe an early indicator, that there’s a great developer experience there. But, frankly, the thing that I look for is a certain amount of joy. If you spend 20 minutes with a developer talking about a certain technology, there are those things that developers talk about scientifically and then there’s other things that they talk about emotionally. You’re looking for the emotional ones.
Derric: The Vim versus Emacs?
Tyler: That’s a whole different discussion. They’re both authentic experiences that’s just more developer geek, because there’s certain trade offs that developers are going to argue to the end of time and Emacs and Vim are the personification of those trade offs. You know, frankly, those trade offs that they advocate, can show up in distributed computing platforms, or blockchain architecture, pick a domain, it doesn’t matter. those same sort of problems materialized in other ways. I think Vim and Emacs are just an easy way for developers to get those arguments out on the table.
Derric: I guess we’re seeing it in everything from REST to GraphQL out, no SQL to SQL, you always have to have a debate, right?
Tyler: They always have to have a debate, yeah. Wouldn’t be fun otherwise.
Dev Tools Cycle Every 15 Years
Dev tools go through massive waves of bundling and unbundling every 15 years, where Git in 2005 turned everything into distributed version control, now GitLab, a highly opinionated single platform, is increasingly expanding to provide a one stop shop with tool sets
Derric: So where does this take us in a couple years with all of the No-Code/Lo-Code solutions out there? Does that mean developer experience is different, is it changing, will look the same as today?
Tyler: I think that we’re going to see a re-platforming of developer tools over the next decade or two for a couple of fundamental reasons, but that’s not driven by a Lo-Code. I think the Lo-Code/No-Code enthusiasm is really just solutions unlocking the ability for both developers and non-developers to build a class of applications that they couldn’t build before. If you need to actually sign and write code and go through a whole lifecycle tooling process, the application has to be something really special for you to invest all that time and energy to build it that way. So there was just over the past 30 or 40 years a whole category of applications that people really wish they could build, they just couldn’t afford to do it because it was too costly to do with a code structure on that. And you just don’t need the power and control that writing it with code is. So I think now Lo-Code systems enable you to unlock those costs of applications and as a result, it allows more people to do application development, because they don’t have to have the same skill set. I think that we’re able to see those systems because there’s now so many APIs, and those API is a pluggable and so the reusable, and so these systems can really make it easy to wire those things together.
In terms of the developer experience, over the past 50 or 60 years the DevOps community has gone through massive waves of bundling and unbundling, and it takes about roughly 15 years per wave. The previous 15 years was a massive unbundling effort and the unbundling happened on a paradigm shift, and the paradigm shift here was the introduction of Git in 2005. Git turned everything into distributed version control and so really the whole tool chain has been reinvented along those concepts and we’ve gotten lots of individual silos. We’re now starting to see evidence that there’s going to be a great re-bundling of all that. GitLab is a highly opinionated single platform that really tries to offer a consistent workflow. GitHub is increasingly expanding from the left to the right to provide a one stop shop with tool sets. And even vendors like JFrog and Docker, because they are systems of record for all the dependencies that you need to work with, either they can build really tightly integrated broad reaching workflows that bundle things together. So I think we’re on this path of this massive bundling. And then we’ll go through another unbundling exercise and maybe 5 to 10 years, probably driven by edge. Where the idea of building applications on the edge is just all developers are going to have to understand a form of eventual consistency that they just don’t have to worry about in cloud-computing architectures. And I think most of the tools and systems that we have today are really not well suited for that, and so there will probably be a rethink again on that front.”
APIs Disrupt Brick and Mortars Like GameStop
The new investors in GameStop are designing a set of APIs for the distribution of games, they’re digitally transforming a brick and mortar that’s losing money hand over fist into software company
Derric: Really interesting to see what happens in the next few years here. We’re already seeing quite a few different folks leverage stuff like Moesif in the edge with CloudFlare workers and other stuff like that. But it’s still just the beginning days. Speaking of APIs a little more and the unbundling of things, there’s a lot of tooling right now in the API space from a focus on developers, to security, to analytics, to the deployment of APIs. How do you see APIs and the way you work with them change over the next five years?
Tyler: Well, the nice thing is that on a technical level APIs are supporting more protocols. A lot of APIs are building in realtime streaming mechanisms, to get away from just the old request/response mechanism. They’re all going to be asynchronous. This will allow APIs to perform better, there’s going to be a lot more richer data that you can extract when you’re interacting with those APIs. And that’ll enable a much richer type of consumer-based application that can be built with them. That’s one of the technical trends, something that we’re going to see.
The second is that we’re seeing a lot of businesses becoming API-first businesses, which is that they’re disrupting brick-and-mortar systems and they’re doing it by building a really rich API. While we’re talking about this, something like GameStop is up 400% today. It’s all the WallStreetBets crowd. It’s really phenomenal because this company is losing money hand over fist. It’s a brick and mortar that is selling games that you don’t need to go and physically buy anymore, you can go to websites and download these things. So, by all means you know there’s this massive short experience. But all that’s happened is that there’s been new investors that have come in and said “well, you know we’re going to turn GameStop into a global one stop shopping video game digital delivery”. So it’s been digitally transformed now and it’s a software company, it’s not a brick and mortar. Sales up and and lo and behold the stock is going through the roof over the mania of that. But I mention all that because what they’re talking about doing is designing a set of APIs for interacting with games, the distribution of games, and then they’re going to retool the business in and around that. So I think we’ll see more APIs that are just disrupting these brick-and-mortar businesses.
I worry about whether startups can do a great job. A startup is unfortunately going to have to find such a niche area of APIs to deliver and they’re gonna have to deliver such a phenomenal experience that enables an app developer to just be way better. In communications, financials and content we’ve now got some mega vendors in the API space and the mega vendors have worked really hard to simplify the API and do the integrations and because they’re buying in bulk they give you relatively cheap rates. And so I think it’s going to be hard for certain types of small startups to compete in similar areas. They’re going to have to find new areas where the API innovation hasn’t happened what.
Understand Your Audience With The Moesif API Observability Tool
14 day free trial. No credit card required.
Learn More
Derric: Does this mean like things like vertical SaaS, we’re going to have these vertical APIs or where do you see the next generation API for startups going?
Tyler: I think almost all of them are gonna be some sort of vertical based APIs, because it’s that’s where the disruptions need to take places - in old, legacy business processes that haven’t been automated and that can be automated. And the API is just a simplification, behind the scenes it’s doing the automation, but the API interface is just a simplification of the process that’s there.
Derric: I’m just waiting to hear the jingle “there’s an API for that.”
Tyler: Yeah, we’re probably not far for from that.
Plaid Wanted Out
The public face of regulators stopping the Plaid acquisition, was a story of convenience. Frankly, the deal took so long that Plaid execs and investors wanted out, since with the growth that they’ve had, the deal was just too cheap
Derric: Speaking of these API-first startups though, there was some huge news that came out last week around the Plaid acquisition and the regulatory side. How’s that going to impact the fintech APIs and the overall API ecosystem?
Tyler: We’re back to the WallStreetBets scenario here. I think that the public face of what we heard, that it was a regulatory issue, was a story of convenience. Frankly, it had taken so long, six to nine months, that the $5B deal, with the growth that they’ve had, makes it just look too cheap at this point in time. So I think all things being equal, I think that the Plaid investors and the Plaid founders were looking for a way to get out of that deal. The company may very well be worth $10 to $15 billion at this point. So I think that their value hasn’t been diminished at all, I think it just reinforces how important these things are. It’s just going to keep fueling the fire on others.
Derric: That’s a really good point around just how that valuation changes so quickly, for these API-first companies.
Tyler: Yeah, they grew 50% or 60% and, in this day and age with multiple expansion, they probably doubled their value. So you might have had a lot of buyer’s remorse sitting around the table at the time thinking $5 billion was great, when we were going to be worth a billion dollars. But then you realize, jeez we’re actually worth 10. What do you do with that?
Derric: The Plaid CEO actually released a really interesting article around building an API-first company, how sometimes it might take a little while to get things going because of the integration component, but once you are integrated it’s just exponential growth right after. Does that mean founders should be looking at different things in terms of growth as an API-first company, versus a more traditional enterprise sales company.
Tyler: I think the nice thing about building an API business is that you can measure engagement really clearly. If people are using your API and they use it more often, then you’ve done something right. But if they use it and abandon it, then something’s not right, and you’ve got more work to do: either the interface is not there, they didn’t understand how to use it, or you’re not providing enough value to the integration that you’re doing behind the scenes.
Derric: What if there’s no interface? What do you measure then, just an API?
Tyler: You’re obviously metering the API. Your goal is to monetize that probably and so the number of applications that are making use of that, and ultimately paying you something, is a great barometer for how how effective the API is on that front.
Contracts Beat Pay As You Go
In billing APIs, pay as you go is a great way to get developers started and for people to find affinity with your service, but once you reach scale you often turn it over into contractualized relationships
Derric: That’s a really good point around metering the API. And then when it comes to billing we’ve seen this huge trend over the last couple years towards the pay as you go model. A lot of it was driven by AWS Lambda, we’ve seen Algolia move towards it. Where do you think billing is going in the future when it comes to these API-first companies?
Tyler: I think there’s a lot of talk about the pay as you go model. But, I think that at scale, when you look at the businesses who are really generating a lot of money over APIs, none of their large customers are actually paying as they go, they work in contracts. They forced them to buy a minimum amount of consumption, but also prevents burst billing and unplanned consumption and whatnot, so it kind of bounds it. And that’s in the API companies’ interest, because they want to have predictability on the revenue that they’re going to get and the buyer doesn’t want to you end up overpaying because they had some rogue developer go to town on something. So I think the pay as you go is a great way to get developers started, it’s a great way for people to find affinity for the service that you’ve got, but once you start to have a real community and it’s really starting to grow, you have a tendency to turn over a lot of those things into contractualized relationships. And that’s the natural evolution of things.
Derric: That’s a really good point, because when we think about these developer-first companies, in some ways you’re selling to developers first trying to get them integrated, we still have an enterprise sales process that you have to run. It’s about two companies at the same time.
Tyler: At the same time yeah. You know, you can get a lot of traction and then when it’s time for you to scale your business then you can think about doing those sorts of things that are appropriate for scaling your business.
Derric:Definitely. Well cool. Really appreciate having you here today Tyler. Anything else you’d like to add, for our listeners?
Tyler:No. Thank you for having me. This was great cool.
Derric:Well, thank you very much.
Make Your API Platform Successful With Moesif
14 day free trial. No credit card required.
Learn More
Related Articles
API Strategy
Announcing General Availability of the Moesif Developer Portal
We’re thrilled to announce the General Availability of the Moesif Developer Portal, a major leap forward enabling you to deploy a seamless experience for dev...
API Analytics and Monitoring
Introducing AI Explain
We are thrilled to introduce our newest feature to Moesif - AI Explain - a powerful conversational tool that lets you interact with your API analytics data l...
API Analytics and Monitoring
Monitoring Cost and Consumption of AI APIs and Apps
Discover how Moesif can help manage and optimize your AI-driven APIs with powerful observability tools that track costs and usage efficiently.
API Development
Unlock Deep API Insights with Moesif’s HTTP Body Analytics
Learn how to use Moesif to analyze HTTP bodies.