Enablement org

Mission

Our mission is to provide technical foundations critical to the business, our customers, and our products. We do this by ensuring we have the best tools, processes, and services in place, for use by both customers and our own engineers when using or developing Sourcegraph. For a deep dive into our mission see our strategy page

Team

The org is lead by Serina Clark (Director of Product) and Jean du Plessis (Director of Engineering).

Repo Management

Dev Experience

Frontend Platform

Content Platform

Michal Vrtiak serves as an org-level engineer, reporting into the Director of Engineering, and partners with the individual teams in the following modes:

Team NamePartnership mode
Repo Managementcoordinator, collaborator, advisor
Dev Experiencecoordinator, collaborator, advisor
Frontend Platformadvisor
Content Platformadvisor

The collaboration modes are described in the profile role description.

Principles and practices

In addition to the engineering principles and practices, the Enablement org follows the following principles and practices. Each team is afforded the freedom to operate as best they see fit to achieve their goals. Below are principles and practices all teams in the Enablement org follow.

Unblocking others is your highest priority

Suppose a teammate is blocked by you on a question, your approval, or a pull request review. In that case, your top priority is always to unblock them, either directly or by helping them find someone else who can, even if this takes time away from your own or your team’s priorities. If you’re the one who is blocked, be sure to communicate that so that others can prioritize appropriately.

Typically, waiting for a PR review does not mean you are blocked: it’s expected that you can start working on something else (e.g., a new PR that depends on the first one). However, it’s important to get a review ASAP in some scenarios—e.g., to fix a regression or a broken CI pipeline. In those cases, you should communicate the urgency and expect that your teammates will prioritize unblocking you.

Even when a teammate is not blocked but inconvenienced (because of follow-up work), please don’t leave them hanging for extended periods. You should generally budget some amount of time every day for doing reviews.

We want teammates to do what is best for the org as a whole. Don’t optimize for your team’s goals when it negatively impacts the goals of other teams, our users, or the company. Those goals are also your problem and your job.

Pull requests

For authors

Prefer small PRs (<400 lines)

We extend Sourcegraph’s company-wide guidance (see what makes an effective PR) with a specific guideline that PRs should contain less than 400 changed lines (excluding tests). Note that this is a guideline and not a hard limit; there are situations where it doesn’t make sense (e.g., PRs that are primarily mechanical changes).

There are several reasons to prefer small PRs:

  • Reviews happen more quickly (“I’ll just review this quickly right now” instead of “Hmmm, better schedule time for this later”).
  • It enables higher-quality reviews because there’s less context for the reviewer to hold in their head. It’s also easier to suggest significant changes when your teammate has spent only a few hours on a PR rather than a day or more.
  • It encourages a tighter feedback loop.
  • Smaller atomic changes are easier to roll back if required.
Keep reviewers to a minimum

Pull request authors should always prefer requesting reviews from a specific teammate(s) as opposed to a group. This creates accountability and clear expectations. A single reviewer is usually sufficient.

For reviewers

Reviewers should try to review promptly, allowing everyone involved in the pull request to iterate faster as the context is fresh in memory. Reviewers should aim to review within one working day from the date they were assigned to the pull request. If you don’t think you’ll be able to review a pull request within that time, let the author know as soon as possible.

If the pull request’s author has not heard anything after one day, a new reviewer should be assigned.

Communication

We recognize that frequent, open communication is key to the success of every team, especially in an all-remote environment. We default to asynchronous communication in Slack, Google Docs, and GitHub issues over other mediums (video calls, emails, etc.) as we respect our teammates’ time.

In addition to team-specific channels, we communicate in the following org-wide channels in Slack:

#enablement-org: Used primarily for org-wide communication and for other orgs to reach out for cross-org collaboration.

#enablement-social goes into this channel and random conversations, banter, jokes, etc., are all welcome here.

#enablement-staff: This channel is for the Enablement staff to discuss higher-level matters impacting the whole org.

Slack acknowledgment

It is essential to remove assumptions/uncertainty around whether teammates have seen, understood, or acted on a message in an async-first communication environment. To assist in this regard, we provide the following guideline for teammates to follow when communicating and responding in Slack.

The most important thing to remember is not which emoji to use, but rather to remember to acknowledge and do it unambiguously.

When acknowledging a request:

  • :thumbsup: (👍) = I see the request and will action it
  • :white_check_mark: (✅) = I have completed my action on the request

When acknowledging a statement:

  • :thumbsup: 👍 = I agree with the statement or I have taken note of it
  • :thumbsdown: 👎 = I disagree with a statement—encouraged to always follow up with a written response

When acknowledging a question:

You should provide a written response unless it’s a simple yes/no question, in which case :thumbs-up: (👍)/:thumbs-down: (👎) is acceptable.

Weekly Slack check-ins

We use Geekbot to facilitate a once-a-week (on a Monday) social check-in where we ask teammates across the org the share a bit about what goes on in their life in the #enablement-social Slack channel. We also use this opportunity to build camaraderie between team members by sharing some non-work-related aspects of our lives.

Participation in sharing is voluntary.

Status updates

Each Engineering Manager of the teams in the org is responsible for sending out a status update once a month.

Staff sync

To stay aligned as an organization we share our priorities for the week in the #enablement-staff channel on Mondays. On Fridays a reminder is sent to the same channel prompting the team with the following:

  • What updates do you have on our OKRs
  • Any highlights on team accomplishments?
  • Any challenges or risks to call out?

On Thursdays we meet as a leadership staff via Zoom to have real-time conversations. We cover one fun question, staff updates, and hot topics. This time gives us space to catch up on topics that are better discussed live and to drive quick decisions. If we do not have a large enough cohort we will run the meeting async.