CTO
Mandate: Build experiments that support the company’s mission but don’t fit well into the priorities of Engineering.
Experiment proposals
We will iterate on an approval process for new experiments. We want to enable experiment proposals to come from anywhere within Sourcegraph, but also note that our current bandwidth for experiments is intentionally limited and we don’t expect this bandwidth to exceed more than 1% of our overall investment in Engineering. For now, we are working on doctree and won’t have bandwidth to take on additional experiments in .
Successful experiments should aspirationally aim to “graduate” into the product organization. This process will be “pull” rather than “push”, meaning it is at the discretion of product leaders to evaluate when an experiment has demonstrated enough validation. No changes to the main codebase will be made until this agreement is reached. The experiment owner is expected to help in whatever capacity is needed through this transition.
FAQ
Q: How are experiments proposed and approved? A: Just DM Beyang with your idea, but bear in mind the earlier note about bandwidth. Beyang will approve experiments, with sign-off from your manager to ensure there isn’t a conflict with the product roadmap.
Q: How many people are working on this? A: Beyang and Stephen.
Q: Should we view the CTO as the default home for new products now? A: No, part of our culture at Sourcegraph is to make bold bets on new products and features that will benefit our customers. We have some great precedents (Batch Changes, Code Insights, Search Notebooks, Compute), and we expect and desire the bulk of these efforts to continue to happen within Engineering. CTO experiments are those that don’t align well with Product priorities, and we’re allocating only a small amount of bandwidth and resources to pursuing these.
Q: How should I think about and engage with projects this team is working on? A: With respect to coordination with teams in Product/Engineering, treat this almost like a separate company. We don’t request or expect engagement from product teams, but if folks think it’s interesting and want to chat about it, we’re open to sharing. If you think what we’re doing is compelling, go ahead and copycat—unlike a completely separate company, we would be eager to partner and help you build upon any good ideas from our work. Ongoing discussion on doctree is happening in the #doctree channel. We will collaborate with Marketing, Sales, and CE to bring these experiments to the attention of devs who might find them interesting, but expect our asks here to be minimal.