Efficient scaleups in 2024 vs 2021: Sourcegraph (with CEO & Co-founder Quinn Slack)

Every decision that I made back in 2021, I now regret. The backdrop was that developers were so in demand and you had a lot of people that had understandable but unrealistic expectations. A lot of our managers' time was spent managing the growth and trying to manage in peacetime mentality. In hindsight, it was not peacetime and this idea of how do we do everything a little bit faster? How do we do everything higher quality? How do we say no to more things?

I think a lot more companies have adopted that now and I think a lot of companies in us included I really wish that we had done a lot more of that back in 2021. Welcome to The Pragmatic Engineer Podcast. In this show, we cover software engineering at big tech and startups from the inside. After each episode, you'll walk away with pragmatic approaches you can use to build stuff, whether you're a software engineer or a manager of engineers.

In this episode, I sat down with software engineering and founder Quinn Slack to talk about how the reality of tech scaleups have changed over the past few years. Quinn is the founder and CEO of Sourcegraph, a co-sourge tool and co-intelligence platform. Sourcegraph was founded in 2013 and has raised a total of $248 million in funding so far.

In my conversation with Quinn, we cover details on how Sourcegraph changed how it operates in 2024 versus three years ago in 2021. Practical AI and large language model use cases and advise on how to best use them. Why Sourcegraph changed from location independent pay to location based pay and a lot more? Let's jump in. Before we kick off, would you mind starting how Sourcegraph started, which has now been 11 years ago and how did things evolve since then?

Yeah, I have been a developer all my life. I love coding. Can't pry me away from it. I love that you get to build something and then just get it out there to millions of people. Nobody knows where you're from or what age you are. It's this incredible equalizer in this incredible sense of creation. But I found that that spark of creation, you don't really get that when you're working on these massive code bases.

So I was working on some patches to Chrome and Open SSL and Firefox. And to even understand those code bases, I would set up a Coatsarch tool. And at the time this was back in 2009 or so, the Coatsarch tools are very primitive. It was like, felt like you are on old MSDOS library computer. And then I went in and worked inside some big banks and they had so much code. They had things like SharePoint.

And it was so hard to figure out who even owned this code or why is it broken. So we just said there's got to be a better way. And my co founder beyond he had been at Google where they famously have this amazing Coatsarch tool that everyone loves. They got a lot of great internal tools, but this is like the most loved. What's it called? It's called code search.

One word, capital C, capital S. So we knew that there was a better way to do it. And we just wish that we had that kind of amazing code search tool inside these big banks or inside these projects that we were hacking on in open source. So we decided to go start source graph. And we knew that code search was something that was in this perfect intersection of something that we would use ourselves that we could build. And that would be really valuable.

Because ultimately it means bringing all the code from all these different code bases. Many cases different code hosts, different languages. And it was this thing that every developer would use. And there were not a lot of tools like that at the time because everything in developer stuff is so fragmented, different languages, different editors, different CI systems,

tons of repos. Yeah, people are so opinionated, but code search was this odd gap that we could fill and make the best code search. And then from there, there would be so many other things that we could do being the only tool that's got all the code and all the devs.

So 11 years later, here we are. We probably thought that it would take us like a year to do all of this, but 11 years later, here we are. And we got Uber as a customer, as you said, they're one of our very first. And now we got a ton more. And love and every single day of it. But speaking of changes, so one change that has been a huge one is how scale up. So you're a scale up. How, how large a source graph, roughly in terms of like people funding.

We have about 180 people on the team. And that this globally distributed as far as funding. I believe we've raised a little over 200 million. And speaking of which, so you're considered what a scale up is, you know, you pass the early stage start up, you're actually like a mid stage, late stage start up the scale up, depending on how people put it. I mean, I don't want to put labels on it.

The point is like you kind of gone through you're really in that growth phase. And in 2020 and 2021, this was a very different time to build a scale up like like yours, then it is today.

I'm just curious to hear like back then, you know, before you knew how how the world changed both in terms of LMS, both in terms of the funding environment. What were you seeing back then and what were your kind of, you know, goals and how has the reality changed in terms of source graph and also talking with other other founders. How do you see.

You know, this big big shift on a lot of things. I feel like we've been doing the same thing that we set out to do 11 years ago. And there's a lot of consistency. I think that's been really good for us. We've had this mission to make it so everyone codes. And our product code search has stayed the same. We've done stuff on top of that with Cody.

And for us, it took us a while to get that initial traction. And Uber was one of our first customers. But that was even five years after we started the company. And wow. So it was like five years to close your first or one of your first clients. Yeah, I'm glad we stuck with it. And there are a lot of reasons why I think for our product, for our market, it took us longer to get there. And we were getting a lot of users along the way.

So there's never any doubt, but it took us a little longer. And what that meant is by the time we were scaling up by the time that kind of pandemic frenzy was leading to massive dev hiring, massive investment and everything software related. We had history. We had staying power. It was clear that we were committed and we'd been moving in this direction for a long time.

And we were able to make better use of that money, better use of that momentum than I think a lot of companies that were one or two years old at the time and hadn't quite found their identity. It's not to say that it was easy, but it really accelerated our growth in an incredible way. I mean, you know, more than 30X growth in terms of revenue just in those few years of the pandemic.

And then of course, we and many other companies in our situation saw that a lot of the customers that we had sold to were really struggling due to the economy. This episode was brought to you by Paragon, the developer platform for building customer facing native integrations into your product. Whether you need to build two way things with your customer CRMs, ingest their Google Drive files or Slack messages as context for a rag AI app, or provide them cross up automations and agenteic workflows.

The list of integrations your team needs to build will never end with Paragon's SDK embedded in your integration platform. You just need to define the integration logic. Paragon handles all the plumbing, including authentication, event listeners, fictional webhooks, rate limits, circumvention and comprehensive monitoring.

This is why engineering teams at AI21, copy.ai, and over 100 other engineering teams at B2B SaaS companies use Paragon, so they can ship integration seven times faster and focus on their core product. Visit useparagon.com slash pragmatic dash engineer to see how Paragon can help you accelerate your products integration roadmap today and get a $1,000 credit on their pro and enterprise plans. Start your free trial today. That is useparagon.com slash pragmatic dash engineer.

It's kind of sounded like you also saw so you saw this this really big increase in in 2021 or 2020 and customers and interests and I guess people companies opening their wallets to become paying customers. But I'm interested in how what were things that you change and how you actually ran the company like let's say from from 2022 or 2023 in terms of any practices hiring. Like did you did you see like different issues which were attention those kind of things.

Yeah. I read this one quote from someone that said every decision that I made back in 2021 I now regret and I really identify with that. The backdrop was that developers were so in demand and you had a lot of people that had understandable but unrealistic expectations they would join a company where they saw the market cap of that company or the valuation of that company grow by 10x from the time that they started interviewing until they got the offer in some cases.

And that expectation is something that cannot be sustained by any company even in a really frothy environment even if that continues.

And I see ultimately were you know wish that I had been way more aware of this but found that there were a lot of people that you know I think a lot of companies source graph included joined because they saw it as a rocket ship and did not join because they absolutely love code for us that's the most important thing when we hire a new engineer we want to know that they absolutely love code. And same thing probably for other companies with respect to their mission.

And I found source graph with a team of people that were all incredibly talented but didn't have that same kind of hacker that founder that you know let's create something from zero to one mentality that we had earlier. And that made it harder.

I also saw us growing a lot of my time a lot of our managers time was spent managing the growth and trying to manage in the kind of peacetime mentality which I mean in hindsight it was not peacetime yes money was freely available but it was the most amazing growth opportunity and I see so many more ways that we could have seized that.

And this idea of you know how do we do everything a little bit faster how do we do everything higher quality how do we say no to more things think a lot more companies have adopted that now and I think a lot of companies and us included I really wish that we had done a lot more of that back in 2021. There are some new features new products that we came out with that I don't think should have made the cut and that's on me as CEO I should not have allowed that to happen.

There were people who especially early career people who I think that we did a disservice by not telling them that their stated goals being like their idols in the coding world requires really hard work especially in that early career time it requires working nights it requires working weekends it requires grinding and that's not something that they have to do but if they want to achieve their stated goals they have to do that one of the really awesome.

Really awesome things we did was bring on Stevie Aggie as our head of engineering and you got him out of retirement right yeah that's that's right I think that he was looking for this kind of opportunity because he built a lot of the stuff around code search at Google and when we were starting source graph we thought he was our nemesis and he was our biggest enemy he was going around at Emax conferences and talking about the thing he was building and ultimately you know we found him and just such awesome fit in what he wants to do.

And what he wants to do and what we needed and he even though he had been at Google and a lot of people at Google you know it's not a startup hard charging environment but he just naturally had that and so you know that focus on we are building something let's just iterate faster do everything faster let's hold the standards incredibly high that's the kind of mentality that I think you know we in every company probably needed a lot more of him coming on was an awesome just to do that.

And that was an awesome just infusion of of energy and momentum for us and when I think about the difference how we work today versus how we work back in 2021 it's just so much more focus so much faster shipping everything that we do used to be primarily self hosted enterprise and that meant that the feedback cycles were at least a month for customers to go and try something.

And we have a habit so we can you know ship many times a day and we ship new versions of Cody and code search many times a day we just sped up everything and we've got a team that celebrates that rather than that you know sees that as something that's stressful and then from this period of like this is really big boom in 2021 what is the biggest

thing is that you're taking away from yourself or that you would you know advise your former self like something that's taking with you for me it's stay really close to the code and the product and I love coding I started the company because I love coding our product helps other people code and if I'm not coding all the time you know pretty much every day then I'm not going to be is fluent with all the new stuff that's happening I'm not going to know every single corner of our product is really good.

Of our product as well as I should to make the right decisions and there's a lot of people who if they hear that the CEO of this company codes they might think oh that's I'm going to be cleaning up a bunch of messy CEO code I try not to code in the line of production as much but I you know we've gotten to the point where it really does help me do a better job as CEO make better decisions and where it's something inspiring and it gives people from all kinds of different functions

whether it's engineering managers or PMs or even our our CFO you know it gives them inspiration to go and code more and says that you know that it's okay because there's a lot of advice out there that says unless you're a full time software engineer you shouldn't write a single line of code and I just think that's crazy it was crazy back then and it's even more crazy with AI that makes it so much easier for people to to dip their toes encoding is interesting because I don't hear many or even any CEO say that they do code daily CTOs I do here.

But I guess if anywhere it would make sense when when your product is is a tool that developer you use day and day and day out yeah the shop if I CEO codes and I love to see that I bet there's others so are you conscious doing it or you're doing it because you love doing it or is it both both you couldn't prime away from it you can go check my commit logs in the Cody and search referee goes.

It's as public as well right that's right love it what is your kind of approach and thinking of how you approach the space you know like we we've seen approaches for what get up co pilot is doing there's other like more bold approaches like Devon building a fully autonomous AI agent what is your thinking of what works today and what you're hoping is going to work let's say tomorrow.

I am so excited by this space I think it's so obviously the future of software development how do you eliminate the toil from humans and there's two things that matter one is the context what information does the AI have access to and to is how are you thinking about automating it and on how you're thinking about automating it we take a different approach from what I see other people doing.

I see a lot of people fixated on let's get a totally new UI for software development that is not in the editor and that stuff demos really well I think we'll probably even get there eventually but I kind of think that's like those auto company CEOs who like 20 years ago would get up on stage and show off a dumb look and concept car with no steering wheel.

It looked kind of dumb and yeah it's like probably the future but that kind of thinking is not what got us to where we actually in San Francisco where I live have self driving cars that are going all around the city what got there is putting a steering wheel in the car and going from the human driving 100% to 99 to 98 to 97 collecting the data along the way and having AI bite off the easy parts first the things that are wrote that are you know part of every task like up there.

And I think that's the thing that humans often forget to do or bad at doing or make typos when doing and I think that the way we get toward 100% automation is not by setting the expectation that we can do 100% and then disappointing people in some different interface and if the tool only gets 90% of the way there then you got to switch to the

editor and it's painful think the way we get toward 100% automation is by starting at zero and that change locked thing might represent 0.1% of dev work and we just keep on piling up those 0.1% that we can give a little bit more structure to that we're using AI but we're not just dropping the whole thing and having AI spit out a one shot thing or something where it iterates with itself because AI checking its own work.

You just like piling shit upon shit is is not end up good you got to bring ground truth in and what you say change log just a thing straight I think that's something that I know you're doing but not as many plays you're doing by that you actually mean the change log of the product

that's right well I see I actually that that's an interesting concept where you're doing it linear is doing it if some companies are doing it I think it's making a comeback now but it kind of disappeared for a while why do you see

change logs being important that's an interesting area well people just want to know what's new in this release so when they get the new version of Cody or source graph they'd just like to see that so she's got sections for changed and fixed and added do you think there's a connection between shipping change logs and a focus on on shipping important and good stuff.

Yeah well even maintaining a change log requires discipline and even that is hard to do to have one very simple process that developers remember to do it all the right times even that is difficult and change log it also is a really easy way to see did we actually ship a lot if you don't have much to put in your change log well that should scare you. I guess this is yeah this is doing two things with with one like you're achieving multiple goals with just one thing two words of one stone pretty.

I love it. So you know going back to the kind of two parts of AI for AI to get close to 100% of what a software developer can do which is way far in the future part of it is just the approach to autonomy you know we're taking this kind of bottom up approach but the other part is you got to get that ground truth in so you got to make it so the AI can check its work.

You cannot have the AI review its own code that you know can help if you're a junior engineer you want to quick pass but that can't work especially when you have many different invocations of it you ultimately need to see does the code type check does it pass tests does it deploy when it

is there a large number of errors mean if you fast forward this all the way to the logical conclusion you want to see does this code change result in increased revenue when you send real or maybe shadow traffic toward it and no one is even close to doing that

forget about AI even just having an elite software engineering team at a company that is building amazing products engineering great revenue I would argue that even not they're not doing the last step for example do you think it might be that these AI tools might make us more ambitious to actually do that could that be that we might be able to the company is a teams that actually

use smart automation and they free up their time they'll have more space for these more ambitious yeah I think so I think because you're going to see the tooling landscape get turned over a lot now that AI is going to be a primary consumer of these tools so think about the logging tool the issue tracking tool the you know deployment the security scanner all these things they were made for nice you eyes and enterprise features for humans consume but what's the AI version of data

dog when you don't need all those bills and whistles but you just need something that is really fast that can you know pipe some of the performance and log data back to AI think you're going to see a lot of stuff turnover you're going to see also there's now increasing ROI from really fast builds it was always the case for humans but it really fast build is something in the order of 30 seconds or a minute and most companies are nowhere even close to that but if you have a really fast

build like let's say that given a dirty get repo you know a diff on your local machine if you could have one command that runs all of the tests that are necessary because that change and if that could run in a hundred milliseconds or 500 milliseconds then you could have the AI iterate try a thousand different code changes see which ones pass if you can then bring in really fast feedback under a second from performance data or the security

scanner then you can help the AI iterate help it narrow the search space and make that iteration more successful and I think knowing that that will be really valuable I'm already seeing a lot more investment in really fast builds really fast everything even in the you know node JS world you went from you know really slow node slow npm now there's a lot more competition what are the areas that because we've seen

AI is really good when when you can bring in context what are areas that you see this type of these type of LMs or this type of AI not necessarily be be that good to use in terms of I'm not just talking about coding but in terms of the developer the developer process building software basically

I think it's really nuanced and you have to have a good mental model of what's actually happening to know how to use it that's something I don't think we do is good of a job as we need to about you know creating in our users I think a lot of tools need to get better at that and one example of this is we see some people go and ask Cody just you know freeform text question what are all the calls to this function or you know what's the history

and just that question we don't kind of it's not a command line that's completely arbitrary they got to at mention this stuff and we can do some stuff to detect it to you know bringing that right data but we haven't necessarily thought of every kind of data that's that's been brought in so

so think that if you're using AI you want to understand that basically the way that code chat works in any product is like same thing if you ask chat to you Pt the question but you paste it in a bunch of files that you think are relevant above your question and that's that's what it's going to be

and a lot of people don't understand that and it's just an expectation setting game the debugger is really make a huge difference in making your tools your workflow better I'm not sure we have that with here yeah that's I think a component of letting it iterate letting it try things letting it understand the context see what are the actual values that this variable can hold at runtime

the in that is really important data and really good committed human engineers will go and get that data but the embarrassing thing is developers probably spend 95% of their time using like print F debugging and don't actually use these tools and going back to what we're talking about earlier around all these dev tools that proliferated in like 2020 and 2021 so many of them actually are amazing products

but devs just don't remember to use them and I think there's also this kind of value unlock that you can get if you make it so easy for a dev to use this flashy newfangled production you know runtime perf tool if it's in their editor if it's one click away if it's so easy for them to get the data they don't need to go and sign in again or remember

that is a way for that tool to go from being used by 1% of the devs at a company to I don't know 50% daily just that little change bringing it into the editor there is a fear especially for new grads entering the software engineering market or hoping to enter the software and your market they're seeing all these powerful elements Cody Copilot and a lot of other things they are capable of doing way more than we've seen

you know just a few years ago and there's this fear saying hmm are our jobs going to be in demand especially as a new grad will I have a future in the industry well what what is your take on on this worry I see the new grad engineers being way more fluent with AI and using AI when coding way more than senior engineers and other people in the industry

so I'm not worried about the junior engineers that have that kind of hustle I think they probably do not quite realize how little adoption of code AI there is in the industry and how they're relatively early adopting of it is an advantage for them so much so that they the people that are in every then probably do not even know how coding has changed and how the way that you know that junior engineer codes is so different from the rest of the team

now that doesn't mean that they're going to get hired by those companies but that means it's fundamentally they're creating value and two ways to look at this I think software engineers have taken jobs from other industries for the last 40 years and now it's time for software engineering to turn over

but also the field is constantly turning over I mean if you were coding the same way today that you were 10 years ago well that just would not work so many things have changed the editors the languages the deployments so you're constantly turning over and I don't see any reason to think that this will mean you know greater shift by any order of magnitude I think people are used to adapting on software engineering

and if anything think I always want to step back and and how do we think bigger about this it will probably mean that the value of a software engineer who knows how to use these tools has gone way up so much so that they might not need a boss or they might instead of being very far from the value that they create and the product that they create they might be able to be way closer to that which means they're going to be doing the job of a PM and an EM

and you know salesperson and all that means they're going to make a lot more money in the future so I'm really optimistic I think that people just need to continue to adapt to this change and everyone in software development has been doing that ever since they joined the field

and what do you think about the fact that these AI tools are here they're going to get bigger they will produce a lot more code we're going to see a code explosion everywhere in terms of the produce code how will that impact the industry because we used to talk about or I remember talking about people and you can tell me if you agree or not that the more code you have the more liability you have out in the wild needs to be maintained and this we were always talking about humans you need to hire more people to maintain it or the world

to maintain it or bugs are harder to spot et cetera how do you think this dynamic will play out because we're going to see a lot more code that's for sure yeah AI has gotten good at writing new code before it's gotten as good at helping with existing code so it's definitely outstripping its ability to keep your code base high quality when you have a lot of code code search really helps so I feel like we're well positioned to help there

but I think you're going to see AI help with existing code and that's actually the the biggest criticism that a lot of people have about these completely like agent first approaches just like let's automate a hundred percent they might work in some cases on very simple toy brand new projects but in existing code bases certainly the kind that most developers work in they just do not work they cannot understand the code base yet so I think that's the big

opportunity and again if you're going to make a small change in a really complex existing code base you got to be really careful I mean I'm sure you felt it at Uber if you're going to make a change is some core service you have to see at runtime you know what are all the things calling it you have to understand all the changes you have to get all this context you have to really deeply understand that yeah and then you do a stage roll out a really careful stage roll out you you message if it's a really big change actually message the other on calls saying hey I'm rolling this out

I think it's okay but if you see something in your metrics please please please let me know like that that's how you kind of do it because you don't know like if you're going to break in the end what you care about is like will it have an impact for the business specifically will will users or paying customers get stuck or or complain et cetera yeah and that that's probably not going to change in the end you know like we just have new ways of doing it actually feature flags are

are relatively new way you know they came in like ten or fifteen years ago mainstream that is so yeah and until code actuals know how to do a stage roll out know how to notify the on call person until they know how to work with feature flags they're not going to be able to make those kind of changes safely and what I've just described that ability to work with all these other tools goes way beyond any agent that's out there today so I think we will get there we want to be the ones to build

that certainly I'm sure there were not the only ones and when that exists then I think you can have AI go and clean up all the really messy code so I think it's actually fine if companies are incurring a lot more tech debt incurring a lot more messy code to move fast because their ass is probably will be saved in a few years by AI but it's a bet you got to make cautiously

yeah I think it is good to remember that there's always tradeoffs right so like assuming you move faster you might be accumulating type that which is fine again just be aware of it yeah talking of source graph engineering culture last year I added a deep dive or we did a deep dive in the pragmatic engineer on how the company worked and some of the things that I just stood out as as a short recap will have the

article in the links but you have a culture of default transparency globally equal salaries it was a full remote work environment you have DRIs which stands for directly responsible individuals for your projects you you you had job fairs back then I think I'm not sure if see you brought that in or that that was there before and you had RFCs requests for comments and a lot of them you you actually published and you also had well defined levels for the ICM manager track this is just a summary

so this was a year ago and and back then this was up to date I'm interested in in the last year or year and a half what are things that have changed in terms of the engineering culture or the company culture as source graph or at least tweaked yeah most of those are still in place with some tweaks one big change has been this idea of job fair

so just to give some context we found ourselves where we had built code search and that was a successful growing product and we knew that we needed to make a big shift in the company's priorities to go and build Cody as well and to you know tap AI there a few ways we could have done that we could have built it as a feature in code search we could have had the same people trying to build both but we wanted to

make a bigger shift because we knew that it was the future and that's what we've been saying for the last 11 years so job fair was this idea that instead of well defined teams that had long term ownership over areas basically every month or every other month everyone would just re arranged to work on the most important things that we would stack rank and it was good to kind of shock the system to get people really quickly

working on the new thing but as a lot of the team anticipated and as we knew it's not something that works forever and it doesn't create that kind of long term ownership and as an all remote company it doesn't create that kind of team camaraderie so it's clear that it would expire pretty quickly as a way to work

that's something I don't think I quite appreciate it as much I think other people did on the team but for me is CEO you know I have this idea that everyone just always wants to work on the most important thing and they're okay switching on a dime and even if they're okay with doing that that doesn't give the kind of quality that we need

and it's frankly hard to manage so we did that for I think about six months and then we had enough stability we had shifted enough people over to Cody that we went back to the much more normal way of just long lived teams I think though that I'm glad that we did that shock to the system because I feel like if we had gone any more slowly in that transition then we it would have been a real struggle for us to keep up that momentum

and then just to explain like how that job fair worked so you stack rank to have like all right here's number one project number two project like discussing with with you are the people who decided and then people saw that that was a clear priority did you also like say like here's how many people were kind of yeah expecting and then I guess people just kind of like worked out they I guess the top project probably got like more applications if you will

that then you expected you kind of channel down that's right what was the motivation like you said it was good to have the shock to the system which which I agree it sounds like a pretty disrupted but I mean in a fun way like it mostly fun yeah most mostly fun but what what was the thing that made you realize like we should just do something where we kind of like you know like have people choose the most important thing like try to balance those things some of those projects that we started in 2021 that

I ultimately see regret allowing us to get started with and they would not make the cut today they had a life of their own and it's not that they were terrible ideas they were good plausible ideas but they were not the ones that we were aligned as a company around it is being the very top priority projects and at the same time we had people working on them that were working hard that were satisfying customers with them and

it's hard to change that you cannot change that without a shock people were holding on to it and I don't blame them for it we needed to make that really clear that we needed them to change that they weren't doing anything wrong per say yeah but that we needed the company's

priorities to change and in a world that people were coming out of where there was always more head count where you could always do more by adding more head count I think a lot of people had gotten used to the idea that if they were work on something that

showed some promise that they could keep doing that and it's you didn't see in 2021 a lot of hey this thing is good but it's not as good as this other top priority so that shock to the system ultimately it you know mostly worked going back there be a lot of things that we could do to communicate it better just be more upfront with this is a shift but what's funny is I see how much of a mind fuck it was based on how you know seeing how the sausage is made and how

difficult it was and how many things we could have been better but there's a lot of people on the outside who say wow you shifted to AI so quickly can you tell us how to do it and VCs or have me talked other portfolio company so I think the grass is always greener it do sense that a lot of things that you're saying it's we're kind of getting a little bit back to basics and in the sense that like my view is that you know there's like it's a great company if

you ever work on the stuff that they want to work on but it's even a better company if it has a long term future which means that it actually has a business that they're focused on and the company communicates whatever that is and by the way this business changes so in your case like this was clearly you've seen the future coming which which is has now arrived and you

sounds like you kind of just communicated this way yeah and again wish we've done it sooner which we've done it more clearly but we we get better and I mean ultimately every engineer wants to be working on something that's high impact to the business and that is rewarding and I really believe that in 2021 there are a lot of people that were afraid to tell engineers that

something else was more important more of a business priority and there wasn't that kind of financial pressure so I think it's a much healthier much more sustainable world that we're in today where developers working on something as a clear

way to the business they should feel a lot more secure they don't because the world is change and they see even the big tech companies doing layoffs all the time but if they're creating business value then they should feel a lot more secure than they were kind of on a foundation of bubbly money no I absolutely and I think we're it's unfortunate that we're seeing big tech you know let go people even from profit centers or or the cash cow businesses but the realities

that the closer I look to company the companies that are either smaller or more rationally run it is true that if you are adding business value and doing a good job your position should be very secure yeah and I think it's great thing as a software engineer for you to have tools to know like am I providing value for the business and this goes back a little bit to what we talk to would

you know connect your co-changes to yeah I mean there will be some downsides but overall I think there will be like if we even attempt to do that and eventually we're going to get there for sure like we will have attempts and failures but that's the that's the history of software engineering isn't it yeah terms of failures yeah and I can make it so software engineers are much closer to the customer much closer to the value and don't

need as many other kinds of people at the company this episode is brought to you by the enterprise ready conference one they have an SF bring together product and engineering leaders shaping the future of enterprise sass the event features a curated list of speakers with

dirt experience building for the enterprise speakers include people from open AI Vanta checker drop box and canva topics include a management compliance encryption and logging essentially a complex features that most enterprise customers require if you're a founder exec PM or engineering task with the enterprise roadmap this conference is for you you'll get details insights from industry leaders that have years of

experience navigating the same challenges you face today and best of all it's completely free since it's hosted by work OS spots are filling up quickly make sure to provide an enterprise ready dot com that is enterprise ready dot com when it comes to compensation as source gap you are very early to be transparent on the

composition that you offer and now we've actually seen in the US multiple states have passed regulation that mandates doing exactly the same so in California and in New York so a lot more companies in the US are are now actually disclosing how much they're offering for the positions across the US actually when they're hiring in California what is your take on on this this change where works we're seeing like from a job seekers perspective just more transparency on

earnings I think that it's the right thing to do for most companies and they should do that's why we've done it for a long time and we've had pretty kind of sophisticated transparent way of doing compensation it works for our team and we have always had to do something's different even being more transparent about this because back when we started the

company in 2013 DevTools were we're weird we could not compete and pay the same salaries of someone in I don't know FinTech or social local mobile stuff in 2013 and SF so we needed to cast a wide net we needed to find people that really loved what we're doing that were you know first two people we hired one was in South Africa one was in Phoenix

and we needed a cast a wide net so a lot of the kind of weird practices that now a lot of companies are doing came about because we were forced to do it early on I don't know what the impact is though of this compensation transparency because most of the people that are looking at these salaries a lot of their compensation comes in the form of equity and softer engineers in general do an

abysmal job of understanding the value of equity compensation and what you see on hacker news is people grumbling where they have not ever had a good outcome there the people that have had good outcomes they don't go on hacker news and comment back so there's a very skewed and very poor

understanding overall of equity compensation and that's not included anywhere in the offer yeah that that's true well it I think it is a step forward that we're actually seeing the cash part at least and yeah sometimes the bonus is included so that gives you a baseline at least and I guess one thing that you are doing very

differently is that you're you're offering the global how do I say this correctly that's something we changed actually oh you've changed it yeah so one of the things that we used to do just you know initially out of simplicity is no matter where someone was located we would pay the same amount for a given a role yeah location independent pay a couple

of years ago we moved to zone based pay and you know thoughtful transition period this is a big change in many ways and you know part of the reason why we did the location independent was because it was a simple thing to do it's actually hard to come up with what is the right compensation multiplier for this city in the world

and all these edge cases and another thing is because there's a lot of appeals to the fairness of doing that what I what we've learned since then is there's a lot of ways that it is fairer there's a lot of weird incentives that it sets up and it ultimately means that everyone who does get the same equity compensation still as shareholders accompany that cannot you know hire efficiently is at a real disadvantage

so we still pay well above median salary we still are very competitive and compensation but you know you just end up with these weird incentives and that's something that GitLab saw they are a company that many people might assume would do location independent pay because they pioneered a lot of the all remote stuff but they never did that they always had zone based pay and at a certain point we looked around and there is one company in the world

that we could find that had more employees that was doing location independent pay and we looked at their stock chart and it was just a nose dive down so we were just a you know a big aberration there it's interesting that that that you shared how you're thinking has changed because again I feel that the companies evolve the world also changes it and you just want to make sure that you know you're you're doing whatever makes the most sense based on where you are

that's right and for engineers really put on your shareholder hat and think if you didn't actually work at this company but you were just a shareholder what is the right thing to do and that's not just the kind of financial side of it it's the people working at the company want the company to stay around

and they want to be able to retire by a house on the equity and that that shareholder hat another way to think of it as you know put yourself in the shoes of the CEO that is a mindset that I think software engineers would do well to adopt more not saying you know always think that but put that

put that hot on a little bit more and I think that that will make a lot of these decisions make a lot more sense and you'll probably find greater calm and understanding this kind of connected to understanding how you're actually creating customer value think that'll give you a lot of calm

yeah and I guess one thing that I definitely saw when what I kind of looked into why companies are stopped doing the globe the same conversation globally is one thing that that handcuffs you as you cannot hire from places where the the median conversation is a lot higher typically in some of the biggest tech hubs like New York San Francisco London and and that can be a choice and especially early on that that can make sense but that's a definite downside

that any company that does it either has to do weird work around of of doing so or doing that and you know that you can already see that there there's just no like everything everything is a trade off right yeah and as you say I think you're right on like it is worth thinking about the business side of things again if you're on a rocket ship it doesn't like that's a great place to be in if you're on a plane that's kind of slowly crashing down it doesn't really matter if you're

if you it's a different flight isn't yeah yeah I think that any company that still maintains location and pay past you know 200 employees I think it's a symptom of a company that struggles to be real with their employees and to treat them as shareholders and that is the kind of thing that probably means that company is going to have a reckoning at some point in the future so you want to see

that you know that companies that are thinking long term thinking shareholders think how do we make money because ultimately that's where all the salaries come from from making money you're better off with a company that's around for 80 more years yeah then one that's not going to be around in two years exactly absolutely agree so you've now been a CEO at source graph more than 10 years is 11 years isn't it yeah that's right coming up so I I want I was interested in a few things I

think many software engineers who have been CEOs for for this long and I guess you've now been a CEO for way longer than you have been a software engineer but just thinking back of when this whole thing started out because you were a software engineer before how how was the initial transition into this CEO role back in in 2013 well when you're starting out you feel like a software engineer because of founding technical CEO should be coding 95% of the time and that's what you

that's what I was doing I remember that moment when beyond and I were coding up the first version of source graph and we had this spark when it saved us like two or three weeks because we found this piece of code that existed and we'd only been building it for a week so it was like a time machine it it had given us net time and it's been an absolute journey since then I have learned so much in particular once we really started to grow near the end of 2019

and how many of you were around that time and then after so what I'm trying to figure out what the growth means yeah we were around 25 people at the end of 2019 and now we're around 180 just under 200 so we've grown quite a bit and I think software engineers they naturally can do a lot of things if you are

if you're coding your even if it's not a software product for developers you're going to be able to talk to your customers you're going to be able to talk to investors people are very comfortable and familiar with the idea of a software engineer who's now a CEO even in the fortune 500 software engineer CEOs are very much over represented

relative to most other majors like the CEO of United Airlines is a computer science major you can find so many examples like that so it's it's not that hard of a transition there's so many amazing advisors and mentors who will help and for me I think everyone's personality is different but for me the real growth was trusting my intuition because as you grow a lot of people have really good advice and also as you grow they see a sea of sea

who was CEO of the company when it had zero revenue and now when it has this much and you know it's especially as a company is quickly growing you don't think the CEO is some you know expert genius that knows everything and every function and the reality is they don't but you still need a single direction a single focus you need that CEO to be overruling to create that focus and that can be tough because that ultimately means overruling people that probably know a little bit more

in this direction about what the CEO is overruling but the company needs a single direction ultimately and that was a struggle for me to learn because I would hire these really smart people and why wouldn't I just do everything they say and trust them fully and it's not about trust about getting that alignment on a single direction that was tough and I've gotten a lot more confidence in that over the last couple of years as we've grown I see that a lot of other software engineers to when they hire this expert sales person or expert marketer in the field and I want to make sure that we can be seen in the field of the field that's a lot of different things that don't happen at the moment.

software engineers too when they hire this expert sales person or expert marketer, they can't fully just outsource that whole function. And when you say you see a lot of other software engineers, you mean other software engineers or CEOs? That's right.

Yeah, a classic example is a company is starting to grow, they hire a marketer and that marketer makes the website read like just yuck and they do these kind of slimy things and the CEO thinks, well, that person has been at other companies before and a lot of times the marketer is like, I've been at these other companies before and the CEO said really clear ground rules about what we shouldn't shouldn't do. I don't hear any of that. So maybe I should do these things.

That has not happened at source grab, but that's exactly the kind of thing that I see and you need the CEO to keep that ethos of what developers love and how do we win their hearts and minds? Even if you have a great marketer that understands that, they want to see the CEO and forcing that as well.

Do you think you have to go through this learning, I mean, clearly it's very efficient way when you do or is how much of the mistakes that you've done, do you think could have been avoidable if only you've listened to I don't know better advisors or how much is just part of the job of building something new? I wish I'd listened to my co-founder a lot more. We talk every single day. I was just talking to him as I was heading over here.

He has a really strong conviction and is just really good at catching me when I become a little weaker and too nice or something like that. So having a co-founder is really good and other people that have been through the times, especially if you're going through a real growth phase that have been through the times when it wasn't a growth phase, they will have more of a sense of scarcity and more directness.

But the advice you get unless it's from a very close board member or advisor who's really in it, who's like sitting in your exact meetings, I think it's probably going to just be platitudes. There's so much advice out there that if you're a CEO and you're going on Twitter or Hacker News, all you hear is people complaining about their CEO and talking about the dumb things or CEO does. That can create this mentality as a CEO.

People assume CEOs are these super confident people, but actually we're just humans. And if all you read is how every other CEO is dumb, well naturally you're going to start thinking all your employees think that you're dumb and that's going to make you lose confidence. When I say you, that's how I felt. It's seeing enough times of that failing and then really great co-founder, really great board. And now a really great exec team, much better position now.

But I think it's hard to learn to just come into the job having that kind of confidence. And most of the times that someone does come in, it's probably overconfidence because you do need to take some feedback. Finding that the right amount of feedback to take is really hard. When you summarize how a week of yours or a day of yours probably week is a better one looked like when you were starting out a few years in when you had let's say 10 people as source graph and how it looks these days.

And I'm asking this because I think there's a lot of software engineers who again, one day they're thinking, you know, I'm in this job at the startup or scale up and learning all the skills. One day like to start out and do my thing, maybe even become CEO, just like you have. As we do see software engineers being CEOs and it's always nice to get a little bit of window on what it actually looks like. Yeah, starting out, I closed the loop with the customer.

So I would build something with our other engineers and I would get it to the customer or user. I would be the one emailing with them to make sure it was actually useful. I would go visit them and, you know, I was involved in every part of the loop. And as we've grown, I've become less involved in some parts of the loop just because it I can't and I need to focus in some areas.

But you know, the thing that I think every software engineer should do is for the thing they're building, follow it all the way through to the customer actually using it. Stay like a dog like holding on to that and see and then iterate with that customer. Whatever feedback they have, turn around and fix really quickly. Even if that means saying, no, I can't take on more work in this sprint because my thing will be delivered to the customer.

By the way, any engineering manager or product manager who hears that from an engineer will be so happy. They'll be so happy to not give you more work. They love to have engineers follow through. And for me, I just got to pick what parts do I want to be focused on. And now it's much more kind of the other end, it's earlier on in the product. Like what is the future of the product and how can all the different things are doing slot in together?

Like how can us bringing in more context make it so that Cody today gets better and code search and the stuff we do with agents and automating software gets better. There's technical stuff there, but there's also strategy. And then also with customers, it's not the minutes after we deliver a new version to them, but it's after they've been using it for a few weeks, going and visiting them, sitting with their users.

And the thing that I love as much as Cody is getting in a room at a customer site with like 20 people who use source graph and just hearing their complaints, hearing their feedback. And I always, you know, I might show a couple slides, but then we just get our laptops, we sit next to each other and I show them how I use it. They show me how they use it, you know, kind of point out ideas. And I absolutely love that. So that's a day, that's a week in the life.

Well, and that's just what you did, right? That's why you're an Amsterdam. Yeah, that's why I'm an Amsterdam. I mean, this sounds very different to how I would have imagined a CEO like my imagination would have been like, oh, I have a lot of, you know, meetings. I said strategy. I meet with my exec team. I have one on one, but what you've described was, was very different.

And it sounds like you're doing, correct me if I'm wrong, but it sounds like you're prioritizing way more of like, all right, let me be out with either the customers and like see how they're doing it. Or in the product, see what's going on. Just kind of, I didn't like the things I didn't hear you say is meetings, alignment, strategy, OK, ours. I do that stuff too. Well, sure. It's a little more boring. And I now have the confidence to admit that's boring.

There's so much advice out there that says CEOs need to just be doing that stuff. But ultimately, if you're a product company, the product and the customer, those are so important. And if you get those right, other things are so much easier. If I am explaining or communicating or aligning some strategy and I bring back, hey, here's what the customer said to me yesterday when I was an Amsterdam.

That means that whatever I'm saying is probably going to be more right and other people are going to get aligned around it better. If instead I do a ton of work to make an awesome strategy doc and slides, but I don't bring in that visceral sense of the product and customer voice, one is probably going to be wrong and two, everyone's going to think that's a bunch of bullshit. So is it fair to say that you've kind of found what is important?

Because what I sense from your job, you have 180 people in the company, so many customers, you're going to get your email inbox probably is flooded with things I just too much to take on. As a person, but what I'm sensing is you actually figure it out what is important, the number one, and then you probably do a best effort everywhere else. But you make sure that these things, the customer is in a product, you do that and you clear that out. Yeah, that's right.

If I'm not able to focus on customers and product, then I figure out how I can get into a state where I can get back to that. And that means getting the right leaders, getting the right alignment, but I try to fix that as quickly as possible. This is awesome.

It's also encouraging to hear because I think like when I think of like as a software engineer, if me or if someone in my position will one day become in your position, which is a CEO of a pretty big company, I would have my initial fear would be it must be overwhelming and you're pulling all these directions. And you know, like if you're unless you've been an exec or someone else, you can't even do it, but you're the proof that you can do it.

And you can figure out how to actually sound like you're actually having fun with this. Oh, yeah. I have a ton of fun. And you know, I make a point to do things that I consider fun because I will do those things 100 times better than the things that I think are boring. And I believe that source graph is will be incredibly successful. Ultimately, that's going to be the test though. So come back and let's come back in 10 years and let's see how this goes. Let's go back.

Let's wrap up with some rapid questions if you're okay with that. So I'll just ask a question and just shoot like what comes to mind. And it doesn't need to be long as it's just like the kind of first instinct or like the first answer. So sound good. So what was your first programming language? Pearl. Pearl. Do you still use it? Love it, hate it. I've not used it. I understand that Pearl is quite big in Amsterdam. Dutch and Pearl are the two languages of Amsterdam.

And I love all programming languages, but have not used Pearl since 1999 or 2000. You're probably not alone with the booking.com folks will be using it. They have a few hundred thousand lines of code, but they're the biggest. Pearl. It's an amazing company. They've done amazing things with it. Yeah. What is the handy utility or app that you use that is not related to source graph through your day to day or anywhere else? Getting the right screenshot or screen recording tool is critical.

And then you'll use it like 10 times a day. So also loom is a really good one. Some clean shot and Kazam. What is Kazam? It's on Linux, but screen recording. Awesome. What is an exciting early say startup that you know of? I love Olamma, which lets you run AI models on your laptop, local inference. And when some new open source model drops, they have it available in like minutes, it seems. And it's amazing. And you also can build so many things on top of it. So Cody supports Olamas.

You can be in a fair day cage on an airplane over the Pacific and you can still get auto complete because it's Olamma running locally using you know, starcoater too or Olamma. Oh, not anything you would have done with you. What's your favorite book or a favorite book? I love the LBJ biographies that Lyndon Baines Johnson, a US president back in middle of the 20th century by Robert Carro. They are the most in-depth biographies ever and you really get to learn about someone.

It's about 4,000 pages, so it's quite an investment, but highly recommended. Any biographies that you've enjoyed recently? I'm reading one about Gandhi now and have read one about Admiral Nimitz from the World War II and the Pacific. I love biographies just for me, understanding how other people came to make these really hard decisions.

And one thing that always tricks me going back to this idea of finding the fun in your job is you read about like the Admiral that was leading the US war effort in World War II and he golfs and plays tennis all the time. And you know, when he goes back from the front back to Honolulu, it must take him weeks and we have this idea that like everyone must be on all the time and in many cases doing things that they don't like.

But I think so many great people in history realize that if you can make a few good decisions every single year, then that's what matters most in a leadership position. So that gives me a nice sense of like what are those few decisions that I need to make and it's not about being in every single little thing. How can listeners be helpful to you? Keep coding, keep writing a lot of code and when you try new AI tools when coding, hold a really high standard and bring that feedback back.

There's a lot of hype out there. I think though that where we are today is so early and we're only going to get there by software engineers seeing through the hype and actually making sure that these tools are incredibly useful for people doing all kinds of things. So feel comfortable saying that the emperor has no clothes and push all of these tools to get better and better. So I guess try this stuff like, but then validate and just keep it real. Yeah, that's right. Awesome.

It was great to have you here today. Thank you. It's great to be here. I'm a longtime reader, a longtime fan and it's awesome to be here. Thank you. Awesome to have you. Thanks a lot to Quinn for his conversation and for sharing more on how SourceGap operates within-side your details. Here are my three takeaways from this episode. Take away number one. As software engineers, it's increasingly important to understand what value you add to the business.

A big difference between 2021 and 2024 is how companies are much more focused on efficiency. This means they're hiring more conservatively and less likely to fund teams with headcount that doesn't contribute to the focus of the company. As a developer or manager, try to figure out how much your team contributes to revenue or savings or other key goals of the company. Are you working in what the company would consider a profit center or what is more of a cost center?

We did a deep dive on this topic in the Primatic Engineer. Check out the article linked in the show notes below. Take away number two. AI tools are great to eliminate the toil that we developers face day to day. Their AI tools that position themselves as their goal being to replace developers or replace whatever job they're trying to do. I found a sympathetic that Quinn did not think this is a sensible path.

His approach is to start by using AI tools with some of the dumbest things like generating the change lock for a software release, assuming you generate a change lock. And then you can take tedious tasks where these tools could help and see if you can automate some more. Do this one step at a time and it will actually help devs and teams and it's a lot more achievable than saying, let's replace this whole complicated workflow with AI. Take away number three.

The reality of location and independent pay is that it solves being sensible above a certain company size. Source Graph was one of the few companies that offers the same base salary regardless of where people worked at. They did this until they grew to about 200 people and then switched this model to a location indexed model. Quinn was honest about why they did it. It was because keeping this location independent pay would have not made sense for the company from a business point of view.

Basically location independent pay means that the company can hire very easily low cost regions, but it can be hard or even impossible to do is in high cost regions. It also creates this weird incentive where employees are incentivized to move to a low cost region where they can save more.

In the end, I don't know of any company that with more than 200 people that pays location independent, all large companies have some kind of indexing it on location and the best companies just pay the top of the local market. We cover more about compensation in the article that trimotal nature of software engineering salaries in the private engineer, which you can check out in the show notes below.

Finally, if you'd like to find Quinn online, you can do so on his blog slack.org and on Twitter, slash X and LinkedIn as linked in the show notes below. If you'd like to learn more about Source Graphs, Engineering, Culture, check out the two part deep by published in their private engineer called Insized Source Graph Engineering Culture also linked in the show notes. This was the second episode of the private engineer podcast. Thanks a lot for listening and watching.

If you enjoyed this episode, I very much appreciate if you subscribe and leave a review. Thanks and see you in the next one.