VC10X - VENTURE CAPITAL PODCAST
Venture Capitalists (VCs) & Angel Investors share their investing thesis, screening process, value-add, exits, and more. Hosted by Prashant Choubey (@ChoubeySahab)
Lee Edward invests in engineers who are starting companies that tackle the hard problems in software - developer tools and services, software infrastructure, applied AI & ML, tooling for data scientists and engineers, computer vision, and anything else that takes a strong technical team to build.
We talk about:
Investment thesis at Root Ventures
We invest in what we call hardware tech. We're interested in kind of hard problems, technical founders, and we're all engineers. We invest in the areas we know. So my background is mainly in software. Chrissy comes from electrical, Emily comes from mechanical. Kane is kind of hard industry, and Avidan is embedded systems, say, the short version of it. I've been doing a lot in developer tools, software, infrastructure. I define that really broadly. Just anything that people are using to build software, anything software engineers are using. And also really interested in certain kinds of vertical applications of AI, who recently invested in Adept, which you may have seen up there, a large language model company.
What does Root Ventures look for in a company?
It's kind of a hard thing to answer in generic terms. But I think it comes down to, is there a huge opportunity here? Are the founders the right people to solve it? And I think that there's kind of a lot to that, right? Is now the right time to do it? Is the team capable of executing on the vision? And do I agree with how you view the world?
I think it's like, one thing a lot of times my diligence comes down to is like, all right, you have all these ideas and claims. Do I see things the same way if I kind of think about it myself? And I like to do a lot of potential customer diligence is kind of one of my tools I do. Instead of talking to existing customers, which I think runs the risk of fatiguing your customers.
And also we invest a lot of times. I don't know, maybe half the companies we're investing in don't have customers yet. So I get to talk to people that are potential customers and just be like, do you have this problem? Is this problem worth spending money on? What are the gaps like, what are you using to solve this problem and what are the gaps? And then the other thing I do a lot is writing. So I'll kind of like write a deal memo and see if I can talk myself into doing the investment or not.
So the reason I do the writing is writing forces you to structure your thinking. I've always enjoyed writing and if you see me on Twitter, you can see probably write hundreds of words a day of stupid tweets. But yeah, I think it's a really if you can write something, I think been able to think about it at least when you're talking about an essay form, like maybe in tweets. You don't have to think that much to tweet.
I think a lot of times you are someone that has a unique insight. So maybe it's something other people haven't realized or most people don't agree with. But I wouldn't say that. It's sort of something I'm specifically on the lookout for. It is exciting when it happens, when I realize like oh, this person believes a really uncommon thing and I actually happen to also agree, but I really think it's the future.
One example of that is a company called Zed which is Nathan SoBo and Max, his co-founders. Max and Antonio, they all came from GitHub together they worked on GitHub, Atom and Electron. And Max was the original author of Tree Sitter which is the most popular open source AST builder. And Antonio has worked on a lot of CRDT back end data type things. They're actually building a code editor. And in my deal memo, I think like the very first I open source these things. So whenever their next round of funding happens and is announced that's usually when I publish it. I think the memo started with something like in some ways this is the worst market you can imagine. There is a whale that's backed by a major tech company that's over half the market and it's free. And then there's also an infinite long tail of other small competitors, startups and open source projects. And some people have been using their editor for 30 years and are never going to change it. People have deep brand affinity and loyalty and will fight wars over which editor they're using. So it's like literally the worst market.
But I think there's a few reasons it's interesting which I don't know, we don't necessarily I guess we can touch them a little bit, but I think the VS code kind of proved that you can actually go from zero to majority in six years if you make a good enough product. And obviously Microsoft has a super cheat code for distribution but I think their unique insights are mostly around product design. And how does a text editor become a collaboration tool and a point of collaboration? Like why am I, why am I making a commit and pushing it so that you can read it and asynchronously give me feedback.
The commit should be like a deploy artifact. It's a release artifact. If you and I are working in the same office together and writing code, usually what happens is I might ask you a question and maybe point at the screen and be like how does that work? Or hey, I started writing this. What do you think? Or maybe we even pair program or do something that's similar to pair programming. I think people do that a lot and we've kind of lost that in the remote world anyway. So I think yeah, it's really funny. I think when I talk to other investors about this company, usually in the first 5 seconds I kind of see their eyes be like, you're an idiot. And then by the time I'm done talking about it, they're like, oh, that's actually really cool.
Difference between a company that's building developer tools versus enterprise software
I think, there are all kinds of different developer tools out there, but I think there is a big category of developer tools whose GTM doesn't really look like enterprise at all. It looks more like consumer adoption, really. This isn't really new. I think people have talked about the consumerization of enterprise, the sort of like wave of SaaS companies that are sort of like, okay, people at work demand these sort of better user experiences. That was kind of like a buzzword in VC, like ten years ago. And then I think people have also talked about shadow it for like 20-30 years, but I think this phenomenon goes a little bit beyond that. It's a little more than like, oh, my existing tool is annoying. I'm going to bring this thing in because it solves my problem is sort of the shadow it pattern. A lot of developer tools are more like, I use this at home, I love it.
There's a community. I went to the meet up, my friend is using it. I've read all these blog posts about it. I can't live without it, I need to bring it. I actually love it, I have affinity for it, and that's a consumer kind of behaviour. Every company, every dev tools company eventually does bring in an enterprise practice. I think the most extreme example of GitHub, waiting quite a long time to do that and then others do it very early, like Snowflake did it from day one.
So like I said, there's lots of different kinds of companies, but ultimately, yeah, I think you do have enterprise sales motions, but I think it's wrong to kind of look at the seed stage of a developer tool and try to think about it from an enterprise lens. I think you have to think about the potential of, like, is this something people will pay for in the future? And there's a lot of components to that question. There's been plenty of very popular open source projects that tried to charge money and couldn't, or maybe you end up being able to charge money, but only in a way you didn't want to. Like, maybe it was consulting services and sometimes that works, but I think many times it doesn't, especially if it's the primary means of monetization, it usually doesn't work.
I think it ends up being different. I think unfortunately, like, a few years ago, I felt like this was a unique insight of mine and most of the large VC firms that were doing DevTools investing were approaching it from this kind of scale enterprise perspective. And that's not true anymore. I think they all figured it out and I’m kind of annoyed.
But I think at least as someone, I use these products and actually every day I use it every day, I write a little bit of code every day. I at least have some empathy for this. But yeah, I mean, it's interesting. I think some of the firms I used to think about is like, oh, those folks aren't going to get it, look at who's investing on the team. And then I'm like, I see who they hired and I'm like, holy shit, you hired like a really impressive person out of really impressive startup who's an engineer anyway. So I think everyone's figuring this out, right?
Low code Vs No code debate
I wouldn't want to rule out no code. I think if someone has interesting no code ideas, they should definitely talk to me about it. But I think that we underestimate code and low code just because I think the number of people that write code or that are capable if they had to, or if they wanted to, or if it were easier, I think it's very high. I would consider copy pasting Excel formulas that you don't understand from Stack Overflow is still writing code. I think writing SQL is writing code, even doing like Markdown is writing code.
So I think basically everyone's capable of some kind of code. And the thing is, it's just very powerful. There are certain things that are more specifically, more directly specified by writing code. So I'm actually a lot more interested in how do more and more people become developers, and let me use that word as broadly as possible. Can you teach people, are people like writing a little bit more SQL? Are they using a DSL? Are they putting marked down into text box that's going to give them superpowers over their job of kind of manually doing things. So I always think that's interesting. I'm always looking for areas where you're like, wow, you have to be a really good programmer to do this. And is there a way for it to get easier and easier? I think machine learning is a prime example of this, where it's kind of moved from these godlike powers to Pytorches, kind of like Prometheus of the space. We kind of brought the fire down to the mortals, but it's still not that easy. I still think there's a long way to go.
And on the other hand, when it comes to no code, I guess this is the other piece of this is like, do I believe the way that you give models to everyone is to make it so they can drag and drop images into web browsers? I don't know if that's the most exciting thing to me, because I think a lot of times the hard part is always, like, identifying the problem, kind of breaking the problem down, solving the components, thinking like an engineer being like a shape rotator about this stuff. Like, is kind of the hard part.
Writing code. Anyone can write code. Like, it's seriously, you're just you're you're writing instructions for something where there's a will, there's a way. Not everyone has the patience to write, like, a thousand line thing, but people would have the patience to copy paste a line of code into a web page if they needed to. So I tend to think it's less about the interface and it's more about the domain modeling and concepts. I think in the in the machine learning space, that's the biggest thing. If you explain to someone, like, how should I use stable diffusion for this? There's kind of a lot you would have to explain if you want them to go a little bit deeper.
On the other hand, there are lots of drag and drop tools specifically for that. So I don't know, I think there's opportunity in both. I just think that more people can write code is a little bit overlooked.
I think it's only become increasingly true since I said that there's a couple of things. I mean, developers are always bringing their own tools to work, and they're making decisions about these things. At most companies, within reason. The CFO is kind of like, oh my god, why are we paying for this slack thing? It's like $7 a month. Like, this is just adding a lot of overhead. And they very quickly get shut down. That conversation probably won't make it out of the first room. It happens. And someone explains to them about what the engineers need this thing for and how much you pay the engineers and how much the tool costs. The boundaries of this end up being like, cloud compute.
There are people spending 5X their salary on GPUs for little ROI. I think that's actually a reckoning that's coming. But for most things, for tools, for productivity tools, yeah. It's a no brainer. And that's even like, even things like Stripe. There are companies, you hear about this a lot where the CFO is like, oh, I did research on Braintree and we can actually save a little bit of more money over Stripe. And the developers are like, we're literally going to quit. I think that dynamic is there and then the company is incentivized to do this, especially in a market that's hard to hire in if there's an economic downturn. We're kind of focusing on core parts of the business. We're focusing on unit economics, we're cutting costs, productivity, like head counties being frozen.
Productivity is the thing you want, right. You look at things like Heroku, like platform as a service or things that are basically their pitches. We replace the DevOps engineer and there's a lot of stuff out there that's like, we replace your security engineer or we count ourselves as like a headcount in this department. That kind of stuff is very appealing.
I'd love to see the data on this. My anecdotal observation is I don't think companies are really cutting serious developer tools from their budgets as they're going through this stuff. I think now is a difficult time to be in a pretty optional this is a classic thing in economic downturns. Like HR SaaS software tends to be the first to go or anything that's sort of viewed as like not directly in the line of business. And HR professionals hate this, as well they should. Their stuff tends to be first on the chopping block. But so far I don't think I've really seen this on the developer tool side.
Perspective on remote work
I think this trend has existed for a while really, but I don't know, I guess one of my contrarian points of view is I do think that colocation of teams, regardless of where the team is, has a lot of benefits. That being said, I think almost every company I work with has some employees that are remote and some of them are fully remote. But yeah, if it were me starting a company today and I possibly could, no matter where I lived, I would try to make sure, like, okay, all the cofounders are in the same place.
We see each other a lot, we get a lot of face time and that's because the work is creative and you kind of want that serendipity. It's a long, long time before a startup is at the point where they're like, okay, we wrote a spec, we threw it over the wall, someone's going to bang out the code, someone's going to do the QA, we can ship it.
I think the trend has existed. I think the trend is good in a lot of ways, but I do think it will continue. I think you have a lot more credible options of places you can live, and the tooling is supporting it more and more. I think it's not even close to perfect. Not even close. The other thing is for developer tools companies.
This conversation is very different. If my other partners are in the room, I really don't think you can do a hardware company remotely. I'm not the expert on this, but Chrissy and Emily are, and they would agree. SpaceX and Tesla are mostly co-located when it comes to design engineering. Apple is the three places that the two of them worked. That's the thing that gets missed a lot in these conversations. It's funny when you see I don't know, for those who are kind of eternally online, for VC and tech, Twitter, one thing that you see when people are arguing and talking past each other is look at what they're saying when Elon's talking about things being in person.
What is Elon thinking about all that? He's thinking about SpaceX and Tesla. You're not building a rocket with a remote team. And then you see people are like, oh, this is stupid, this is crazy. At GitLab. We're all remote. I'm like, yeah that works really well for you. You have a Git workflow at the company that's building the Git workflow company. Literally, it works. I'm sure a lot of the Zoom team is remote. I'm sure a lot of the Slack team is remote and open source project. I mean, the Linux kernel was built by people who barely saw each other. It's well established patterns and tools.
Like, that totally makes sense. Like, it really depends on what you're trying to build. And if it's a hardware product, then it's really hard to embrace, remote work in that case. But if it's a software product that doesn't require a lot of colocation and working together, then maybe you can consider remote work.
Where’s the next Github coming from?
I never intend to go on interviews pumping my own companies because I think it's kind of annoying as a listener, so I'll try not to do it. I did mention one of our companies that's working on this, and there's a few that are also doing it. But yeah, I think the overall thing, it's kind of weird that GitHub's original tagline was social coding. And I think I was someone I had used SVN and CBS before Git came out, and I never used Git until GitHub came out. So I think those two things are like, close to synonymous at this point when, like, actually, I guess GitLab people would be super angry to hear me say that. But yes, I mean, I'd put GitLab in the same category. The pull request concept is essentially like part of Git, even though it literally isn't.
So like that workflow. It was just dramatically better than CVS and SVN where I'm locking a file and then I fall asleep at my keyboard and then get up late and then the next person in the morning is like, Lee has that file locked. This horrible way to horrible way to write software. It is, by the way, the state of the art for mechanical CAD. That is literally how mechanical CAD gets done. They call it PLM Product Lifecycle Management and these horrible products do this to these poor people. But in any case, I think it just watching that time compress and compress. Like we teams really rely on slack to sort of have chat that is, it's both synchronous and Asynchronous. It's probably most of the time Asynchronous. But then it kind of like in the Limit case, it becomes synchronous, but still when we want, if I want you to look at my code, like I'm typically making a branch, I'm making a commit, I'm showing it to you. And making a commit is I don't know, for different people it probably feels a little different, but on some level for everyone, you're sort of packaging your work up and saying this is something worth reviewing.
Whether you're doing this as showing this to someone or testing it on staging or you're making a PR, it's almost like a political act or it's definitely like a personal act that puts your ass on the line to varying degrees. But yeah, I think one of the questions is just like why is the commit the canonical unit of collaboration when it's actually very discreet? And a commit can contain one line of code and 30 seconds of work. It can also contain a week of work and hundreds of lines of code. The funny thing, and I think kind of the proof of this, is that we all know the best practice is like more and more smaller and smaller commits. We know that the Limit should approach zero. And so I think at the same time, enabling asynchronous work is one reason that programming works remotely. But we do lose something by being all asynchronous. I think there are times when synchronous adds a ton of value. I think that that's one of the frontiers for collaboration.
And yeah, I will plug our companies. I mentioned Zedaily is one of our companies that's an API for video chat using Web RTC. So they're like bringing that to a lot of different tools. And Octeto is a company that kind of lets your development environment exist remotely in the cloud. And so there are many use cases for that, but one of them is this the idea of like, if I want to run my thing in the cloud. Most people are testing their code at certain companies, like certain companies I've been at that shall remain nameless. People test their code by pushing it to staging and letting CI run the test. And you're like, all right, is that really like the best way to be doing?
What change do you wish to see in the dev tools ecosystem?
Yeah, it's funny. It's funny because it's sort of like if I knew exactly what it was, I would probably build it, I guess. I think there's like a few things I always find myself gravitating towards. There's this perennial that's existed forever, this sort of trade off of performance and productivity. I think even like going from writing assembly to writing C, most of the time when you add an abstraction, you are making a trade off of some kind and often it's like performance and usability.
Like really good examples of that. It shows us how far we've come that Java is a really good example here where you're like, oh my God, Java is so non performant compared to C++ at the time in the 90s. Now Java is quite performant, but you are trading off like direct memory management for developer productivity and happiness.
And then I think taken to extreme like Ruby. Ruby kind of claims to be a language and Rails claims to be a framework that's designed for developer happiness. But now we're seeing things like Rust that kind of shift this curve. I think Rust is still extremely harder than probably two of those languages I mentioned, but it's easier than the other two I mentioned and highly performant and also does a really good job at a certain kind of performance multi threading thread safety multicore that lots of other languages that are performant aren't even good at. So I think it's interesting to see that.
I guess now to take the leap to startups. Every time I talk about developer tools in a very high level, I always end up talking about Heroku, which again, a lot of investors are kind of like, why? Because it was sort of like for an investor it was like a middling exit. This is kind of a really offensive thing to say to people that. Spend a lot of time and hard work on Heroku and a lot of them did pretty well financially with it. But for an investor you want like a billion dollar plus exit. But I think Heroku I'm stealing this line from, I don't know if I should name them necessarily, but an executive from Heroku who said basically like Heroku created a lot more value than it captured, that's basically right? So it's impossible for me to talk about DevTools without talking about Heroku. For me, I love that company. I still love that company. I wear their swag.
They were a really good example of this. I mean, you're paying extra money for productivity for them to kind of implement this architecture for you and not have to think about it, and way more expensive than just using AWS. But what you're paying for is the developer productivity. The more apps you have, the more developers you have, the more you kind of realize the value of that. But yeah, it's interesting to see as things evolve. I've seen some next generation platform as a service companies that I think are changing the trade off curve by letting you kind of dig in if you want to get under the hood of the platform.
I don't know, that's just one rant of like many, I guess. I really heavily weigh developer productivity. When I look at something, I think historically that is sometimes meant throwing performance completely out the window. It's exciting to see that maybe you could have a little bit of both. I'm optimistic.
How do you add value to your portfolio companies?
Well, the first thing I do is I try not to subtract value. So that puts me hopefully in the top 50%. The number one thing when founders ask me that is if I'm giving them a term sheet and hoping to close them, I have them ask the founders I work with, which I think not only hopefully they'll all give me a thumbs up, but they'll all have different stories. And I think that's kind of the point, is I think sort of generic, one size fits all VC advice can be very value subtractive. I think one reason you see it on the internet is you're literally like the content you're writing as a VC is like the audience is for everyone. So it is pretty generic. But if you get in the boardroom with an investor and they're kind of like repeating something you could have read in a blog post, I think that's not helpful.
So I think it's pretty clear talking to me like I'm someone who kind of thinks like an engineer. I think about problem solving in a very technical way in a way that annoys my fiance, sometimes annoys a lot of people in my life. But I think that what you're usually doing to help is like being someone to kind of bounce ideas off of be a first principles thinker with, be a collaborator and maybe someone to kind of agitate the stable equilibrium. Like you and your co-founders have been talking about this idea and you've found an equilibrium. And sometimes that's a really good thing, right?
But sometimes you kind of want someone from the outside to come in and sort of challenge it and discover if it's a stable or unstable equilibrium. Having been on the other side of the table, having been the CTO at a startup, that CTO at one startup where we were high flying front page news like big deal. And then we were crash and burn and pain and existential crisis. Like, I've sort of seen that up and down and worked with a lot of really amazing investors and board members through all that I kind of model after a little bit or try to. And I think having that empathy and understanding that understanding what the role of the investor is, we're not in control and we're not even managing. It's influencing. I kind of lived that.
Moving from engineer to engineering manager to executive. You are losing more and more direct control and having to get comfort with like you're attempting to influence. And so I think a lot of people get that wrong. A lot of managers get that wrong. I got that wrong. I think almost every good manager has fucked that up at some point in their lives. And there's kind of a more extreme version of that if you're a board member, whether that's as an investor or a founder or an executive or outside board member.
At the end of the day, sometimes doing the thing to do, to help is to not do anything and let the founder be themselves. Like you invested in them for a reason. I don't know. It's kind of a lame answer. If you wanted to get concrete, a lot of times the way these things go is like helping the company raise the next round of funding. It's like a big part of my job to know how the ecosystem looks like, to be connected to those people.
Connections for hiring. Probably most of our companies have at least one person that we've brought in. Some companies I work with have like three or more people we brought in. And connections for sales. But I think all that's I mean, that's everyone's answer. I think some of the larger firms have a platform which really just means they've productized and outsourced this.
So instead of the partner you're working with helping you with recruiting, they send you to the recruiter. So we're kind of like to do things that doesn't scale, kind of firm and you get us a back office.
Rapid fire round
What sectors and regions you invest in?
Developer tools, AI and all regions.
What stage you typically invest in?
Pre seed, seed, post seed, anything with seed.
What's the typical check size?
2 to 3 million in this fund.
Where can the founders apply?
Root.vc if you can use a command line interface, you can find the info. I love the website, by the way.
Where can our listeners follow you?
@terronk on Twitter. Okay. Or just search for me, Lee Edwards. But be prepared for a wild ride. It's not all dev tools, it's usually just whatever I'm thinking of.