The Cloud Software-as-a-Service (SaaS) Team is responsible for the service management part of the Sourcegraph Cloud product. The team provides both customer-facing and internal capabilities that enable our customers to use the Sourcegraph Cloud product as a service.
TBA. More can be found in our Cloud Vision
Our detailed Sourcegraph Cloud roadmap is currently internal-only until our public announcement later this year. Our OKRs are publicly available here.
Beyond , our goals over the next months include:
- Provide a delightful self-service onboarding and self-service payments capabilities for new developers and new teams to enable a true Software-as-a-Service experience for customers who prefer it
- Provide in-depth administration capabilities to unlock adoption of Sourcegraph Cloud by large enterprises
- Enable full multi-tenancy for Sourcegraph, both cloud and on-prem, providing additional security for customers who prefer it
- Create a culture that focuses on launching and landing features by verifying user love of each new feature we release
Service management is a broad area of ownership. To provide more clarity into what its stands for, we will break this down based on product domains. We will also provide a list of features and services from a technical engineering ownership perspective.
Capabilities that provide customers with transparency and access control to how Sourcegraph Cloud is used within their organizations. This means changing the Sourcegraph product from a single to multi-tenant architecture that will enable multiple customers to operate on a single shared cloud instance securely. On the other side, it’s all about providing functionalities to support organizations collaborating on the cloud. This includes but is not limited to team management, role-based access control, and other features targeted towards admins on our customer’s side.
In addition to the organization-level management capabilities, we are also responsible for individual users’ administration experience.
While managing code host connections and repositories as a domain is owned by the Repository Management team, we identify this area as crucial for supporting organizations collaborating on the cloud. It’s also impacted by the transition from single to multi-tenant architecture. Because of both, we acknowledge the lack of clear boundaries between the domains and the need for close collaboration between both teams in this problem space.
The end-to-end experience of managing customers’ subscription lifecycle includes the subscription as the entity, its changes over time, and the impact on Sourcegraph product offering and AAR. This includes both providing transparency to the customers and internal tooling to support Customer Engineering and Finance and Sales teams.
Both technical and presentational sides of pricing. This includes both the presentation of pricing tiers to the customers with the process of selecting an appropriate plan and underlying technical implementation of the pricing model and its connection with billing and payments, plus impact on subscription management.
The end-to-end self-service process on paying for Sourcegraph subscription on the cloud.
We own both authentication and authorization to Sourcegraph.com, including both login and sign-up flow and user management on the cloud.
Code-level authorization is enforced based on the repository permissions on the code host level and the Repository Management team owns this area. It is coupled with administration experience and team management, which created close collaboration between both teams.
Customer-facing and internal tools and features that provide transparency to how customers consume entitlements within their current subscription, including entitlements limiting enforcing capabilities.
The list below contains features and services that already exist, and the Cloud SaaS team is responsible for keeping the light on them.
- User profile and settings
- Sign up flow
- Post sign up and onboarding flow
- User notifications
- Ryan Phillips (he/him) - Product Manager
- Quinn Keast (he/him) - Product Designer
- Rafal Leszczynski (he/him) - Engineering Manager
We’re hiring! Check out our open roles.
The Cloud SaaS team works alongside several other teams within the Cloud organization at Sourcegraph. You can find more information about their teams and goals on the respective pages:
Each Friday, we send weekly team updates to the rest of the Cloud org to keep the Cloud senior leadership and our partner teams in the loop about Cloud SaaS Team progress and our ups and downs. You can find all the weekly updates in this Google Docs.
We are committed to sending a monthly newsletter to the entire Product and Engineering org summarising our progress towards current goals, challenges, opportunities, learning, and important team updates. You can find all the previous entries in the links below:
- For cloud users with urgent help requests reach out to our support team at firstname.lastname@example.org.
- For emergencies and incidents, alert the team using Slack command
/genie alert [message] for Cloud SaaS Team.
- For internal Sourcegraph teammates, join us in #cloud-saas to ask questions or request help from our team.
- For cloud users with feature requests, please reach out to our product manager, Ryan, at email@example.com and include
Cloud Feature Request:in your subject line.
The Cloud SaaS team plans work based on our long-term roadmap and setting quarterly goals. During the quarter, we follow a flavor of the SCRUM process with biweekly sprints. Our cycle starts every second Tuesday with a retrospective, sprint review, and planning meetings. We set goals for each sprint and focus team efforts during the iteration on achieving these goals rather than closing a number of issues. It’s the outcomes and delivered customer value, not the output, that matters.
We are using Jira as our project tracking tool. While you will need access to Sourcegraph Atlassian account to view the Cloud SaaS project the list view of all the issues within this project is publicly available.
- Jira is the single source of truth for our backlog. Please use descriptions, comments under Jira issues, and different categorization options to keep all the issues up to date. Comments are also the best place for asking questions about the issue itself. That way, we keep all the context in a single place.
- We use versions/releases for milestones (usually connected with the quarterly goals) and group issues for given initiatives/projects into epics.
- We use components to track different service or engineering ownership areas. This for example, helps us understand what the cost of operations with each area we own is.
- To track GitHub PRs automatically in JIRA, use the JIRA ticket number anywhere in the branch name. So for example, if the ticket number is
CLOUD-42and you name your branch
the-answer-to-everything-CLOUD-42, the resulting PR from this branch will automatically be associated with the JIRA ticket. The same goes for commits and PRs - all will be linked to a Jira issue as long as you keep the issue id within the commit message or PR title.
- We use Agile Poker addon for groomings and estimation sessions which we run asynchronously.
- You can use Jira issue ID (exp.
CLOUD-123) within the messages on the #cloud-saas-internal Slack channel to automatically create a link to Jira issue. We are also pushing all status changes to our Jira project to #cloud-saas-jira Slack channel.
We conduct regular user research and usability testing. This helps us understand how our product is being used, identify pain points and opportunities, and better understand our users.
Research is typically planned, organized, and executed by the product team.
Anyone on the team can join a research session as an observer and notetaker. Observing and notetaking during user interviews and testing sessions is an amazing way to get a first-hand look at how others use our products and ideas, and your role as a notetaker is a huge help for the team.
See ”So you’re about to help us with user testing” to learn what to expect during user research sessions and how to take great notes.
We use a shared Sourcegraph Cloud Research calendar to schedule and surface research activities. When new research sessions are scheduled, they will be automatically duplicated to the Cloud SaaS team calendar, and the Cloud SaaS team invited as attendees (note that attendance is always optional, but we haven’t found a way to reflect this in the automatic event).
This document contains all important decisions and agreements done within the Cloud SaaS team in chronological order so that they can be tracked over time. Consider this a single source of truth for all the decisions within the team. If you are leading the decision-making process, please update the documents with the details about the decision made. If appropriate, especially for team working agreement, please update the handbook as well.
We are a globally distributed team with 16+ hours of time zone difference. Asynchronous communication is a key for achieving high visibility and close collaboration within the team. In addition to general Sourcegraph async communication guidelines, we agreed to the following recommendations within the Cloud SaaS team.
While the team is following multiple Slack channels, #cloud-saas-internal is the place for all work-related discussions, including status updates, questions, requests for help, team announcements, etc. Please remember that Slack is not a source of truth. To make the relevant information easily discoverable over time, use other channels (for example, Jira, Handbook, Google docs, etc.) and reference them on Slack via links. It’s worth thinking about Slack as a synchronous—rather than asynchronous—communication channel.
Jira is the Cloud SaaS team’s single source of truth for team backlog, work planning, and execution. Please include all tasks related to status updates and questions within Jira issues and keep the state of the sprint board up to date.
Please keep all discussions related to ongoing code changes within GitHub pull requests. You will find more guidelines for making PRs and asking for code review in the Making pull requests and asking for code reviews section.
We use Figma for high- and medium-fidelity design and prototyping. High-fidelity design artifacts and their annotations should be considered a source of truth for design implementation, copy, and interaction behavior.
Use comments in Figma to ask questions and share feedback. If a decision or missing information is uncovered in comments in Figma, that context will be added to the design artifact itself as an annotation.
Google doc is a great choice for kicking off async collaboration, proposing RFC, writing a one-pager problem definition, or documenting a decision. To make the context in Google docs more discoverable, we agreed to:
- Public Information - Convert it to a handbook section/page linked from the main Cloud SaaS team handbook page once
- Information internal to Sourcegraph - Add a link to the Google doc to the Cloud SaaS team handbook page, ensuring that sensitive information is not exposed in the link title.
Please read this for more context about the difference between public and internal information.
We are using Loom to record short videos for bug reports, demos, and for multimodal communication. This way, we can provide more context to the rest of the Cloud SaaS team.
All team members, including product manager, engineering manager, and product designer, have agreed to share regular status updates on the #cloud-saas-internal Slack channel. The recommended cadence is either daily or every second day, based on the needs and personal preferences. These updates should be focused on current sprint or quarterly goals, risk and blockers, requests for help, and any personal information you would like to share with your team.
To keep the updates standardized, we are using the following template:
👉 Status update 👈 What is my priority: <content> What went unexpected: <content> Where do I need help: <content>
Each sprint is followed by a short sprint review meeting on Google Meet. During this meeting, we review the state of sprint goals, demo the features we delivered and discuss topics related to the sprint’s scope. We also review the state of our retrospective actions items. This is an open meeting. Our stakeholders and members of other teams at Sourcegraph are always welcome to attend. Each review has a designated facilitator, usually an engineer from the Cloud SaaS team, responsible for filling in the agenda and facilitating the meeting.
The team is doing retrospectives on a biweekly basis at the end of each sprint. We are using Retrium and changing the format of the retrospective from time to time, experimenting with different techniques available within Retrium tool. Action items from the retrospective are migrated to Jira and usually have the owner assigned responsible for leading the action to its completion.
To support the globally distributed nature of our team, we are doing our groomings in an asynchronous format. Agile Poker Jira addon is our tool of choice, and we are running our groomings session based on the following schedule:
- Each Monday, the new async grooming session should be created within Agile Poker app
- Every task added to the session should have an owner assigned. The task assignee is responsible for breaking the tasks into meaningful subtasks if applicable and working on description and acceptance criteria to meet the expectations of our DoR. This should be done between Monday and Wednesday.
- Thursday and Friday are reserved for the whole team async estimation based on the Agile Poker session settings. We are using Fibonacci numbers and treating one story point as one day of work for a single engineer
All team events and reminders should be added to the team calendar. This will allow us to keep all team events and reminders in a single place, increasing visibility for people within and outside of the team.
- Please add
firstname.lastname@example.org to participants for all events you expect people to join/participate in. This will automatically block time on your peers’ calendars. Also, if they can’t join, they can decline the event providing transparency about their ability to participate.
- For reminders, you don’t need to add participants
- #cloud-saas-internal - internal channel for Cloud SaaS team for all day to day communication within the team
- #cloud-saas - external channel for Cloud SaaS team where other Sourcegraphers can ask for help or leave questions for the team
- #cloud-saas-jira - integration with Cloud SaaS Jira project, all changes to the project including new issues, or issue status changes are automatically reported to this channel
- #cloud-org - public channel for all the members of Cloud product and engineering organization
- #cloud-org-social - public channel where all the members of Cloud product and engineering organization can get to know each other, socialize and talk about other non-work-related topics.
- #cloud-research - public channel for all the updates about user research related to Sourcegraph Cloud
- #cloud-gtm - a place to discuss Sourcegraph Gloud go to market strategy, including pricing, packaging, customers, and more!
This section contains links to Cloud SaaS specific interview types.