Sourcegraph values

Customer-first

You earn and keep the trust of our customers by putting their interests first, ahead of Sourcegraph’s interests and your team’s interests. Over the long term, we need to be a customer-funded business, and you’ll help us get there by being customer-first.

• We are not engineering-first. We are not sales-first. Being customer-first unites us all (engineering, sales, and every other team).
• When you’re building the product, being customer-first means you solve real problems for customers who use, love, and appreciate what you build. You aren’t working on abstract tech that will never be used.
• When you’re marketing, selling, and supporting the product, you know the entire team values you and affirmatively decided to join a customer-first company. We are not one of those developer-facing companies where “how to make money and serve customers” is an unpleasant afterthought.
• Avoid being prospect-first when possible. Solve a problem for existing customers (not prospects) first. You can be much more iterative and get much better feedback from existing customers, which means you’ll build a better solution and will have happy customer references. This wins prospects better than if you were narrowly prospect-first.
• For more, see ”Being a customer-first company“.

Work as a team

We prefer to build teams, not workgroups. A team has a small number of shared goals that team members work on together. This yields collaboration and focus, which helps us do higher-quality things faster. In contrast, a workgroup is a group of people who are each working on their own things.

• If it is not clear to you what your team’s goals are, it’s your responsibility to get clarity.
• If you feel like you or your team have too many goals, it’s your responsibility to reduce the number of goals so that you have focus.
• If you feel like you are working alone, or your team doesn’t feel like a team, it’s your responsibility to take action to fix that.

As a team’s size and scope grows, it (unintentionally) tends to become a workgroup. Resist this by aggressively focusing, or by splitting it into smaller teams.

High agency

Everyone at Sourcegraph has the power and the responsibility to improve Sourcegraph as a company and as a product.

“Life can be much broader once you discover one simple fact: Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you’ll never be the same again.” - Steve Jobs

A few examples of how we encourage high agency are by being a handbook-first company, which allows anyone to change how the business operates, and by empowering engineers to spend time on projects they believe in through our policy of innovation time.

With agency comes responsibility; teammates are expected to take initiative and engage in collaboration when exercising their agency. If you feel that something is important, then advocate for it or make a decision! 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.

While decisions should be made eagerly, this doesn’t mean that you should make unilateral decisions when others should be involved. As an open company, we value open discussion on important topics, and think that collaboration should be a large part of making things better. It is not a bad outcome if your proposal is not accepted or replaced with a better solution, because you took the initiative, started the conversation, and either reaffirmed that our current solution is good, or implemented an even better one! We’re a startup, and if we take the safe path, we will most likely fail.

High quality

You are responsible for finding out what high-quality work looks like and delivering that high-quality work iteratively.

• If you don’t know what high quality looks like, it’s your responsibility to find out (for example, by asking teammates and stakeholders).
• If you don’t have the time to produce high-quality work, then it’s your responsibility to take more time or cut scope (and communicate this), so that you can produce high-quality work.
• If you don’t have the skills to produce high-quality work, then it’s your responsibility to acquire those skills (for example: learn them yourself, make use of Sourcegraph’s education budget, delegate to an existing teammate with the necessary skills, or hire a new teammate with those skills).
• If you need help producing high-quality work, it is your responsibility to get that help.

If we discover that we’ve produced something that does not meet our quality bar, we’ll roll it back (for example, revert a commit, roll back a deployment, or unpublish content) until we can make it high quality. If that’s not possible, we’ll prioritize improving it.

High-quality isn’t the opposite of iterative. You can keep quality high while still being iterative by narrowing the scope (for example, by solving a smaller problem at first, or by solving it only for certain customers initially).

Be welcoming and inclusive

You make people from all groups and backgrounds feel comfortable belonging to our team and community. You understand that diversity is having a seat at the table, inclusion is having a voice, and belonging is having that voice be heard. You are acting against racism and bias.

• In order for us to realize our purpose, our team must have diverse perspectives that are truly heard.
• In order for everyone to feel safe sharing their perspective, truly having a voice, and being heard, we must all continuously confront our unconscious biases by identifying them ourselves, graciously accepting when they are identified for us, and doing the work to ensure our biases do not inform our conduct and decision-making.

We view equity and inclusion as foundational elements to our culture, our success, and our ability to realize our purpose. We understand that:

• We all have unconscious biases we need to confront.
• Good people can say and do biased or racist things (and this doesn’t automatically make them bad people).
• Diversity supports our moral values and practical goals and we cannot truly have diversity without also having equity and inclusion.
• We consider a focus on diversity, equity, and inclusion a critical job function of all leaders at Sourcegraph.

For more information, see our ”Diversity, equity, and inclusion“.

Open and transparent

We are an open company.

Being open and transparent builds trust with our customers and within our team. It makes it easy for us to partner and collaborate with our customers so we make Sourcegraph the best that it can be. It enables our teammates to work autonomously to solve tough problems while maintaining alignment.

We favor transparency by default. There are multiple levels of transparency, and we always strive to be the most transparent that we can be for a given piece of information.

Being transparent by default is hard.

The level of transparency we are comfortable with as an organization can be initially uncomfortable to new teammates who are not used to being transparent by default.

We are eagerly transparent (not eventually transparent). This means it is possible to observe things that are inconsistent or incomplete (e.g., work-in-progress code, docs, goals, plans), which can be confusing to someone who is used to only seeing things that are “done”. We think being eagerly transparent by default is worth the challenges because it gives everyone visibility into the process, not just the outcome, and an opportunity to contribute to that process at any point in time.

Examples:

I want to keep my document private and share it with a limited set of people until I am ready to get feedback from a broader audience.

It is totally legitimate to want to create “breathing room” for a new thought or idea to develop before exposing it to wider critique. We want to create a culture where it is possible to do this while still being transparent.

1. Make your document accessible to everyone at Sourcegraph.
2. At the top, write down the state of the document and the kind of feedback you are (or are not) looking for (e.g. “I am not finished drafting this so please hold off on any feedback. Just sharing for transparency so others know what I am working on.”, or “This is a first draft that is ready for feedback”).
3. Share your document in an appropriate channel with the same context that you added at the top of the document.

My team has goals and plans for the future, but I am hesitant to put this in the handbook because I don’t want to promise anything to our customers and I don’t want competitors copying us.

We document our goals and plans publicly so we can engage with customers to build the best product possible. Documenting a goal is not the same thing as committing to a customer. If our competitors are closely following what we are doing, then we are clearly doing a good job and we should keep doing what we are doing!

I am working on improving the security of our product, but I feel uncomfortable clearly documenting what I am doing (e.g., in public status updates, issues, PR descriptions, the changelog) because I am worried that it will make Sourcegraph look bad.

Our code and PRs are public, so lack of transparency is only obfuscation, not security. Unless something is immediately exploitable and would put customer data at risk, you should be completely transparent about it, just like any other non-security improvement.

Continuously grow

You strive to continuously grow and learn.

• You genuinely solicit feedback early and often.
• You humbly reflect on past mistakes.
• You actively seek out learning opportunities instead of avoiding them.
• You identify gaps in knowledge and share them openly and honestly.

Here are some ways that we support learning, teaching, and knowledge-sharing at Sourcegraph:

• We aim to provide a high-quality onboarding experience for new teammates by providing them with the learning materials and guidance they need to get started.
• We have an education budget for professional development. This budget is dedicated to helping teammates expand their knowledge, whether it’s through books, courses, training, or other resources.
• We organize occasional hackathons internally, which are opportunities to learn, experiment, and share knowledge.
• Product and Engineering teams host regular Demo days in which we share progress and learn from each other.
• We teach each other new things in Brain food sessions
• We encourage self-directed growth.
• We strive to support teammates who are interested in making career changes by switching teams or roles.
• We have a framework for supporting early-career engineers.