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 through iteration

You are responsible for defining and building high quality work iteratively.

We try to ship small things fast, instead of big things slowly. Being iterative allows us to avoid unnecessarily long planning, avoid deadlocks, and derisk what we do faster, increasing the value we create for customers. Postponing shipping things leads to them being outdated, creates complexity in managing what’s not been shipped, and delays learning what high quality is.

Discussions around large changes tend to be slow and deadlock, whereas small steps are much more likely to lead to a decision. Bundling lots of problems together in the hope that you can fix them all at once is attractive, but it rarely works. That’s because as you increase the complexity of your proposal it becomes more and more likely that the whole thing will get stuck, and because finding out what high quality is for a bundle of problems is much harder and vague. It’s also always easier to re-evaluate after we have learnt by taking a first step.

Having a strong vision and strategy allows us define and deliver high quality iteratively: it gives us the framework that we need to move in the right direction, and allows us to plan less and iterate faster instead.

In practice this means we:

• cut scope to get things out faster
• don’t hide work in progress from customers as long as the change is better than the previous state
• start a proposal, instead of waiting to organize a meeting to collect input
• try to make reversible decisions, that allow us to change our mind if we change our definition of success

Being iterative allows us to work efficiently in an async-first setting. As long as we are aligned on our vision and strategy, being iterative reduces the need for heavy coordination, because we are mostly taking small reversible steps. It reduces communication bandwidth, because in many case we can share concrete artifacts (a PR, customer feedback on an iteration, a proposal) instead of sharing larger plans.

We should avoid iterating in a way that requires change management or large company-wide communication (for example, changing planning processes in the middle of planning). You can do this by either waiting until the end of the process, or by making it clear that the changes will take effect next time.

Because we’re a handbook first company, anyone can rapidly get caught up on recent changes by reading the handbook page.

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.

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 collect and curate educational resources (for use with the education budget mentioned above) in the Educational Resources Library.
• We organize occasional hackathons internally, which are opportunities to learn, experiment, and share knowledge.
• The Engineering department hosts 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.