Communities of Practice are self-organized, cross-functional groups of Subject Matter Experts (or aspiring to be!) within the CS organization dedicated to a topic within GitLab or the broader DevOps space. The goal is to build assets, best practices, demonstrations, and share experiences we learn from prospects and customers. In turn, CoP will build broader technical depth within our CS organization to better advise our customers and influence our product roadmap.
The content and assets are aggregated into a single group to maximize discoverability. Each Community of Practice has a project which contains a Readme of links and an issue board for discussion.
Roles and Responsibilities
Assembles the group, runs the meeting, and maintains the project
Any subject matter expert. Participates in meetings, provides input, and contribute to the resources
Any Team member who engages with the CoP group SME should try to contribute back - such as providing a deck or recording where the information gathered was utilized.
CoP should consist of three or more members to foster a culture of collaboration.
Time commitment can vary depending on involvement, but the expectation is 3-5 hours a month for active members.
CoP can be managed through Async communication, but the core team should meet once a month to ensure content is maintained and updated.
Participating in a Community of Practice
Anyone can establish or participate in an existing Community of Practice. Below you will find the active ones. If you are interested in starting a new one, please follow the process outlined below.
There are reoccurring topics from prospects and customers that could be a good fit for a CoP. If you are looking to build a new CoP but unsure what would be most impactful, this is an excellent place to start!
Windows Development and Automation
Establish a focus topic.
Enlist GitLab team members to participate in your new CoP, utilize the #customer-success channel in Slack to reach a broad audience. Make sure to point them to the process outlined on this page, so they understand the commitment.
Update this handbook page under the table "Active Communities of Practice."
Setup a slack channel using the #cp_ prefix, so team members know where to go for help.
How can I ensure my Community of Practice is effective and impactful?
A Community of Practice does not have a specific timebox; it's an ongoing process that should evolve. Here are some useful methods to follow and review regularly:
Selecting a Topic
Select something you are excited or interested in - not just what is "needed."
Select a topic that is broad enough that it can evolve and expand over time. (i.e., "Cloud-Native" would be more impactful than "Helm Deployments")
Research the impact on GitLab and the broader team. i.e., Are there any issues on the GitLab Issue tracker related to this topic? Are there industry trends around this topic?
Measuring Health and Success
It's important to reflect on the group to measure if it's successful and healthy. Here are some suggestions on how to measure:
Individual: Has the community helped individuals become more knowledgable on the topic and expand personal or career growth?
Team: Has the CoP provided the broader team with meaningful assets and depth on the topic? Has the group engaged the CoP members to participate in customer conversation as an SME?
Product: What impact has the CoP had on GitLab product roadmap or strategy?
Customer/Prospect: has the CoP enabled us to be thought leaders on the topic or more impactful trusted advisors?
Including New Members
Communities of practice are not just for GitLab and Customer Success, but personal growth and career development. It's essential that our CoP is open and inclusive to all people - not only those who have expertise on the topic.
Encourage team members to get involved at any point, not just when the CoP is established. It will be natural for members to join and leave over time.
Archive when necessary.
CoP's are community-driven, and for various reasons, they may decline in participation, so the content becomes stagnant or outdated. If you are a facilitator of the group, check with the team if anyone else wants to take ownership. If not, it's best to archive the group for historical purposes rather than let it linger out-of-date, which could send other team members down the wrong path. In the future, we will add a table on this page for "archived communities."
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license