These values are the beliefs and principles that help us achieve our goals and strategy and build an inclusive team. These apply at every level of our organization—“you” refers to individuals, teams, and Sourcegraph as a whole.
- Customer-first: You earn and keep the trust of our customers by putting their interests first.
- 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.
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“.
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.
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.
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).
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“.
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||Business metrics, 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.
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.
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.