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

Episode Date: October 9, 2024

Brought to you by:• Paragon: ​​Build native, customer-facing SaaS integrations 7x faster.• WorkOS: For B2B leaders building enterprise SaaS—On today’s episode of The Pragmatic Engineer, I���m joined by Quinn Slack, CEO and co-founder of Sourcegraph, a leading code search and intelligence platform. Quinn holds a degree in Computer Science from Stanford and is deeply passionate about coding: to the point that he still codes every day! He also serves on the board of Hack Club, a national nonprofit dedicated to bringing coding clubs to high schools nationwide. In this insightful conversation, we discuss:            • How Sourcegraph's operations have evolved since 2021• Why more software engineers should focus on delivering business value• Why Quinn continues to code every day, even as a CEO• Practical AI and LLM use cases and a phased approach to their adoption• The story behind Job Fairs at Sourcegraph and why it’s no longer in use• Quinn’s leadership style and his focus on customers and product excellence• The shift from location-independent pay to zone-based pay at Sourcegraph• And much more!—Where to find Quinn Slack:• X: https://x.com/sqs• LinkedIn: https://www.linkedin.com/in/quinnslack/• Website: https://slack.org/Where to find Gergely:• Newsletter: https://www.pragmaticengineer.com/• YouTube: https://www.youtube.com/c/mrgergelyorosz• LinkedIn: https://www.linkedin.com/in/gergelyorosz/• X: https://x.com/GergelyOrosz—In this episode, we cover:(01:35) How Sourcegraph started and how it has evolved over the past 11 years(04:14) How scale-ups have changed (08:27) Learnings from 2021 and how Sourcegraph’s operations have streamlined(15:22) Why Quinn is for gradual increases in automation and other thoughts on AI(18:10) The importance of changelogs(19:14) Keeping AI accountable and possible future use cases (22:29) Current limitations of AI(25:08) Why early adopters of AI coding tools have an advantage (27:38) Why AI is not yet capable of understanding existing codebases (31:53) Changes at Sourcegraph since the deep dive on The Pragmatic Engineer blog(40:14) The importance of transparency and understanding the different forms of compensation(40:22) Why Sourcegraph shifted to zone-based pay(47:15) The journey from engineer to CEO(53:28) A comparison of a typical week 11 years ago vs. now(59:20) Rapid fire roundThe Pragmatic Engineer deepdives relevant for this episode:• Inside Sourcegraph’s engineering culture: Part 1 https://newsletter.pragmaticengineer.com/p/inside-sourcegraphs-engineering-culture• Inside Sourcegraph’s engineering culture: Part 2 https://newsletter.pragmaticengineer.com/p/inside-sourcegraphs-engineering-culture-part-2—References and Transcript:See the transcript and other references from the episode at https://newsletter.pragmaticengineer.com/podcast—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

that 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, us included, I really wish that we'd 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 Engineer Turner's 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 code search tool and code 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 2004 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 source graph 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. You can't prime me away from it. And I love that you get to build something and then just get it out there to millions of people. And nobody knows where you're from or what age you are. It's this incredible equalizer and this incredible sense of creation. but I found that that spark of creation, you don't really get that when you're working in these massive code bases.

So I was working on some patches to Chrome and OpenSSL and Firefox. And to even understand those codebases, I would set up a code search tool. And at the time, this was back in 2009 or so the code search tools are very primitive. It felt like you were on old MS-DOS 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 own this code or why is it broken. So we just said there's got to be a better way. And my co-founder, Beong, he had been at Google, where they famously have this amazing code search 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, you know, different CI systems. Tons of repos everywhere. 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'd 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 were one of our very first. And now we got a ton more and loving every single day of it. Awesome. But speaking of changes, so one change that has been a huge one is how scale-ups, so you're a scale-up. How largest source graph roughly in terms of like people funding? We have about 180 people on the team.

And that's globally distributed. as far as funding, I believe we've raised a little over 200 million. And speaking away, so you're considered what a scale-up is. You know, you pass the early-stage startup. You're actually like a mid-stage, late-stage startup, a scale-up, depending on how people put it. I mean, I don't want to put labels on it. The point is, like, you've 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 yours than it is today. And 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 founders? How do you see, you know, this 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. Wow. So it was like five years to close your first or one of your first big 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, 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 sinks with your customer CRMs, ingest their Google drive files or Slack messages as context for

a RAG AI app, or provide them cross-up automation and agendic 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 other plumbing, including authentication, eventless for external webhooks, rate limit circumvention, and comprehensive monitoring. This is why engineering teams

at AI21, copy.a.i, 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 usparagon.com slash pragmatic dash engineer to see how Paragon can help you accelerate your product's integration roadmap today and get a $1,000 credit on their pro and enterprise plans. Start your free trial today. That is, usparagon.com slash pragmatic dash engineer. It's kind of sounded like you also saw. So you saw this really big increase in 2021 or 2020 and customers and interests and I guess companies opening their wallace to become paying customers. But I'm interested in how. What were things that you changed 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 see like different issues with retention, 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, as CEO, ultimately, 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 at a lot of companies, Sourcegraph 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 Sourcegraph 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?

I think a lot more companies have adopted that now. And I think a lot of companies, us included, I really wish that we had done a lot more of that back in 2021. There was 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 things we did was bring on Steve Yeggie as our head of engineering. You got him out of retirement, right? Yeah, that's right. I think that he was looking for this kind of opportunity because he built a lot 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 Emacs 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 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 just 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 and every company probably needed a lot more of. Him coming on was an awesome just infusion 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. Well, we now have it so we can ship many times a day, and we ship new versions of Cody and code search many times a day. We've 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, this is really big.

boom in 2021. What is the biggest learning that you're taking away from yourself or that you would, you know, advise your former self, like something that's sticking 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 as fluent with all the new stuff that's happening. I'm not going to know every single corner 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 at this company codes, they might think, oh, 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 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 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 dip their toes in coding.

It is interesting because I don't hear many or even any CEOs say that they do code. daily CTOs, I do here. But I guess if anywhere, it would make sense when your product is a tool that developer use day and day out. Yeah. The Shopify CEO codes. And I love to see that. I bet there's others.

So are you conscious doing it? Are you doing it because you love doing it? Or is it both? Both. You couldn't pry me away from it. You can go check my commit logs in the Cody and Sourcegraph repos. It's all public as well, right? Yeah.

That's right. Love it. What is your kind of approach and things? thinking of how you approach the space. You know, like we've seen approaches for what GitHub co-pilot is doing. There's other like more bold approaches like Devin 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 two 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 looking 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 day. data along the way. And having the AI bite off the easy parts first, the things that are wrote that are part of every task, like updating a bullet in a change log. That's the dumbest thing, but I think we all can understand intuitively that an AI can do a pretty good job of taking your diff and updating your change log. And 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've got to switch to your

editor and it's painful. I think the way we get toward 100% automation is by starting at zero. And that change log thing might represent 0.1% of dev work. And we just keep on piling up those 0.1 percent 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 up. out a one-shot thing or something where it iterates with itself. Because AI checking its own work, it's like piling shit upon shit. It does not end up good. You got to bring ground truth in.

And when you say change log, just to setting straight, because 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, right? That's right. Well, I see, I actually, that's an interesting concept where you're doing it, linear is doing it. 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 Sourcegraph, 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 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 one, like you're achieving multiple goals with just one thing, killing two birds with one stone pretty much. 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 can help if you're a junior engineer you want a 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 deploys, is there a large number of errors? I 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 insuring team at a company that is building amazing products and generating 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 companies, the teams that I'm not? 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 deployment, the security scanner, all these things.

They were made for nice UIs and enterprise features for humans to consume. but what's the AI version of data dog when you don't need all those bells 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. I think you're going to see a lot of stuff turn over. You're going to see also there's now increasing ROI from really fast builds. It was always the case for humans, but really fast build is something on 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 Git 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 of that change. And if that could run in 100 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. I mean, 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 I think we've seen AI is really good 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 that good to use in terms of, I'm not just talking about coding, but in terms of 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 as 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, free form 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, bring in that right data. But we haven't necessarily thought of every kind of data that's been brought in. 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 GPT the question, but you paste it in a bunch of files that you think are relevant above your question. And 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 debuggers 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. 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 printf debugging and don't actually use these tools. And going back to what we were 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 say, sign in again or remember which tab to go to, 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 industry market. They're seeing all these powerful LMs, Cody, co-pilot, 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. Are our jobs going to be in demand, especially as a new grad, will I have a future in the industry? 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 the people that are interviewing them 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 that 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 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, a salesperson and all of 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 produced 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 we were always

talking about humans. You need to hire more people to maintain it or bugs are harder to spot, etc. How will 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 biggest criticism that a lot of people have about these completely agent-first approaches, just like, let's automate 100%. They might work in some

cases on very simple toy brand-new projects, but in existing codebases, 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 and a really complex existing code base, you got to be really careful. I mean, I'm sure you felt at Uber, if you're going to make a change of 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 rollout, a really careful stage rollout. You message, if it's a really big change, you 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's how you kind of do it because you don't know, like, if you're going to break. And in the end, what you care about is, like, will it have an impact for the business specifically? Will users or paying customers get stuck or complain, et cetera? Yeah. And that's probably not going to change in the end, you know, like we just have new ways

of doing it. And actually feature flags are relatively new way, you know, they came in like 10 or 15 years ago, mainstream that is. Yeah. And until Code Ait tool is, no. know how to do a staged rollout, 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 that we're 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 incurred. a lot more tech debt, incurring a lot more messy code to move fast because their asses probably will be saved in a few years by AI, but it's a bet you got to make cautiously.

Yeah, and I think it is good to remember that there's always tradeoffs, right? So, like, assuming you move faster, you might be accumulating tech death, which is fine, again, just be aware of it. Yeah. Talking of the source graph engineering culture, last year, I did a deep dive, or we did a deep dive in the pragmatic engineer on how the company worked. And some of the things that just stood out as a short recap, we'll 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 had job fairs back then. I think I'm not sure if Stiegger brought that in or that was there before. and you had RFCs, requests for comments, and a lot of them 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 back then this was up to date.

I'm interested in the last year or a year and a half. What are things that have changed in terms of the engineering culture or the company culture at 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 fare. 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 tap AI. There are 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 Jobfare 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 rearrange 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 appreciated as much. I think other people did on the team. But for me, as CEO, 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 get 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, 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, so you stack ranked of like, all right, here's number one project, number two project, like discussing with what you or the people who decided. And then people, people saw that that was a clear priority. Did you also like say, like, here's how many people were kind of expecting? And then I guess people just kind of like worked out. I guess the top project probably got like more applications, if you will, then you're expecting and you kind of channel it down. That's right.

What was the motivation? Like you said it was good to have this shock to the system, which I agree. It sounds like a pretty disruptive, but I mean, in a fun way. Mostly fun. Yeah, mostly fun. But what was the thing that made you realize like we should just do something where we kind of like, you know, like half 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 or regret allowing us to get started with and that 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 as 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 se, 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 headcount, where you could always do more by adding more headcount,

I think a lot of people had gotten used to the idea that if they were working 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'd be a lot of things that we could do to communicate it better, just be more up front with this as 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 was and how, how difficult it was and how much. many things we could have done 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 are having me talk to other portfolio companies. So I think the grass is always greener. I do sense that a lot of things that you're saying, we're kind of getting a little bit back to basics. In the sense that, like, my view is that, you know, there's like, it's a great company if everyone works 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, and the company communicates whatever that is. And by the way, this business changes. So in your case, like this was clearly you've, you've seen the future coming, which has now arrived. And

you sounds like you kind of just communicated this way. Yeah. And again, wish we had done it sooner, which we'd done it more clearly, but 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, I really believe that in 2021, there were 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 that has a clear tie to the business, they should feel a lot more

secure. They don't because the world has changed 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 agree. And I think it's unfortunate that we're seeing big tech, you know, let go people even from profit centers or the cash cow businesses.

But the realities, the closer I look to 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 a 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 talked to. Would it not be nice to, you know, connect your code changes to revenue?

I mean, there will be some downsides. But overall, I think that will be like if we even attempted to do that. And eventually we're going to get there for sure. Like, we will have attempts and failures. But that's the history of software engineering, isn't it? Yeah. Attempts of failures. Yeah.

And AI can make it so software engineers are much closer to the customer, and much closer to the value and don't need as many other kinds of people at the company. This episode is brought to by the Enterprise Ready Conference, a one-day event in SF, bringing together product and injuring leaders shaping the future of enterprise SaaS. The event features a curated list of speakers with direct experience building for the enterprise. Speakers include people from OpenAI, Vanta, Checker, Dropbox, and Canva. Topics include advanced identity management, compliance, encryption, and logging, essentially a complex features that most enterprise customers require.

If you're a founder, exec, PM or engineer in 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 WorkOS. Spots are filling up quickly. Make sure to request an invite at enterprise ready.com. That is enterpriceready.com. When it comes to compensation, as a source graph, you are very early to be transparent on the compensation that you offer. And now we've actually seen in the U.S., 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 U.S. are now actually disclosing how much they're offering for the positions across the U.S., especially when they're hiring in California. Now, what is your take on on this change where we're seeing, like, from a job seeker's 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 a pretty kind of sophisticated and 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, dev tools were 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 to 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 software 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's true. Well, I think it is a step forward that we're actually seeing the cash part at least. And 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 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 role. Location independent pay. A couple months ago, we moved to zone-based pay. and thoughtful transition period. This is a big change in many ways.

And 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 and 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 a company that cannot you know higher efficiently is at a real

disadvantage. So we still pay well above median salary. We still are very competitive in 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 was 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 you shared how your thinking has changed. Because again, I feel that the companies evolve. The world also

changes. And you just want to make sure that, you know, you're doing whatever makes the most sense based on where you are. Yeah. 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 or buy a house on the equity. And that shareholder hat, another way to think of it is, 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. I'm not saying, you know, always think that, but 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. I think that'll give you a lot of calm. Yeah. And I guess one thing that I definitely saw when I kind of looked into why companies are stopped doing the same conversation globally is one thing. that handcuffs you is you cannot hire from places where the median compensation is a lot higher typically in some of the biggest tech hubs like New York, San Francisco, London. And that can be a choice and especially early on that that can make sense. But that's a definite downside.

Any company that does it either has to do weird workarounds of doing so or doing that. And you know, you can already see that there's just no like everything, everything is a tradeoff, right? Yeah. And as you say, I think you're right on, like, it is worth thinking about the business side of things. Because 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 it?

Yeah. Yeah. I think that any company that still maintains location independent 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 companies that are thinking long-term, thinking shareholders, thinking 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 than one that's not going to be around in two years. Exactly. Absolutely agree. So you've now been a CEO at Sourcegraph more than 10 years. It's 11 years, isn't it? Yeah, that's right. Coming up. So I was interested in a few things.

I don't think I know many software engineers who have been CEOs 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 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. That's what you did?

That's what I was doing. I remember that moment when Beyond and I were coding up the first version of Sourcegraph 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 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.

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're coding, 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 overrepresented, relative to most other majors. Like the CEO of United Airlines is a computer science major, and you can find so many examples like that. So 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 CEO 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, you know, it's not about trust. It's 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 years as we've grown. I see that in a lot of other software engineers, too, when they hire this expert salesperson or expert marketer, they can't fully just outsource that whole function.

And when you say you see a lot of other sufferangers, you mean other subverengers 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 set 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 enforcing that as well. Do you think you have to go through this learning? I mean,

clearly it's very efficient when you do. Or is how much of the things that you, 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 this just part of the job of, you know, building something new? I wish I'd listen 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 weak or I'm 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, you know, 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 exec meetings, I think it's probably going to just be platitudes. And 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. And that can create this mentality as a CEO.

You know, 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, you know, make you lose confidence. And when I say you, I mean, that's how I felt. So just seeing enough times of that failing and then really great co-founder, really great board and, you know, 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, there's probably overconfidence because you do need to take some feedback. Finding that the right amount of feedback to take is really hard. Can you summarize how one, 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 Storescraft 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. I'd one day like to start out and do my thing,

maybe even become CEO just like you have, because 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 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 I can't and I need to focus in some areas.

But 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 to 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, you know, pick what parts do I want to be focused on? And now it's much more kind of at, you know, 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 we're doing slot in together? Like how can us bring 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, you know, strategy. And then also with customers, it's not, you know, 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 coding 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 of slides, but then we just get our laptops. We sit next to each other and I

show them, you know, 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 in Amsterdam. Yeah, that's why I'm in Amsterdam. I mean, this sounds very different to how I would have imagined the 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-ones.

But what you've described was very different. It sounds like you're doing, and 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, OKRs. 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 in 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 dock and slides, but I don't bring in that

visceral sense of the product and customer voice. One, it's 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, like, your email inbox probably is flooded with things. There's 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 know, you probably do a best effort everywhere else. but you make sure that these things, the customers in a product, you do that and clear that out. Yeah, that's right. And 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 when I think of like, you know, as a software engineer, if me or if someone in my position will,

one day become in your position, which is the CEO of a pretty big company, I would have the, my initial fear will 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, you're the proof that you can do it. And you can figure out how to actually, sounds 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 a hundred times better than the things that I think are boring. And I believe that Sourcegraph 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. Yeah. So I'll just ask a question and just shoot like what comes to mind. and it doesn't need to be long. It's just like the kind of first instinct

or like the first answer. So, sound good? Yeah. 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 it. The booking.com folks will be using it. They have a few hundred thousand lines of cool, but they're the biggest.

Yeah. It's an amazing company. They've done amazing things with it. Yeah. What is a handy utilior app that you use that is not related to source graph to 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.

Gloom, Clean Shot, and Kazam. What is Kazam? It's on Linux, but screen recording. Awesome. What is an exciting early-safe startup that you know of? I love Olama, 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 Faraday cage on an airplane over the Pacific, and you can still get auto-complete because it's O'Lama running locally using, you know, StarCode or two or Lama. Oh, not anything you would have done, would you? What's your favorite book or a favorite book? I love the LBJ biographies that Lyndon Baines Johnson, a U.S. president back in middle of the 20th century by Robert Caro. 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 in the Pacific. I love biographies just for me feeling, understanding how other people came to, to make these really hard decisions. And one thing that always strikes me, going back to this idea of finding the fun in your job, is you read about the Admiral that was leading the U.S. 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, but then validate and just keep it real, right? Yeah, that's right. Awesome.

It was great to have you here today. Thank you. It's great to be here. I'm a long-time reader, a long-time fan, and it's awesome to be here. Thank you. Awesome to have you. Thanks a lot to Quinn for this conversation and for sharing more on how SourceGrap operates with insider details. Here are my three takeaways from this episode. Takeaway 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 like it to fund teams with headcounts, 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 pragmatic engineer. Check out the article linked in the show notes below. Takeaway number two, AI tools are great to eliminate the toil that we developers face day to day. There are 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 log for a software release. I mean, assuming you generate a change log. 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,

the Lesterplates this whole complicated workflow with AI. Takeaway number three. The reality of location independent pay is that it solves being sensible above a certain company size. Sourcecraft was one of the few companies that offered 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 in low-cost regions, but it can be hard or even impossible to do this 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 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 the primodal nature of software-engine salaries, in the Pragmatic 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 Sourcegraph's engineering culture, check out the two part deep by published in the Pragmatic Engineer called Inside Source Graph Engineering Culture, also linked in the show notes.

This was the second episode of the Pragmatic Engineering podcast. Thanks a lot for listening and watching. If you enjoy this episode, I very much appreciate you to subscribe and leave your review. Thanks and see you in the next one.