When set up for it, engineering and support teams have so much to offer each other. This is how we have set-up our teams to realize the benefits of learning from each other and the discrete workflows and work focuses of each team. And, of course, everything here aligns with support’s desire to be as self-sustaining as possible, where our success is felt most when we are able to understand common troubleshooting patterns, diagnostic steps, and tools, etc with less reliance on engineering in order to solve issues faster for our customers.
CS categorizes all customer inquiries so that we can get better insight into trends and identify opportunities for improvement. CS application engineers also share qualitative data about customer context and/or issues to ensure we fully consider what is best for the customer in our decision making.
Some folks in engineering offer office hours and those can be useful for an application engineer to join to learn, ask questions, collaborate.
- Application engineers rotate on other engineering teams. Depending on interest and timing with all involved, application engineer may also do rotations in other teams. These will be carefully coordinated to make sure that we always have enough help available to our customers. If an application engineer is interested, they can start the process by talking with their manager to determine next steps.
- Members of engineering rotate on support. There is tons of value in working directly with customers and seeing the variety of questions and issues that come up across our entire customer base. Any member of engineering who is interested in working in support for a day or even a week, just needs to let the support team in #customer-support-internal and we will make it happen.
Pairings are different from rotations in that they are usually ad-hoc in nature and there is an event that results in a pairing being useful. For example, the events outlined by the Batch Changes team or working on a ticket together. This is very much a “I have something useful for you” or “I have a question for you” and the best step for all involved is to work closely together on it, pairing style. A pairing could also happen while support follows the protocol to engage other teams. While that protocol is designed to foster our remote-first culture and allow for folks to work across timezone and asynchronously, the CS or engineering team member can always initiate the idea of pairing on an issue if the situation/issue seems like it would benefit from it.
We are not quite a big enough team to have folks pair long term with one team. From time to time, however, we may want to retro with a team. We can do this in a few ways, depending on the preference of those involved:
- An application engineer can join the existing engineering team’s retro session and participate (great for casual collaboration, when there isn’t anything specific, and if the engineering team agrees)
- The CS team and X engineering team can schedule a time to do a dedicated retro together on a topic, how they are working together, etc
- An application engineer and one rep from each engineering team can join in an org wide session
It can be hard to focus on the root cause. It can be far too easy to focus on solving for a symptom instead. Application engineers know to keep this focus and how to divide the work so that we offer a quick solution and are able to plan for the deeper work to address the underlying issue. Read an open letter about root cause for more.
The software engineer doing support rotation for their team can join the #customer-support-weekly-pairing Slack channel and be paired with an application engineer for a focused coffee-style chat with the following agenda:
- If the application engineer and software engineer haven’t met before: intros, otherwise, casual catch-up
- Software engineer: what’s going on on my team? What’s being built? What am I (personally) building?
- Application engineer: what’s going on in support, in general? What’s going on with supporting (search|code-intel|$TEAM)? What have been my pain points (personally)?
- (Optional): application engineer or software engineer: bring any topics you’d like to learn about
If the donut app pairs two engineers, we can do some swapping to ensure CS and engineering pairings.
Whenever a software engineer or an application engineer has the desire/time to create training materials they feel will help CS and that can be available on-demand (written or video), it’s as easy as:
We have a shared responsibility to maintain and improve docs.sourcegraph.com. Whenever an application engineer identifies a gap or something that needs to be updated, we will either:
- Make the edit on (or create) the actual docs page (in Github) and seek review from the appropriate engineering team
- File a docs issue in Github for the appropriate engineering team explaining what is missing, and tag it as
docsas well as tagging the appropriate engineering team to fill in the gaps/needs we have identified
When we work on documentation, we…
- …remind ourselves that the vision set forth by our product team for our docs is to align with the the organizational approach outlined in https://documentation.divio.com/, especially the how-to section and their examples (how-to is the doc type we create/improve the most)
- …remind ourselves of the guidelines for contributing to product documentation, as well as the content creation guidelines
- …note that troubleshooting documentation falls into the category of how-to documentation as outlined in the vision above
- …ensure that every page in our docs to have a single purpose (it may take us awhile to redo what is there, but keep this in mind for creating/revising)
- …ensure that if we move a page, we add a redirect for the old URL here
- …default to explaining in text so it’s searchable (avoid screenshots)
Some engineering teams have a way for an application engineer to take on a scope-bound project (like taking responsibility for a small Github issue). This isn’t easy for all teams and it’s better if we start with a conversation than jumping in. Also consider the following…
Our Frontend Platform team welcomes you to:
- Learn Typescript and React
- Learn how to write unit tests with Jest
- Read Developing Sourcegraph
- Read Web Client Development
- Read Sourcegraph’s testing principles
- Read how Sourcegraph tests web code
- Explore the frontend codebase
- Explore Frontend Platform GitHub issues
- Start with issues with the
good first issuelabel
- Chat with your manager about your plan
- Let Patrick (engineering manager of the team) know which ticket you’d like to work on