Internal communications is the connectitive tissue that keeps everything and everyone in the company moving forward in the same direction.
We aim to bring team members along on the journey through storytelling, empowering team members to become GitLab ambassadors and we seek input from across the company to continually iterate.
This page defines how our Internal Comms program operates.
Given the amount of information we need to communicate with GitLab team members around the world it's important that we have a structured approach to communication.
In preparing key messages to be shared with all team members, we ask all parts of the business to follow the process below:
We use a variety of channels to communicate with various audiences within GitLab. The top channels we use and the purpose of each of these channels is as follows.
Timing of various messages and internal campaigns, and having a solid plan is a key to successful communication. As a company that's in growth mode, change is contant and we have a lot that needs to be shared with team members.
We plan when messages and campaigns will be live internally by maintaining an internal communications editorial calendar.
Given this calendar tends to include information that is confidential until it's shared, it is not published here, but available for GitLab leaders looking to understand what is planned for a given week, month, or quarter.
Beyond timing, we want to be intentional about what we share with team members. Choices made about the weight of different themes we decide to highlight will have an impact on our culture. We use the general guideline below to guide our prioritization during normal times.
Content topic | Percentage of Internal Share of Voice |
---|---|
Team member total rewards and program updates (Primarily Finance & People Group) | ~30% share of voice |
Values, culture, and team-building content | ~20% share of voice |
Leadership updates about key projects and functional changes | ~20% share of voice |
Business outlook / Product updates | ~20% share of voice |
Reactive, unplanned messaging (we know it happens!) | ~10% share of voice |
It's important that we consider how information will be received by various sub-groups within GitLab before sharing a piece of information with all team members. A typical cascade of information may end up crossing through various channels in cases where a significant change is being introduced.
For example, if we were announcing a big, exciting new program we might cascade information as follows:
It's important to note that information cascading could be seen as lacking transparency. That's not the case, rather it allows for managers and leaders to keep people more informed as they will have a chance to understand key changes with enough time to then answer questions to their teams.
As we continue to grow our internal communications function, we'll continue to add more detailed information to this page. Please offer feedback by suggesting edits to this page or reaching out in the #talent-brand-engagement channel on slack.