Inside Sourcegraph’s Engineering Culture: Part 1
Inside Sourcegraph’s Engineering Culture: Part 1
A deep dive into how Sourcegraph works from the perspective of software engineers and engineering managers.
Sourcegraph is a code search scaleup, cofounded in 2013 by Quinn Slack (CEO) and Beyang Liu (CTO.) The company first raised major venture capital funding in 2017 with a $20M Series A round. It has since raised a further $223M across 4 rounds, according to Dealroom, the latest being a $125M Series D in 2021.
I first came across Sourcegraph while at Uber in 2018. The tool was introduced internally and rapidly made it much easier to explore codebases and returned search results surprisingly fast. I’ve followed the company’s journey since. We’ve previously covered in-depth how Sourcegraph does RFCs (Requests For Comments,) as part of an examination of Design docs, RFCs and ADRs.
Sourcegraph stands out from many tech companies by applying high transparency to everything it does. This made me keen to discover any learnings that this approach may offer by going through everything shared publicly – and also a few things not in the open.
To do this, I’ve spent weeks in contact with current and former Sourcegraph engineers and on examining publicly available sources. I also talked with Quinn for some CEO insights.
As with other deep dives on Facebook/Meta and Amazon, this issue is longer than usual. You might consider treating it as an educational resource for future reference.
In this article, we cover:
1. Introduction
3. Hiring
Part 2 of the series additionally covers:
4. Compensation
Base salary
Equity
Benefits and perks
External salary transparency
5. Career
Levels and competencies
Engineering job levels
Engineering management
Product management
Design
Performance reviews and promotions
The tech stack
Architecture overview
Testing
Developer experience
Advice for software engineers to succeed at Sourcegraph
Advice for engineering managers to thrive at the company
Inspiration for founders and engineering leaders to take from Sourcegraph
8. Resources
Interview loops at Sourcegraph
Performance review templates at Sourcegraph
1. Introduction
Overview
Sourcegraph is a full-remote company and one of few employers to pay globally equal salaries. At time of publication it employs 200 people of whom 76 are software engineers, engineering managers, product managers or designers.
Transparent by default. One of the most eye-catching things about Sourcegraph – and what’s motivated me to cover its culture – is a default commitment to transparency in almost everything. All code is in the open, as are issues tracked. It publishes its employee handbook and also designs in the open. Many of its RFCs are in the open, too.
In the same spirit, Sourcegraph may be used without signup via the website. A fun use case is searching Sourcegraph’s own codebase with it:
The “transparent by default” principle applies internally, with information far more accessible to employees than normal. Of course, some things remain confidential from non-employees, like discussions, documents, business metrics, customer information, etc.
The history of Sourcegraph
Before starting the business, the cofounders studied at Stanford University and after graduating, Beyang worked at Google before joining Palantir in 2011, where he met Quinn, who already worked at the big data analytics company. As Beyang recounted on a podcast:
“It was [at Palantir] that I got to work closely with my future cofounder, Quinn Slack. We’d gone to school together and kind of knew each other from there, but it was at Palantir where we really got to spend some quality time together. That was also kind of a tipping point for me because I think a lot of Sourcegraph’s roots were planted in that experience.”
The idea for code search came early while they were at Palantir, from working with large companies and seeing the scale of the problem:
“Quinn and I are both CS majors by background, so we both kind of had this pain that I think every programmer feels, which is like, ‘Man, it seems like it’s harder than it should be to find existing code and reuse it.’ It just seems like I’m spending too much time searching the Internet, crawling through random forums, trying to find the answer to how to do this pretty straightforward thing in code.
We felt that kind of day-to-day pain as programmers. But the experience at Palantir showed us this is a problem that’s not just relevant to programmers now: it’s actually relevant to the top leadership at one of the big five banks in the US.”
Extra inspiration came from Beyang’s experience at Google and seeing how well Google Code Search worked:
“I had previously done an internship at Google, which internally has this great utility. If you ever meet a software engineer who works in the main Google codebase and you ask what they think about Google Code Search, I guarantee you they will say it’s the best thing since sliced bread. Just ask him how many times they use it every day, how often they have it open in a browser tab, and they’ll tell you, “60, 70, even 80% of time I just have it open as a reference.
Seeing the value that it provided inside Google and also just missing that tool and not seeing it anywhere else, made us want to build something like it; [a tool] which could handle the entire universe of code and kind of empower every individual developer out there.”
During the first two years of Sourcegraph’s existence (2013-2015,) the cofounders spent most time prototyping a viable technical solution for large-scale code search. After that, the business took off, initially growing slowly and then expanding in size quickly after Series A investment in 2017.
I mention above that I started using Sourcegraph at Uber. Quinn informed me Uber was actually their first major customer, whom they landed due to having a Chrome extension. Quinn said:
“A bunch of devs at Uber had been using our browser extension to search and browse code on GitHub. Uber ran some internal survey and asked engineers: ‘Hey, what would make life as an Uber dev better?’ Outside of checkboxes, they had a free text option. Out of about 1,000 responses, about 75 people wrote ‘Sourcegraph’ in that freeform text box.
Uber then gave us a phone call; I don't know how they found our number. They said: ‘Hey, we want to get Sourcegraph.’ At the time, we were not ready to serve the enterprise, but we had already done a lot of scalability work. Given we had some amazing additional champions at the company, we got it rolled out. And I am forever grateful to Uber for this.”
Company values
Sourcegraph defines 7 company values. Each is stated below and I’ve added current software engineers’ opinions of them.
1. Customer-first: You earn and keep the trust of our customers by putting their interests first.
Engineers I talked to all feel close to customers and are encouraged to get close up to problems and solve them. As one put it:
“Everything I’ve worked on in the past year was either for customers, or serving an internal need, like solving our own pains to let ourselves serve our customers better.”
2. Work as a team: You work collaboratively with your peers, cross-functional teammates, and leadership to create shared success, trust, and belonging.
Pairing sessions are encouraged in most teams. Managers help with work across functions, and people tend to grab coffee with colleagues they don’t know.
3. High agency: You have the power and the responsibility to improve Sourcegraph as a company and a product. You deliver regardless of the circumstances.
All engineers I consulted said they feel the company lives this value and several noted that high agency is a differentiator from other companies. An engineer said:
“High agency is really practiced at Sourcegraph, and there's no ‘glass ceiling’ or ‘red tape.’ You can go to whoever you want and make a proposal, or point out things that need to be changed. While your proposal may not be accepted, you'll never hear ‘it's out of line for you to do this.’”
In practice, high agency means engineers and teams are autonomous, and are expected to find the solutions and compromises, when needed, which work best for the group and the business. From the company handbook:
“If you feel something is important, then advocate for it! If you feel like you’re using the wrong tools for the job or doing the wrong thing, then you’re responsible for quickly voicing that concern, and engaging with your teammates to find the solution that is the best for the team. Do not ever assume or wait for top-down change. If something is broken for you or your team, then fix it for you or your team, and then share that fix in case other individuals or teams have the same problem.”
4. High quality through iteration: You are responsible for defining and building high quality work iteratively.
Thinking about the smallest-possible increment is how most engineering teams work, and there is even more focus on speeding up delivery time. Engineering teams are encouraged to cut scope to progress faster, to not wait to start work, and to try and make reversible decisions as they do.
Interestingly, Sourcegraph releases are not that frequent, which is normal for a company with many enterprise and on-prem customers. Still, the push on iteration means teams focus on the smallest-possible increment to demonstrate an idea is good, or a problem valid. This is in contrast to the attitude, "we'll build a high quality product by spending 12 months in isolation."
5. Be welcoming and inclusive: You make people from all groups and backgrounds feel comfortable belonging to our team and community.
Engineers I talked with said they feel that globally equal compensation embodies this value. Remote-first and transparency also contribute to this value.
6. Open and transparent: You proactively communicate in an open and transparent way.
Sourcegraph is an open company and more transparent than many tech businesses. Internally, engineers shared that leadership regularly shares strategy documents, salary ranges, and basic financial details like “cash in the bank.”
Of course, a good test of transparency is what happens when things go bad. I’m told that during the difficult summer of 2022, when the company let people go, Quinn the CEO owned it. Also, the company has Slack channels for less-than-positive news, like departures of colleagues and announcements of lost and downgraded customers. Both are approaches you don’t see at many other companies.
7. Continuously grow: You strive to continuously grow and learn by genuinely soliciting feedback early and often, and humbly reflecting on past mistakes.
Talking with engineers, this value felt like the most vague. Outside of the general principle of seeking feedback earlier rather than later, I didn’t hear much reflection on this value.
Regions
The company is all-remote and hires globally, save for a few countries which are off-limits due to US government policy. Sourcegraph employs staff from more than 30 countries.
As of 2022, the split of the company by timezone is roughly:
Engineering: ~45% in US timezones, ~45% in EU timezones (UTC) and ~10% in other timezones
Rest of the company: 66% in US timezones
Organizational structure
Thanks to the transparency, it’s relatively easy to get an overview of Sourcegraph by department and also a sense of the teams software engineers work in. Here’s my visualization of the structure, based on the handbook and conversations with Quinn Slack:
Quinn noted a few things during our conversation:
For larger engineering teams, there may be two engineering managers, in order to split workload.
Reporting lines are perhaps less important, thanks to internal transparency. Lots of functions reporting to the CEO could easily create silos, where people don’t know what other organizations do. At Sourcegraph, this is less the case: colleagues talk across organization boundaries and know what others are working on, as almost all work is done in the open.
The handbook
In its handbook, Sourcegraph sets out how team members collaborate. As a note, among engineers, the consensus is that the handbook is somewhat dated and behind on actual practices. For this article, I draw from the up-to-date parts of the handbook and highlight practices that have changed over time, or aren’t covered. Of course, it’s little surprise this is the case: a company handbook is a model example of documentation and all documentation tends to lag behind the facts on the ground, or doesn’t cover everything, or has details which may not be fully correct.