Sourcegraph values

These values are the beliefs and principles that help us achieve our goals and vision and build an inclusive team. These apply at every level of our organization—”you” refers to individuals, teams, and Sourcegraph as a whole.

Be customer driven: You proactively work on the right things by continuously orienting your goals around delivering value to your customers.
Work as a team: You work collaboratively with your peers, cross-functional teammates, and leadership to create shared success, trust, and belonging.
High agency: You have the power and the responsibility to improve Sourcegraph as a company and as a product. You deliver regardless of the circumstances.
High quality: You are responsible for finding out what high-quality work looks like and producing that high-quality work iteratively.
Be welcoming and inclusive: You make people from all groups and backgrounds feel comfortable belonging to our team and community.
Open and transparent: You proactively communicate in an open and transparent way.
Continuously grow: You strive to continuously grow and learn by genuinely soliciting feedback early and often, and humbly reflecting on your past mistakes.

Values in detail

Be customer driven

You proactively work on the right things by continuously orienting your goals around delivering value to your customers.

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! 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.

This doesn’t mean that you should make unilateral decisions. 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 actively 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.

Level of transparency	Description	Channels	Examples
Public	Anyone outside of Sourcegraph can access this information. This is the default level of transparency.	Handbook, code, issues, public Google Docs such as RFCs	Goals, plans, all code, product docs, dev docs, company docs
Internal to Sourcegraph	Information that is not public for specific reasons, but is shared with Sourcegraph teammates.	Public Slack channels, Google Docs accessible to everyone at Sourcegraph, internal Google Groups	Board slides, company financial info, customer information, open security investigations
Private	Information that is neither public nor internal to Sourcegraph for specific reasons, but is shared only with a specific set of people.	Private Slack channels or DMs, private Google Docs, private emails	Feedback, compensation, and personal information of teammates and candidates

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.

Make your document accessible to everyone at Sourcegraph.
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”).
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 by genuinely soliciting feedback early and often, and humbly reflecting on your past mistakes.