Support Team Rituals

Team rituals help maintain healthy communication, boundaries, and expectations between teammates and as a team. Our rituals can and should evolve as our team evolves. It is welcome to iterate on and experiment with our rituals.

Asynchronous collaboration

In order to stay in touch throughout the week and support each other, we share the following in our #customer-support-internal Slack channel…

  • Weekly planning. Every Monday we take some time to orient ourselves and then share with each other our intentions for the week.
  • Daily captain’s log. Every day as we go about our days, we share things we learn/read/hear that are important for us to all know. Yes, we are all in the same channels, but a lot happens in Slack every day and this is how we collectively stay on top of things.
  • Weekly reflection. Every Friday we take some time to reflect on the week and share a summary with each other.
  • As-needed what you missed compilation. When someone is not working, before they are out, they share a doc for the rest of the team to populate with anything we want to be sure they are aware of from when they were away

Synchronous collaboration

In order to get some purposeful face-time in with each other, we convene synchronously over Zoom each week for…


In order to maintain healthy communication, we…

  • We populate and refer to our team README to orient ourselves for working with each other
  • We honor that not everyone writes/speaks English as their first language and use Grammarly and HemingwayApp to help make sure we are saying what we intend
  • We rotate who facilitates our weekly planning/retro session so that we normalize hearing each other and noticing when someone isn’t getting a chance to talk
  • We take turns each month auditing our section of the handbook to make sure it’s current and accurate
  • We create succint title-like first posts and share details in the thread in #customer-support-internal. This is our most active channel and doing this makes it easier to find threads we might need a day or two later. We still make sure the handbook is our source of truth, not Slack; this just helps keep things easier to navigate whilst talking about multiple topics.

An occasional challenge of being async by default is there can be a lot to read in Slack. To ensure that we stay as informed as possible and set healthy boundaries around Slack, for the following channels we do the following

  • #customer-support: We stay attentive as this is where we collaborate with everyone outside of support. If there is a question/request, you have the agency to assist. We are a fully remote team and it is our responsibility to ensure our teammates feel supported. Leadership note: If there is a specific @cs-leadership mention an online member of the leadership team is expected to respond within 24 hours (this time frame is for each thread)
  • #customer-support-internal: We read EVERY single thread even those that are posted when we are not working within 24 hours of it being posted to stay aligned with our teammates and emoji react accordingly so we all have confirmation we are on the same page.
  • #announcements: We read every single thread by the end of each week to stay informed of what is happening more broadly across the entire organization.
  • #customer-support-triage: whoever is responsible pays close attention to that channel, as well as the manual triage channels, and actively asks for coverage if needing to be AFK.
  • #prod-eng-announce: We read every single thread by the end of the week to stay informed of what is happening across the product/engineering organization.


In order to keep the air clear with each other, we do the following:

  • We honor our Sourcegraph values, code of conduct, and team ethos
  • We make it clear when are committing to do something, we make it equally clear when we cannot, and we adjust and communicate accordingly when life happens
  • We let each other know immediately when we are feeling like it’s anything other than feasible to get done what we have committed to doing
  • We let each other know immediately the moment we realize something we committed to doing may be at risk somehow

When we are away from our keyboard (afk) or out of office (ooo)

If you are going to away from your keyboard (afk) or out of office (ooo) – planned or unplanned, for your focus day or time off – the team relies on you using your agency to make sure what you ensure there is a plan to cover what have committed to being responsible for.

We always make sure the following is true:

  • We let each other know when we are/will be unavailable by posting in our #customer-support-internal Slack channel and adding it to Roots to be sure it’s also reflected in the team CS team calendar and our Slack status.
  • Before we are afk or ooo, we clearly indicate why a case can wait for us to return OR we post in our #customer-support-internal Slack channel and ask that someone either fill in or take it over (fill in if it’s just a day and you want someone to keep an eye on it or have something specific and not time consuming for them to do; take it over if you are gone for a few days and we want the customer to have a smooth handover).

We want to minimize customers having to work with more than one application engineer; so we strive to keep fill-in requests and handovers rare. Fill-in requests should be simple things (not covering calls or doing heavy debugging). For example, keeping an eye to see if our engineering teammates get back to us on a RFH for a time-sensitive issue and sharing that with the customer would be a reasonable request (vs if the issue isn’t that urgent, it’s okay for it to wait until you return). We want to show-up for each other, but also not confuse the customer – in theory, maintaining no more than 5 open/active tickets should allow for things to be such that taking 1-2 days off doesn’t require anyone on the team to do anything. We mostly reserve handovers for when folks have 3+ days off or it’s an exceptional situation where a handover will be truly best.

When you will be away for 3+ days and a handover is required, post about each case requiring handover in a new thread. This will make it easier for whomever is on @cs-triage duty to help make sure another AER takes responsibility.

You never have to ask to take the time you need and you never have to share why you need the time you do. You just need to communicate clearly and make sure the team knows how to show-up for you and it honors the customer experience.

Also, sometimes we wake up not feeling well and we don’t have it in us to line things up. That’s okay! Simply add a sick day to Roots and post in #customer-support-internal Slack channel and @ mention @cs-leadership and ask that they tend to things for you. A member of @cs-leadership will make the call about whether any coverage is needed and work to ensure as little goes to the rest of the team as possible. Again, you don’t have to say why you need the day, just that you do; posting in the shared channel ensures whoever is online can help (you can also, of course, share details with whoever you desire).

For those who cover Fridays, we also need to ask that someone cover our Friday responsibilities. When you need to take a Friday off planned or unplanned, you can lean on @cs-leadership to help make sure you have coverage. We can also rely on @cs-leadership to track who has covered a Friday to make sure this doesn’t always fall to the same person:

  • For SLA Pacific hour time block 2am-7am the following folks can cover for Mariam: Michael or Stompy
  • For SLA Pacific hour time block 7am-12pm the following folks can cover for Don: Alex, Ben, Jason, and Riana (Riana once they reach 90 days)
  • For SLA Pacific hour time block 12pm-5pm the following folks can cover for Kelvin: Amber, Gabe, and Warren (Amber when she returns from leave)
  • For SLA Pacific hour triage coverage from 7am-5pm, Brielle, and Shawnteé work together to handle any exceptions needed to the schedule (which is maintained on the team calendar).

Optionally, when we are out for more than a day or two, we can create a “what did I miss” doc in our shared drive folder for our teammates to populate with things we need to catch-up, be aware of when we return.

Saying Farewell

Moving on from the team or the company can be a significant milestone/pivot point in the lives of team members. In order to facilitate a human centered approach to these departures from the team we seek to …

  • Celebrate achievements
  • Grieve/mourn the ending
  • Hope for the future
  • Provide a space for closure/reflection

We do this by …

  • Sending out a virtual card signed by the entire team. Team members should try to write notes expressing gratitude, encouragement and/or highlighting ways the individual has impacted them.
  • Sending out a card directly from a member or members of the leadership team.
  • Allowing/ encouraging/ asking the individual to write a grand final post on their last day as a member of the team.
  • Meeting with the team member for the final debrief to solicit any input from them on anything they think we should know/learn from.
  • On their last day as a team member, announcing and then removing the individual from:
    • Zendesk
    • Team invites
    • The CS Google, Github, and Slack @ groups
    • Links to their README (the file will still be there if you need it for your new team)
    • The support team org chart
    • The team schedule
  • Allowing team members to decide on/opt in or out of a synchronous virtual gathering. A part of this can be a Q&A where other team members solicit advice and ask questions.