The GitLab Support Team may very well be unique among the many teams within the company in that its multiple sub-teams each have the same charter. Making decisions and managing change within this structure come with equally unique challenges not faced by the other teams. Specifically, managers must determine the appropriate scope - whether to act individually or in coordination with the other managers - when they want to make a decision or introduce a process change. And the worldwide support management team must agree that the scoping is correct. We define here our most current processes for determining scope, gathering data and feedback, choosing a path forward, rolling out a change, managing adoption, and reviewing results for future improvements.
If you have an idea but aren't ready to propose a change yet, you can start with the Request for Comments issue template. The template includes guidance on how to make your RFC.
One of the most important considerations when looking to make a change is what the scope of the change will be.
When thinking about whether a change should be local or global, you might be tempted to focus on the size of the change (number of lines of code changed, number of lines of text in a doc that changed, etc.). But that’s actually a different type of scope that isn’t relevant to this discussion.
Instead, begin with the idea that for the sake of consistency and simplicity, you should lean toward making your change globally unless it doesn't even make sense for, or apply to, other regions. If you're considering making the change locally, be sure that you can answer "no" to all of these questions about potential impacts of making a local change:
Whether you’re making a local change, based on the decision criteria above, or proposing a global one, it’s important to communicate your plans with the rest of the Support Leadership Team.
The first step toward making a change is to create an issue via the support-team-meta project. Using the linked template (Request Change), it will ensure you supply the required information (DRI, problem statement, ways to measure success, etc.), helping to speed the process along.
The first step in constructing your change proposal is to create an issue or a MR to describe your proposal and invite discussion.
Until you know what change you are proposing, and so can open a MR, use an issue for presenting the problem that you are working to solve and for hosting a discussion around that topic. An issue is especially useful during the testing phase.
As soon as possible, create the MR(s) to present the actual proposed changes. Include at least the following in the MR:
NOTE: If there's any part of the proposed changes that cannot be presented through a MR, place the information in the issue instead.
Even for a change that you’ve determined will be local, inform the leadership team. Put it as an “inform” item in the agenda for the next leadership sync meeting. Why?
Once you’ve determined that your intended change must be global, engage the leadership team in a conversation through your issue and through a full agenda topic in the leadership sync meeting:
We make data driven decisions whenever possible. If your proposed change doesn't have any supporting data, you'll run one or more localized trials. Be frugal if there is a cost and always be sensitive to disrupting existing workflows:
For future iterations:
Do we want to have standard timelines for certain steps in a rollout?
During the rollout, use these terms and their provided descriptions to communicate clearly about the different roles people can play in the change process.
| Role | Description |
|---|---|
| Champion | Person who will advocate for the change due to their strong interest in, and possible responsibility for, the success of the change. Most of the time champions are managers. |
| User | Person who use the processes, documents and resources that are being changed. |
| Impacted Non-User | Person who is not an actual user of the processes, documents and resources that are being changed, yet who will experience changes in the behaviors of the users. E.g. Support Engineers may notice managers responding differently to escalations, though they themselves do not need to do anything new. |
When it's time at last to make the change, create a Process Change Rollout Plan issue. The process change rollout plan template contains instructions to guide you through filling in all the appropriate details. And the issue itself then describes your full action plan.
