Ep. #42, Elevating Code Search with Quinn Slack of Sourcegraph

Grant Miller: All right. Quinn, thank you so much for joining.

Quinn Slack: Thanks. Great to be here.

Grant: All right, well, let's jump right in.

Tell us a bit about how you got into enterprise software.

Quinn: I've been a coder all my life, I remember back in the late '90s, early 2000s when I was 11 or 12, I would go on the internet, join IRC channels, learn to code, ask all kinds of silly questions.

And I loved that no one knew that I was just a kid at the time.

And I started fixing other companies websites all around the world.

I love how global it was, and started to make money.

That's when I got hooked in software and in the coding.

I was the first engineer and employee at Bleacher Report.

And then it was well after college that I saw what enterprise software was like.

My experience before that was working on academic projects, fun projects, small websites, open source projects.

But I was working inside of JP Morgan and Bank of America, and they have a ton of code.

Grant: So you were at Bank of America or JP Morgan, which one were you working for?

Quinn: I was at Palantir working inside of JP Morgan and Bank of America as a contractor.

Grant: Okay, got it. I guess straight out of college, you went to Palantir?

Quinn: Yeah, that's right.

Grant: Okay. Oh, this is interesting, you were forward-deployed engineer, which I think they invented that title from what I know.

Talk about, what does a forward-deployed engineer do at Palantir, or at least what did they do at the time?

Quinn: What I loved about it is you got to write code that directly solve the business problems that you had uncovered.

It's like this, by day, we were business casual, we dressed up, we went into these bank buildings, we met with the people, they thought were the business people.

At night, 5:00 PM rolls around, every one at the bank goes home, we're still in.

We pull up in the conference rooms, change into sweatpants and pull out our laptops and code to write tools to solve the problems that we just heard about, pull the data, things like taking loan data from over here, making it so that the bank can better avoid foreclosures and rolling that out as a tool to call center agents.

And of course, the next morning when we would show up and we'd have software, they would know that we were the same ones that coded overnight.

But the magical thing was that feedback loop was so fast between the problem and the solution, and I love that.

Grant: That's really cool.

And so you would sit there with their teams understanding the problems, really digging in and then use Palantir software to basically build solutions to those problems virtually overnight?

Quinn: Yeah.

Grant: That's awesome.

Talk a bit more about Palantir in general, it has some amount of mystery behind it because generally I think works with a lot of intelligence agencies and the government, but obviously works with a lot of financial sector folks.

And talk about like what the technology really did, what was powerful about it and how you decided to go there?

Quinn: I was there more than 10 years ago at this point, and I was on the commercial side, so not working with government and other clients like that, I was working with large banks.

And I was there for 10 months, so I got to see some of it.

And I think at the time, we were tasked with figuring out how can Palantir go solve some really big problems that these large banks are facing.

And at the time, it was when the housing crisis was still a mess and foreclosures are terrible on families and they're extremely costly, and so banks wanted to avoid those.

So what we felt was more of the challenge, how do you go into these banks that have an intense needs to write software to solve really big business problems, and how do you get that software written as quickly as possible?

For the part of Palantir that I was on, it wasn't yet, "Hey, Palantir has a product that does this out of the box."

It was, what problems and repeatable solutions can we find in this sector that then later over the last 10 years, Palantir has productized.

Grant: Oh, interesting. So you were like just writing custom code, were using different frameworks, or what were you building these like apps in?

Quinn: Palantir had, think of it like a souped up Microsoft Excel that was really good at data integration, and you could write custom code in that.

So we did a lot of that.

We also had to build tools, web applications to take data from that system and show it to a call center agent or bring it to another system in the bank that would let them sign off on this model and their compliance team.

So there was a lot of custom Ruby on Rails apps and working inside of Palantir software.

So because we were doing that custom software development inside of these big banks, and because we had a mandate from the senior leadership of these big banks to solve these problems as quickly as possible, we got a crash course in what it was like to build software inside of these big banks.

And instead of timelines taking years, we had to solve these problems in weeks.

So we really felt the pain of being inside big companies with tons of really smart people that are trying to do good things, and there's so much code, there's so many APIs, it's so hard to figure out, how can you change this?

Can you hit this API? How has this defined? What team owns it?

We felt that pain, and we had to do things like fly people from around the country to a single meetup point, just to get information about code or figure out if you're going to change something, what might break.

And the amount of code that those banks and that companies have written since then, 10 years ago, has just grown like crazy.

So the problem is only getting worse.

Grant: That's really interesting.

So then you left Palantir, you were there for about a year, and you started a company before Sourcegraph.

So between Palantir and Sourcegraph, there is another company.

Talk about what that company was and what happened there, and why did you leave Palantir, I guess, part of the question?

Quinn: I loved my team at Palantir, I learned so much from them, and the team bond was so strong.

So some of the other people on this small team of Palantir, we really loved working together, we wanted to keep working together and we saw massive opportunity.

So I followed this team and I was one of the co-founders of Blend, which recently went public a couple of months ago, and right now is helping a lot of really large banks have a much better platform for lending.

So you can do a mortgage on your phone in two hours, and I've done it with Blend, instead of this terrible process is so many PDFs or even worse, paper that lasts weeks.

So it makes it much easier to buy a house.

And on the bank side, there's a ton of work that goes into an amazing consumer experience for mortgages and Blend makes that so much easier.

So I love working with that team.

I think that mortgages are such a fascinating problem because it's the biggest transaction the most people have in their lives.

But as much as I love that team and mortgages, my original love here was code.

And the biggest problem that I wanted to go solve along with my co-founder, Beyang, who also worked with me at Palantir was, this problem that we felt inside of these big banks of there's so much code, so many developers, so much complexity, how can we make that easier?

And that problem is only getting worse.

So that's why we started Sourcegraph after Blend, because we felt like we needed to go solve that and we didn't see anyone else doing that.

Grant: Yeah. Well, number one, I guess congrats on co-founding a company that's just IPOed.

That's pretty amazing, just as you're like, "Oh yeah, I started a company nine years ago and it just IPOed in the last few months," or how recently?

Quinn: Yeah. I think a couple of months ago. It's testament to the team.

That's a good reason why I followed them from Palantir and started the company with them because they are amazing people.

Grant: So you were there for about a year as well and decided, "This is interesting, but it's just not what I really want to do. I want to solve this burning desire to solve a problem around code discoverability."

Quinn: Right. I felt like I was put here on earth to make it so that as the amount of code grows, that we can still make forward progress in technology because I've had these experiences that I had felt the pain, I felt that I could build this solution and Beyang and I together, we agreed on a solution.

And he had seen a glimpse of the solution.

He had been at Google previously, which like so many other companies, has a ton of code, but they have been able to build stock at scale more effectively than any other company, and especially back then, 10 years ago.

And they have the secret weapon.

Every Google dev uses their internal Google for code, their internal code search tool.

And if you're a Google dev and you quit Google, it's the thing you miss most, way more than the free sushi or the foosball.

And we don't want Google to have a secret weapon, we want to bring that to every company in the world so that they can get on top of this big code problem.

Grant: Cool. So then you said you started Sourcegraph. Did you raise some money right away or how did you fund it when you first started?

Quinn: We raised something like $300,000 to begin with.

And now when I hear about the financing available, it makes me really happy that there are a lot more bets being made.

At the time when we started in 2013, it was not cool to build things for developers.

And this was before you really saw the success stories of GitHub and Atlassian.

And in many ways, their success has made it so that investors know how to properly value those very initial signs of progress.

But we raised $300,000 from some people that believed in us, and I'm forever grateful for them believing in us.

And then if you just zoom out, from 2013 to really the end of 2019, we were still trying to find that product market fit.

The idea was code search, let's get it to every developer and every company, but we made a lot of mistakes along the way.

We had to build a ton of really deep tack along the way.

And so it took us a lot longer than we expected, it took us a lot longer than I think a lot of people think is normal for a startup, but I'm really glad we stuck with it.

Grant: Yeah.

It's funny, I think we were just chatting before the recording, both of us, I think you've been out a bit longer than we have, we've been at it for about seven years, but it took a while for us to really find the true pool from the market as well.

But I think there's something about teams that stick together and stay at the same problem and keep solving it.

And I think you had the conviction, you knew what an important problem was and that if you could solve it, you could really improve the overall day to day quality of life for most developers.

And so you stuck with it and then now you've raised a bunch of more money and you've created this, you say 200 people on the team or something, is that right?

Quinn: Yeah, that's right.

Grant: Yeah. Incredible.

So I'm really interested, the initial thesis, code search, because you have a pretty strong open source motion, was it always open source?

How did you think about getting it in the hands of developers early on?

Quinn: Well, first, the moment that code search really clicked for me and the Sourcegraph really clicked for me was in the first two weeks, some people might be listening and they think, "Well, what is code search?"

I have code search in my editor. Let me talk about a use case that really clicked for me.

Grant: Yeah. Great.

Quinn: And the first week and half of writing Sourcegraph, building Sourcegraph at this tiny little apartment where we were working in, we were using Sourcegraph as we were building Sourcegraphs, so we had it up on another screen, and I was writing some code to Pascal and do cross-references.

And using Sourcegraph, I found someone else who had used the same code and I've written this other library, this library did exactly what I needed to do over the next two weeks.

And I just use that library and I saved two weeks.

So in the first week and a half of building Sourcegraph, it was already net positive time-savings for me.

And it's not just time-saving, it also made me smarter.

Grant: That's a really interesting use case. So is there beyond that initial, how you found a use case, is that the standard use case for your customers today?

Or how do they think about the value of Sourcegraph in the standard development workflow?

Quinn: Well, today, just to fast forward, right now, we have really large engineering teams using Sourcegraph, some of the world's best engineering teams.

So three out of five are the FAANG companies and other companies like Uber, and Plaid, Atlassian, and GE.

And it took us a long time to build a product that could help developers at that scale, at those kinds of companies throughout their day.

So finding a bug in code and understanding what are all the places that are calling that, or if you're onboarding to new code base, how do you understand it?

How do you know who you can ask? How do you know how it's changed over time?

If you own an API, seeing who's calling the API and being able to see, "Hey, you're going to change it in this way, who is using that? What ways should you change the API?"

Because maybe you see people using it in a way you didn't expect and you can make that easier for them, or if your page in the middle of the night and the site is down, you know there's something in the logs about access tokens.

Well, one thing you want to know is what changed related to access tokens in our code, and Sourcegraph can show you that, you just search for changes related to access tokens.

And so it's all of these things. That's what code search does in the end.

And I would liken it to Google Search. Google Search does so many things for you.

You wouldn't call Google Search a tool for finding a pizza recipe, or for researching this war in the 1840s.

That'd be a weird way to describe Google. It's like a second brain for you.

And that's a hard concept to explain upfront, but once you use it, you feel it.

And initially, our approach was to make Sourcegraph awesome for open source and then have a cloud offering that let anyone, OAuth, GitHub code and Gerrit.

We in the end found that it was these larger companies, 50-plus engineers, at least where the problem was felt, and all it took was one dev to bring us in and then it would spread organically and virally once that dev brought us in, but it was a long journey to get to that point, both to understand that that's what we needed to build for from a go-to-market strategy point of view, and to build a product so good that one dev could bring it in, they could run it self-hosted, it would work in all their systems, it would scale, and they could share with their whole dev team.

And everyone would generally like it enough because if we made a product that 10% of devs liked and 90% thought was not good, well then they're going to reject it.

Search is not a system of record, so you can't be forced to use search, you only use it if you think it's really good, and if you remember to come back.

So we had such a high hurdle to overcome, but once we did that, once we figured that out, then things really started to take off.

Grant: Interesting. And I remember if we dive into a little more detail on the initial architecture and thesis, we met, I think literally just as we were starting Replicated.

Someone referred us to you, we met, we talked about what you're doing.

And I think I remember at the time, it was like a go-binary that someone could run on their personal workstation.

And then that was the primary way that it would get distributed and that first developer would use it. Is that right?

Quinn: Yeah.

Grant: Is that still true today? Is that still the primary way someone will initially interact with it?

Quinn: Gosh, I think that moment in time that you remember, it's amazing to look back, that was one of many things we tried.

What really started to work was when it was a single Docker run command that let you sell posted code search across many repositories, across all the code hosts that you use.

And I think that thing that you referenced, it didn't even have really good code search yet, it was code navigation, it was very basic.

So that was still many iterations away.

Grant: It's interesting.

Talk about any of those other iterations, like what you know, because I think understanding some of those different hypothesis you might've had that you were like, "Oh, we tried this. And then here's why we moved beyond that and tried something else," that's a really interesting insight.

Quinn: Yeah. Lot of big decisions that we had to make.

So one was just whether to go self-hosted or cloud and this was around 2014, 2015, when we were thinking about this.

And the default was to offer a cloud service.

And what that would look like is you could sign into it with GitHub, you could click that big green button on the OAuth screen and send all of your code up the Sourcegraph, and then you could search it.

And in hindsight, completely predictably, everyone would get scared at that screen, and they wouldn't trust us.

Not that we'd done anything wrong, but code is such a sensitive asset, and why would they trust a tiny little company that they barely knew?

And so the only kinds of companies that were willing to do that were these tiny companies.

And I am so grateful for their belief in us, but they didn't have big code problems.

They just didn't have that much code.

If you have five engineers and you've been around for a year and a half, you're not that worried about clicking the OAuth button, but you also don't have a big problem with developers onboarding or with the site going down and needing to trawl through a ton of code to understand it quickly.

And so we felt like we were hitting our heads against the wall and we were getting very limited traction with some of these much smaller companies that we didn't really see a way to build a business around.

And we waited too long to fix this problem, and I think for me, it was because I wanted to be introspective, and I think too introspective in hindsight, but it seems so easy to say, Hey, these people are telling us they don't feel comfortable sending their code up and it's a security problem, but if the product were more valuable, then the value would outweigh the risk.

And look, they have made that determination for a lot of other products, they send all of their code up to GitHub on the cloud.

And so it's not a security objection, it's actually a product value objection.

And that makes total sense. And when I explored that route, it felt like I was doing the right thing, like I was being really honest with myself and asking myself the tough questions and I wasn't being the jerk CEO who was just like, "My product vision is perfect, no one can doubt it."

But in the end, we got nowhere, and it was a security objection.

And again hindsight, I feel so stupid because I care about security, I would not OAuth my code to some company like that.

And that was a huge mistake, we spent too long on that, but within a couple of weeks of making that realization, we made a bunch of really big changes at Sourcegraph.

And one of our team members prototype this Docker runs self-service, self-hosted way of running Sourcegraph, and that doesn't require anyone to trust Sourcegraph.

You run Sourcegraphs on your laptop or your own infrastructure, connects to your code hosts.

And that ended up being a much better way forward.

That's when our business really started to take off.

And it wasn't just, oh, we started to get customers, but who the customers were was different, instead of these small companies that didn't really have big problems that we could solve, our early customers were organizations like Uber and Yelp, and Lyft.

And we learned so much from them and from building code search that would work at their scale, the insight into their problems, the other problems we could solve was so valuable.

And I think a company's trajectory is defined by the first five customers that it has.

And self-hosted not only got us customers, it got us the absolute best customers that we could possibly hope for us to build a big company around.

Grant: Yeah. That's a super interesting insight.

The idea that matrices or whatever, the overlay, the Venn Diagram, however you want to think about it, but the folks that were willing to send code up to your cloud environment didn't have the big code problem that you really solved.

And so you felt like the product was missing because even those users who were using it in the cloud, it was like, "Yeah, that's fine."

Because they didn't really need it that badly.

If you think about, one thing that Rahul from Superhuman really is ruthless about with their product was only letting people use it that met that ideal customer profile.

And only if you were going to have a really high NPS were they going to give you access to it.

If you didn't use email the way that Superhuman was designed, then you wouldn't get access to the product.

And so it's the same thing here, those early customers that were signing up for the SaaS product just didn't really need it, and so they just didn't love it.

I'm sure that was probably a really tough period for you because you think you've built this great thing and you're really excited about getting into the world, and then you're getting this lackluster response from folks and you're thinking, "Okay, well, those customers aren't loving it, and these customers won't try it, maybe there's not enough value here." Right?

Quinn: Yeah, that's right.

Grant: Okay. And so then the Docker-run self-hosted version was fully open source. Is that right?

Quinn: No, at the time, our code actually was not public nor open stores at all.

And it was only about a year and a half after we had that Docker-run commands that we made our code public.

We never expected that to be a huge change in the business.

As a company that's building an end-user product that has a UI that people actually use, open source is a much less meaningful strategy for us in many ways.

If you're building a library or some infrastructure that developers need to pull into their stack and deploy along with their production applications, I can completely understand why you need to cast the net really wide with open source.

And then as a business, you try to offer value to some fraction of that.

But open source is very different for an end-user product company, I feel.

And so we decided to make our code 100% public, and anyone today can go on and look at our repo on GitHub and see all the issues, all the PRs, all the code history.

We did that so that we're transparent. It's great, it helps build trust, it helps anyone who's thinking of using Sourcegraph.

They can see what's being worked on, or they can know that we have put ourselves out there and forced a level of transparency that goes beyond most companies.

And for us hiring, I love that people when they're at Sourcegraph, the work that they do is not hidden, they can show it off to the whole world.

That makes me really proud that we do that. It's great for hiring as well.

But it's not really a part of our go-to-market strategy, other than that on the margin, it probably makes a developer slightly more likely to want to run Sourcegraph at their company because of trust and because of devs like me, we prefer to run stuff that have a GitHub repo.

Grant: And so all of your code is at least viewable, right?

Quinn: Right.

Grant: Code visible more or less.

I think Atlassian did that as well at some point, that was part of their strategy for that transparency as well.

Quinn: GitLab as well.

Grant: Yeah. But GitLab has an open core product, so there is a part of GitLab community edition that's fully open source and you can compile it or you can run it on your, probably do a Kubernetes or Docker install.

Do you have the same idea of a community edition that is still like a code search tool that you could use and then an upgraded enterprise edition?

Or is it just the open source is a trial and then you need to upgrade to enterprise?

Quinn: Yeah. We are also open core, so about half of our code is under Apache2, the other half is not, it's not under some weird license, it's just copyrighted and it's clear about that.

In the same way if you go to The New York Times website and you read an article, just because you can view it doesn't mean that you have full rights to reproduce it, it just copyrighted.

And GitLab is the same way there. From a go-to-market point of view, unlike GitLab, we don't emphasize that start with the open source version of the product and then upgrade to enterprise.

And the reason why is because that just causes infrastructure churn.

We want every developer to start out with a freemium version that they can use for up to 10 developers, and then if they want to roll it out to more, then they can just put in a license in the same thing that they've deployed, and GitLab is really preferring that too. So you don't have to redeploy, change the Docker images, remigrate the database if you want to upgrade.

And if you look at some other really popular products that we all use, they're like that, but people don't think about that.

I'll give a few examples. Chrome, the Chrome browser, Android and VS Code.

These are all products that are mostly open source, there's some part of them that is not, that is closed source.

In some cases, that code is visible, in some cases, it's not.

And they all encourage you to just download the binary's that are built with a combination of open source and some closed source components.

And so it's a really common pattern.

Once you get into all the details, it sounds really complex, but the way that we ship Sourcegraph is really identical to how GitLab does it and identical to how Chrome and Android and VS Code do it.

Grant: Oh, interesting. So that makes more sense.

So basically, the model is, it's a freemium model, but it's a freemium self-hosted model where any developer can install Sourcegraph "Enterprise" onto a Linux server or their own workstation, invite up to 10 of their coworkers, and they're using that for free and it's totally within the bounds of your license.

But then if they want to spread it out to a second team or more folks, or get the full, really spread it within the organization, that's when they need to pay your team to spread it?

Quinn: Yep. That's right. From the point of view of users, it's freemium. It's really simple.

Grant: But because you're doing the self-hosted side of this, it's truly freemium for the enterprise because the reality is, the small team at an agency probably doesn't love to spin up a lot of their own infrastructure and set up their own self-hosted version of many products because they don't have IT folks, they don't have folks that are really going to manage or operate these applications.

And so for the enterprise though, they know how to do this, they have an existing Kubernetes cluster or something else for them to install this into, and it really meets their requirements, and they don't have to share any of the code or data with you at all?

Quinn: Yeah, that's right. And I have been actually surprised at how even small companies in many cases do prefer self-hosted, especially outside of the US for a variety of reasons.

But yes, there are always going to be a ton of companies that don't want to run software in their own infrastructure.

It turns out that now we are big enough and trusted enough to offer a cloud service, coming full circle.

Once we got a sizeable number of customers and we'd proven that Sourcegraph is secure, that we have the right practices and so on, now we see companies, many of them preferring cloud.

And so that's a big effort for us to come out with private code search on the cloud.

But I'm so glad we didn't start with that.

Grant: Well, you said you did start with it initially, so you had it?

Quinn: Yes.

Grant: Did you take it down?

Quinn: Yes. We took it down.

I'm glad that it completely and utterly failed and we weren't bogged down by also trying to do that over the last five years.

Grant: Really interesting. So that's fun.

So you had an open source version for some amount of time, there was a desktop client, whoever knows of you went production with it.

And then you had a cloud-hosted SaaS product that did code search, and then you realized, "Hey, we need to offer a self-hosted version of this."

That's what really got the momentum.

And then since then, you have found existing demand from customers to have you host it yourselves?

Quinn: Yeah.

Grant: I love this. Clearly, anybody who listens to show knows like this is what Replicated core business is.

We love to hear this kind of story.

We love that you have found success because you're doing, we used to call it modern-on-prem, now we call it multi-prem.

But this idea of allowing customers to run your application in the environment that they choose because of this data security, data control issue.

And then to the point of, we never think it's all or nothing, we think it's a really beautiful blend of some people just want it different ways and you should be willing to run it however they want it.

So if they want to host it in AWS, great. If they want to host it in an on-prem air-gap data center, great.

If they want you to host it, great. And sounds like that's becoming more and more reality for you.

Quinn: Yeah.

And I would strongly urge anyone who's building a software business that is either targeting developers or where they want to be the developer friendly version, that's their differentiator in a non-developer market, go self-hosted first.

And there's a lot of objections that people have.

Sometimes people will say, "Oh, it's so much easier to build a multi-tenant secure year online, 24/7 service than a self-hosted version."

And I think that's completely false. The single tenant self-hosted version can be so much simpler.

The security threat model is so much different because it's running only with a single company's data.

In most cases, they are going to be managing the ops of that and so you don't need to have a 24/7 online service, you don't need to pass all of these compliance checks.

And really, to run it locally, you probably have a dev environment when some dev on your team needs to do local dev on your product, just start with that as your self-hosted version.

You don't have to make it way more complex. I think a lot of people think, "First, we need to build multitenant and then rip it out and then make that self-hosted in single tenant."

But no, why go through all the complexity of adding multitenancy before you've got product market fit?

Grant: Yeah. That's super interesting.

And I think that's an angle that I'd love to explore more, this idea of really focusing on single tenant self-hosted to begin with.

One of the initial challenges that I see from doing that would be around like telemetry and visibility and how someone's using your product.

How did you solve for that when customers were first using your self-hosted single tenant version?

Quinn: Yeah.

We knew that we needed to understand how people were using Sourcegraph, but the kind of data that we could collect that customers would feel comfortable with us collecting was so, so limited.

So we look at, what does VS Code collect? What does Chrome collect?

And it's these kinds of scalar values, so nothing like the event level tracking that you'll see in a cloud app where every single click, every single mouse movement is trapped is how many users were there today?

How many users were there this month? It's very broad information like that.

And yeah, it would be great if you had perfect information into everything that was going on in your business, but it's a trade-off.

Would you rather get the ideal first customers and have to get a lot of the qualitative information by talking to them?

Or would you have a cloud service that you can jam all these trackers into and get companies that are not your ideal customer and probably get way fewer customers?

I think certainly the former. It's not a silver bullet.

Grant: It's identifying that there's trade-offs.

There's very few solutions, but there's lots of trade-offs.

Did you do anything specifically, like you mentioned the first three customers really helped define your product.

And so were you pretty hands-on with them, were you setting up calls, watching them use it?

How did you get that customer feedback from those early self-hosted customers?

Quinn: So this gets to another benefit of going self-hosted and self-serviced, you really cast the net wide.

We had a lot of companies install Sourcegraph as soon as we made it available and got talked about on Hacker News and Twitter.

And so we were able to sift through a lot of companies and basically look for, who are the five or 10 that are most excited by code search?

We narrowed that down even further to see, is the company the ideal kind of initial customer?

And so, because we were able to sift through, we ended up with three to five that we're really passionate about code search. In some cases, they were ex Googlers who'd used code search, in other cases, they just felt the pain of working on massive code basis.

One of our early customers had run a survey among their developers, and the biggest request was, please bring in source Sourcegraph, because we had a lot of people that were familiar with it.

So we were able to get really good feedback just by going over to their offices or chatting with them on the phone or Zoom.

It gets to this power of casting the net really wide with self-serviced and self-hosted.

Whereas if we were on the cloud, I think it's such a huge constricting point in the funnel for someone to authorize their code and send that up to you.

And so we would have to make do with a much smaller number of companies that had gotten to that point.

Grant: And were you interviewing them like regularly?

Were you spending time with them on a Zoom?

Were they engaging with you in issues on GitHub?

Quinn: Yeah, all of those.

These people that were setting up Sourcegraph in their company, they were obsessed with code search as much as we were.

So it wasn't like pulling teeth to get feedback out, we were able to narrow it down to the other people that were as obsessed as we were.

So all of the above, meeting them in person. They would text us at all hours of the night, email us.

They would contribute changes to how we deployed Sourcegraph.

They were just so passionate. And I loved that.

And the reason why, it didn't feel like a job for them, it was something that they saw other developers talking about.

And at nights, or on weekends, they could just set it up and try it out across all their code.

They never needed to talk to us or talk to sales or anything like that, it was completely self-service and they were able to do so much on their own.

And also they hadn't wasted a lot of their time going and getting approval from the security team and the compliance team.

We much prefer them to spend that energy and time setting up Sourcegraph, spreading it, talking to us rather than these boring bureaucratic processes that they'd have to do if we were deploying on the cloud.

Grant: And did you have like a hard limit to, it says today, 10 users, but were you hard capping or you could keep inviting after that and it was just going to be a lot of warnings?

How did you think about feature capping your free version?

Quinn: Initially, we wanted to focus on making the product better, rather than these restrictive things.

Subject to the constraint, we didn't want to do anything that was non transparent, so we were really upfront with how it's charged and so on.

But we spent the vast majority of our time building product features and making the product better.

Grant: So you didn't have a true limit inside of the free version to keep people from going over 10 users initially?

Quinn: I think there was a limit.

And for about nine months, we didn't realize that there was bug and the limit wasn't actually checked, so silly stuff like that.

Grant: Great. But probably more usage and more advocates if it was really working inside of a company, and then you can come in with a sales team.

Do you have a sales team today or not?

Quinn: Yeah, we do now. And it wasn't until near the end of 2019 that we built a sales team.

And for me as a founder and somebody who had been doing a lot of the sales, I wish that we brought a sales team on sooner.

I love our sales team. And I think what sales is really smart people who figure out how they can make it easy for people who love your product to go and spread it in their company and buy it, and that is what sales is.

The compensation and just mindset of sales is set up so that it attracts a ton of really smart people who know how to do that.

And if there's a developer founder out there that's worried about, "I'm never going to be able to find a sales person that truly understands my product and audience,"you're going to be surprised.

You're going to be humbled like I was.

Grant: Yeah, no, I agree.

We've been able to find some really super smart sellers to go in and represent us incredibly well with customers and do things well beyond my skillset as a seller as well.

So I couldn't agree more.

And I think those of us with a pretty technical background often have a slightly bad taste in our mouth about salespeople initially.

And I think when you find really great sellers, you realize that they do add to the customer experience, they do help solve problems, and that they're navigating complex organizations and lots of different things, and they add a ton of value.

Quinn: Yeah.

And I would suggest, if someone thinks they might start a software company in the future, and if you're at a company right now, get involved in the buying process of some software so that you can see what it's like to work with sales reps from a company whose tool you really want to use.

It's going to teach you so, so much.

Grant: Yeah. That's a great idea.

And it's a great way to see lots of different sales motions and realize that there's good and bad.

Let's rewind back a bit more. So you went self-hosted, did it instantly take off?

It sounds like it took up some amount of iteration with these early customers.

You said 2019 is when you really felt the pool. What happened in between those two points?

Quinn: It just about immediately took off when we went self-serviced and self-hosted.

And we have done a ton of things since then, but there was latent demand for code search, and we were more than busy serving the demands that came about when we went self-hosted.

And again, that's because it cast the net really wide.

And it was nice that by the time we were talking to these companies, they had already set up Sourcegraph, gotten users, gotten their code in.

And so it wasn't us saying, "Hey, please try our thing."

It was them coming to us and saying, "Hey, we've got it rolled out here, we want it to do these things. Can you help us get this other team using it?"

And that kind of stuff keeps us really busy. We learn a ton.

And we were able to document some of the success stories from those early customers.

And then that got us more customers.

And then also this diaspora of developers, where if you're a dev at a company using Sourcegraph and you quit and you go to the next company, a lot of people would get in and say, "Wait, you all don't have code search, you don't have Sourcegraph? How have you all been coding all this time?"

And they'd bring us in. So that diaspora was really powerful.

And that's an aspect of our product and business that we didn't quite appreciate.

The fact that we are an end-user product means we've got way greater awareness among all the devs at these companies and people move and people talk.

Grant: Yeah. That's actually a really powerful motion.

I was talking to the founders of Segment years ago, and they said that they did a bunch of research and figured out that that's their most valuable customer acquisition channel, was people leaving generally small companies and going to big companies and then bringing them in.

So it is definitely a very powerful way to do it.

But I'm also curious, you were at how many people at the end of 2019?

Quinn: Maybe 20 people.

Grant: Okay. And you'd raised at that point, like 10 million? Where was the funding history?

Quinn: Yeah. Around 10 million.

We had done a series A and series A1 as well.

And so then end of 2019, we made some other big decisions.

For example, we decided to go all remote, having been partially remote and we felt that was really working.

Grant: You did at the end of 2019?

Quinn: Yeah.

Grant: Excellent timing.

Quinn: Yeah. Of course we had no knowledge of the pandemic, but it was timed well.

Grant: Of course, yeah.

Quinn: We were able to keep moving without skipping a beat and be there for our team and our customers.

And that also coincided with a lot of other trends in the pandemic that made every company out there realize just how important software is.

And for us, we raised our series B from David Sacks at Craft in February of 2020, right as more of the pandemic news was coming out.

And so we had an ability to grow quickly.

And then all of a sudden, overnight, companies were thrust into a totally different world where in the past, as a dev, you could go and tap someone on the shoulder or go to lunch with them and ask them, "Hey, how did this code work?"

You just had so many more ways to understand code, get your questions answered, make these big changes.

All of a sudden overnight, can't tap anyone on the shoulder.

So you need a way to understand code on your own and code search does that.

And you also saw companies that overnight had to shift from, for example, building physical restaurant point of sale systems to building an app and shift 1,000 developers from one business unit to another so that the company could stay alive because the pandemic changed everything about their industry and market.

So that's 1,000 devs that suddenly need to onboard in an environment where they can't tap anyone on the shoulder.

And you also just generally saw companies make bigger bets on soccer and technology as their savior.

So our business really started to accelerate then, and having found that product market fit that need from every company to get better at billing soccer in this distributed world, we were well positioned for that to serve all those companies out there.

And so we really grew very, very quickly at that point.

Grant: Oh, that's really interesting.

Fortuitous timing both on the going remote and then raising your Series B and then yeah, to your point, the idea of if software was eating the world before COVID and the pandemic hit, it became pretty clear that once we were all stuck in our homes that software was the world.

And so you've seen this, the run up of enterprise software valuation because it really is the foundation of the transformation of all these organizations.

Truly digital transformation was happening, they had to become software orgs.

They needed their developers to have the tooling to move fast, they could build better software and get into the hands of customers.

So that makes it of sense to me. Scaling from 20 people to 200 in less than two years is a pretty big challenge in itself.

Did you have executives? Did you have any other leaders other than you and your co-founder when you hit that product market fit and raise the B or did you go out and build that team after the fact?

Quinn: Combination.

We've had people that been at Sourcegraph for many years who are in executive roles and we've brought on some new executives in the last year, year and a half.

So I think it's important to always think about who do we need, what are the challenges ahead of us?

And we have an amazing team.

I'm so grateful, I would dig ditches, I would do anything with this team, and I feel lucky that we get to work on something so fun and cool.

Grant: So you've built this team, you prior to these folks, but you mentioned you were doing early sales, did you actually find a VP of sales or CRO or someone to really help mature the go-to market side?

Quinn: Yeah. We brought on a VP of sales, actually who had been at Segment before.

And we brought on a VP of marketing that had been at Fastly, and they are fantastic.

Really appreciative of their contributions as we've grown from a much smaller company in every single way, customers and revenue and team.

And we still are faced with this challenge of, code search is something that most devs and most companies have never heard about.

It's not as though we're convincing all these companies to switch from a worse code search to a better code search.

In some cases they're using open source code search tools like OpenGrok, which was built in 2004 at Oracle, our son, now Oracle, but we really have to educate the market.

And so our challenge is just a lot harder, and I'm grateful that we got a team that's up to solving this challenge.

Grant: Yeah.

It is interesting because, to your point, it's not really an existing big category that everyone knows about where there's like clear leaders and there's quadrants and all the Forrester Wave, all these things.

And so you're really defining a category and it's one of those challenges of category definition is, to your point early on, you don't necessarily know that you're hitting all the right features.

You don't know if it's valuable because it's not like there's something else out there that you're like, "Oh, we're going to do all of these things better, and people are using that tools and we'll get them to switch over."

Are there any other lessons you've taken away from trying to define and create a category?

Quinn: Yeah. Everyone always says, if you think you're creating a category, you're probably fooling yourself, so don't think about that, you just need to redefine the category.

And it turns out, you're always in a crowded space.

And I got that advice in the end, it's my decision whether or not to follow it.

And I made the mistake of thinking that was true for too long of not coming out and saying, we are building code search, of thinking, "Well, code search is something that no one knows about, and so we don't want to do that. What we're actually building is," and there's a long list of things we tried to use to describe Sourcegraph that failed like new developer platform or code intelligence tool, and all these things where then it put us in a competition with other companies.

And again, I look back in hindsight and feel dumb for doing that. And we really simplified it.

Once we got the confidence, I think, of having some early customers that were really using the product and they would call it the code search, so why would we ignore what our early customers and fanatic users were saying?

Why make it sound more complex? They were begging us, just call it code search, stop dancing around the bush.

Grant: That's really funny.

Quinn: We finally called it code search and things have been so much better ever since.

And then another type of advice that drove us in the wrong direction there was all this well-intentioned advice that is like, "Don't say what your product is, that's an implementation detail. Instead, talk about the value. And if you were to take that to the extreme, then instead of calling Sourcegraph a code search tool, you might call it a developer of value creation engine."

Or someone suggested, "Well, what code search really does is makes it so that developers can actually get off work at 5:00 PM instead of needing to work longer. And it means that they can spend more time with their families."

I have two kids, I love the idea of spending time with my family, but that has no value when we describe what Sourcegraph is.

And so it was just getting that confidence that we are building code search, and if someone doesn't think that's valuable, we want to educate you, we want to win you over.

We want you to see how all the other developers and companies you know are using code search and how amazing it is, and you're going to feel that at some point, but we're not going to win you over by saying it's some other complex thing, we want to introduce you to code search.

Grant: I love that. That's so funny.

I think it's extremely true for developers and probably more technical audiences where it's like, number one, they're like, "We don't want bullshit. What does this thing actually do? Describe it to me in the simplest terms so I can decide if I want to explore it more."

And the whole like, "Here's the value that it creates for you."

It's like, "We'll decide that ourselves, we'll figure that out. I'll tell you if it does that or not."

And so just saying what it is and a little bit of why it's valuable, like, "Hey, here's some of the problems it solves," because you point out like these different use cases, but you don't need to sell so much value.

I love that. It's so true.

Quinn: Yeah. The value is the follow up.

Some specific points of value that we can follow up on with code search, and these are all real.

We have customers that can find and fix vulnerabilities in hours instead of days.

We have tons of surveys that customers ran that show their devs are saving 30 to 60 minutes a day when they use Sourcegraph.

We have big healthcare company that said in the middle of their claims process reconciliation, the busiest time of the year, their database went down, they needed to find where they're hitting the database in their code, Sourcegraph meant that they could get their site back up in 20 minutes instead of, who knows how many hours?

And we can show all of that, but if I led with that, people would just be scratching their head.

And yet, another thing that makes this so pernicious is, when a developer is hearing a description, they want to hear real facts, but when it's developer founders like us, I think sometimes we underestimate our business acumen and it's very easy to be swayed by, for example, venture capital investors that have seen all these other amazing companies and their advice is, "Well, that sounds like you're talking about implementation detail."

And so again, I just, we finally got the confidence by getting some great customers and great users, but I would just suggest that other devs out there that you probably have a better sense of what your product does than people that have seen it for 30 minutes on some slides.

Grant: Yeah, it's so true.

And the other thing that, and you did an interview with David Sacks on his new Callin app which is great, folks should go listen to it.

It's a really great interview, but like one of the things that I loved similar, he just didn't believe in the value of self-hosted modern on-prem software.

You had to teach him why that was doable now, whereas he came from this pure SaaS background. And so the thing that I think is constantly true is the ecosystem is going to take the facts from the decade before and try to apply it today.

And as we all know, the market is actually pretty efficient, and so if you try to use what worked really well a decade ago, the effectiveness of that is gone because as everyone's already trying to do it.

And so you have to really innovate and you have to take a step out and say, "Look, it might seem like heresy to say we're not going to tell you the value, we're going to tell you what it is. And we're not going to do it as a SaaS product, we're going to make it be self-hosted."

But that's where the market is today. And if you want to succeed today, you need to do what's working now.

There probably was a time 10 years ago when actually talking about the value was the most important thing you could do because everyone was talking about what it was, no one was talking about the value, but now that everyone has taken that as gospel, it's no longer true because now everyone's just confused by all this marketing jargon that's out there.

Quinn: Yeah. That's right.

And 10 years ago, it probably made sense to deploy on the cloud because I was really pre-Docker, pre-Kubernetes, but five years ago, very different.

So it's crazy how fast things change.

One funny thing with investors, and you mentioned David Sacks having run and founded Yammer, which was on the cloud, which replaced some on-premises old, tiny, similar software from the 2000s.

He had been through that, he had seen that the cloud was so much better, is investors love when you tell them why they're wrong and all they have to do is believe you, and then they have an edge over all the other investors that they view are now the sheep and they're in on the secret.

So in a way, the heresy is what investors are looking for. That's what they want to bet on.

Grant: Yeah. Well, I think some smart ones are, but there's a lot of sheep.

Quinn: Well, I think they're not trying to be sheep.

Grant: No, no, they're not. They're not.

Quinn: Yeah. It's hard to make the right bets and it's scary.

And look, I wasted many years of my life, as I've talked about, by not making the decision that seemed foolish, but that seemed in hindsight obvious.

So I get it, it's tough.

Grant: Yeah. I think maybe the other thing I'm picking up here is, just believe in yourself, the idea of all this advice, synthesize it, take it for what it's worth, test it, but if you think you have evidence of the contrary, you're closer to the reality than somebody else trying to give you the advice, and so you have to make the decision for yourself.

Quinn: Right. And if you can't believe in yourself, you're screwed anyway, because no one's going to do that well if they're just really good at agreeing with other people.

Grant: Right. Exactly.

One other thing I know that we both do, and I'll see if you want to talk about it, but we both got pulled into something called spearhead.

I think I've been doing it for two years.

But the idea is that so the AngelList folks created a model where they give a million or two million to founders to create a micro seed fund of sorts.

Have you been actively angel investing?

Is that something you've been doing as part of spearhead?

Quinn: Yeah.

I was doing it a little bit before and then I have loved participating in it and just getting the community, the other founders that are also thinking about, what else is new out there, what can we help with?

So I love it. And it is so exciting for me to see companies that are just getting off the ground that have such potential.

And if I can help them in any way not repeat the mistakes that I made, that's great.

And I also love when they completely ignore me and do what's right for them. It's so educational.

And it also just gives me a sense of what it's like to be on the other side of the table.

Grant: Yeah. So true.

The one thing that I've learned from this is number one, how funds raise money from LPs.

I think it's been a really interesting insight to see that part of it, but then also, how do you think about evaluating a deal, when to invest in it or not, it's really informational and interesting.

And I think for me personally, it keeps me really close to the ecosystem in the market and knowing what's happening.

So I've enjoyed it. I'm sure you probably do it much like we do, which is like a very, very small side project where you only take inbound and stuff that you get referred.

It's not really like you're out there trying to source up a bunch of deals with publishing your thesis.

Is that how you think about it as well?

Quinn: Yeah. That's right. We have a lot of stuff to do. We have day jobs, it's busy.

Grant: Yeah. We have day jobs, we have teams, but it's something you've continued to enjoy doing?

Quinn: Yeah, definitely.

Grant: Yeah. Me as well.

Quinn: What do you think you get out of it?

Grant: For me, I just love seeing how different folks are forming up companies, what they're thinking about, angles that they're looking at.

I still talk to a lot of these founders.

I was actually on a call with one of them that I funded today, and just talking about, he's raising his Series B, and what's he seeing in the market.

He's doing some partnership with AWS, and what is he seeing?

And so it becomes just an extension of your founder network, but I've found that the folks that I've been able to write checks behind, it's just an extra reason to chat.

And so it pulls us a little bit more closer together and gives me reason to check in and see how I can be helpful.

And obviously, we've been doing it two years, there's no returns, but for me, it's not even really about the money, it's more about the ability to engage with these companies and to stay pretty relevant and active.

What else are you spending your time doing outside of--

You were pretty active in the Go ecosystem for a while.

I think one of the initial ways you can went to market was around Go Search.

Have you stayed active in the Go ecosystem?

Quinn: Yeah. I love coding.

That's why I got into this whole thing in the first place, it's why I started Sourcegraph, so there's no way that I'm ever going to stop coding.

And for business reasons too, I need to stay on top of what it's like to be a developer.

So I've been coding a few fun projects, like something that will take Markdown in Emacs or vs code and put that in a Google Doc and then sync it so you can update it.

That's a fun project to work on.

I've been working with Demo the new node, like JavaScript runtime, which is cool to play around with.

It has much better sandbox model. And I like the way that it is package management.

It feels like the Go of JavaScript in a way. Have you played around with that?

Grant: I haven't. No.

Quinn: That's very cool.

And I'm also just working on an airline simulation game, something where you can say, "Here are the airlines and airfares," using all the technologies that I want to be using and playing around with, like ES bill and Static React, server-side rendering, all these things.

And occasionally, I'll make PRS to Sourcegraph itself and bring some of that in, but it's a nice sandbox to play in.

So anyone who tells you CEOs, founders they can't code, hey, you got hobby time too, and that can be coding.

Grant: Yeah. I love that.

And it's a great way to explore different technologies like you're doing and then bring those into your main workflow.

What do you think about working with the Google Drive API? How well is that done?

Quinn: It's really interesting to see...

Now that I'm editing Google Docs in my browser, when I do that, I think of, what are the API calls that are being done?

And it seems like they use an internal API.

The API is not exactly what I'd expect, and it's not exposing a lot of the operational transform or other primitives.

It's really fun writing something that takes a Markdown, parse tree and converts that to the commands that will batch, update a Google Doc.

I think the next thing is how to do Delta update so that if you publish a Google Doc to Markdown, someone else has updated it, how can you make it so that's reflected in your local copy?

And I think eventually that needs to turn into a full editor extension, not just something that runs and looks to the file system and updates it.

Grant: And then are you version controlling all of these, is that the main concept to commit everything into version control and then have it deploy into publishes Google Doc or?

Quinn: No, it's not going to be some automated workflow like that.

I'm not really sure where it'll go, but I just wish that someone had taken the like VS code or Emacs live share experience with shared cursors in the editor and made it so that can also be a Google Doc.

I'm surprised no one has done that.

You've seen like Hackpad, which was like Google Docs, but with Markdown, but that's a separate site.

We use Google Docs, Sourcegraph, everyone uses it, it's just like the default.

And I want to have all my editor shortcuts and they're like nice focus mode that you get in your editor available when editing Google Docs.

Grant: Yeah. That's funny.

There's all always a debate here for us, it was always like Google Docs versus Markdown, versus different things.

And so I saw you tweeted that out and I thought that was funny because I was like, "Oh yeah, we've experienced similar problems."

Quinn: Yeah. You shouldn't have to choose between Google Docs or Markdown.

Grant: Yeah. I know.

Quinn: You should be able to say yes to both.

Grant: Say yes to both. Cool. Quinn, anything else you want to add in before we wrap this up?

Quinn: I would once again say, if you are building software, think of making it self-hosted single tenant first, I think it can help you get to market way faster.

It can help you get the ideal early customers. I wish we had done it.

So look at this as someone who has spent years of their life not doing that and realizing that once we started to do that, that's when our business started to take off.

So single tenant, self-hosted, give it a try.

And also, if you haven't used code search before, then try out Sourcegraph.

Grant: Amazing. Quinn, thank you so much. This is great. I really loved the conversation.

Quinn: Yeah. Thank you.