Cloud Software-as-a-Service Team

Administration experience and teams management

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.

Subscription management

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.

Pricing and packaging

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.

Billing, invoicing, and payments

The end-to-end self-service process on paying for Sourcegraph subscription on the cloud.

Identity and access management

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.

Usage reporting and entitlement enforcement

Customer-facing and internal tools and features that provide transparency to how customers consume entitlements within their current subscription, including entitlements limiting enforcing capabilities.

How we use Jira

• 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-42 and 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.

Observing user research

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.

User research calendar

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

Decision log

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.

Team internal communication

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.

👉 Status update 👈

What is my priority:
<content>

What went unexpected:
<content>

Where do I need help:
<content>

Sprint reviews

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.

Retrospectives

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.

Groomings

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.
• Each story point represents a single developer day.

The “grooming” label is used for marking tickets to be included in the upcoming grooming session.

Team calendar

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 cloud-saas-team@sourcegraph.com group 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

Making pull requests and asking for code reviews

• Everyone (including engineers, EM, PM, PD) should set up a reliable way to receive pull request review notifications, examples are emails, Slack notifications (through GitHub Scheduled reminders). In some cases, direct pinging required reviewers could inform reviewers about the urgency and may help expedite receiving reviews.
• Pull requests in the draft state indicate work in progress and not ready for review, while occasionally the author may ask for early feedback in explicit forms, examples are direct pings, mentioned on the pull requests.

Definition of done (DoD)

TBD

Definition of ready (DoR)

TBD

On-call

TBD

First month

The central theme for the first month is learning. During these 30 days, your goal is to acquire the foundational domain knowledge about our product, processes, architecture, and codebase to help you feel comfortable and effective in a software engineer’s role in the Cloud SaaS team.

You will be exposed to a ton of new information - you will meet many people, read multiple documents, and, most importantly, solve small, well-defined technical challenges. We understand this might feel overwhelming, so please relax and do not stress. This first month is the time for learning and growth.

Second month

We will give you more ownership and opportunities to make an impact. While learning will still be the central theme, you can expect more complex problems to solve. You will also get your first project assigned, requiring you to collaborate with other teams, think about planning, execution, risk management, technical design, and other factors.

With the domain knowledge and business context you have acquired so far, it’s an excellent opportunity to start making an impact on the team. We expect your honest feedback about our current processes, tooling, architecture, code base, product goals etc. Please be proactive in sharing your ideas on how we can improve in the spirit of continuous improvement.

Third month

Time is running fast, and you learned a lot. You feel productive and autonomous, and your contributions make a real impact on the team. It’s time to provide you with more technical leadership opportunities.

We would like you to take the role of a Directly Responsible Individual (DRI) for a given project. DRIs are empowered and accountable for the success of the initiative they lead. The scope and complexity of the problem will depend on your seniority level. While you likely won’t be the only person working on this project, it’s up to you to make sure it gets done and that you have all resources necessary. Being a DRI might sound challenging and stressful, especially during your first months at Sourcegraph. Don’t worry; your buddy, peers, and team’s triad (Project Manager, Project Designer, and Engineering Manager) are here to help and support you. The goal is to give you the sense of responsibility, ownership, and experience of wearing different hats.

Finally, we would like you to start shadowing your team members during on-call rotation and participate in responding to and resolving production incidents. This experience will prepare you for performing on-call duty once you finish your onboarding process.