Skip to content

Add "Working with our team" section

Kerri Miller requested to merge kerrizor-master-patch-55415 into master

Why is this change being made?

I was thinking about the discussion around declining MR rate last month as we as the idea that we should collectively strive for broader exposure to customers, and given how much we’re a “front line” team — our features are high-profile, and we’re often called on to diagnose/triage issues with MRs, regardless of root cause, answer customer questions about why things work the way that do, etc. I believe the impact to our collective productivity would be slightly reduced if we had an explicit clarity on expectations for response times; I know that more than once I've dropped everything I'm working on to answer a support engineers question or a sales-related crisis. A more even distribution of opportunities for customer involvement, by creating an internal "SLA" for responding to inquires, and rotating the role of First Responder might help further 2 of our goals.

Most of the time, @phikai handles incoming requests, but there's also technical inquires and MRs that get passed to us, and with a large percentage of the company and customers being in NA timezones, it often falls on @garyh and I to answer. Now, again, I certainly don't mind, but it does keep others from having the opportunity to respond and have involvement in these usually customer-focused inquiries.

So.. I'm proposing here 2 things - an explicit statement of how we as a group will handle these queries, and sketches out a rough idea for how we can distribute the opportunities more equitably across the team. This might not be the best solution, but I wanted to float it for discussion.

This is very much a draft to start a conversation. What do you think? Do you miss using Zendesk and trying to hypothesize about what the heck a customer did to get an MR into a given state? Is it even a problem that we need to address?

Author Checklist

  • Provided a concise title for the MR
  • Added a description to this MR explaining the reasons for the proposed change, per say-why-not-just-what
    • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added.
  • Assign reviewers for this change to the correct DRI(s)
    • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the "Maintained by" section in on the page being edited.
    • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies.
  • If the changes affect team members, or warrant an announcement in another way, please consider posting an update in #whats-happening-at-gitlab linking to this MR.
    • If this is a change that directly impacts the majority of global team members, it should be a candidate for #company-fyi. Please work with internal communications and check the handbook for examples.
Edited by Kerri Miller

Merge request reports