People communications & team member engagement

Our approach to communications and team member engagement at GitLab

Introduction

“Internal communication” is the connective tissue that keeps everything and everyone in the company moving forward in the same direction. It’s a broad term and is an aspect of our culture that every team contributes to in some form.

The People Communications & Engagement team aims to keep team members informed and engaged through compelling internal storytelling and timely information sharing to empower team members to become GitLab ambassadors.

This page defines how our People Communications & Engagement team operates to support GitLab team members and various cross-functional teams within GitLab.

Guiding principles

  • 👁 Be credible, transparent, open, and honest
  • 🤝 Provide context, reason, and a call to action.
  • 📈 Be consistent on delivery, cadence, and tone.
  • ⏱ Respect people’s time and attention.

People Communications & Engagement Objectives

  • Increase team member engagement and company advocacy through compelling storytelling and timely information sharing
  • Empower team members to become advocates for our talent brand by connecting business updates with our values, mission, and purpose
  • Drive team member engagement by creating a variety of touchpoints to meet team members where they look for information
  • Instill operational rigor into our cross-functional change management processes
  • Increase trust and connection between leaders and team members

GitLab team members can better understand how communication and engagement work together by reviewing our Engagement Strategy presentation.

Working with People Communications & Engagement

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 & engagement so team members are provided a full view of things happening across GitLab.

There are several different ways our People Communications & Engagement team can support cross-functional projects depending on the need. These include:

Type of involvement What this type of involvement entails How People Comms & Engagement can support
Review of communications The most basic level of support provided is a review of planned communications, typical lead time is 48 hours This means reviewing a single message or series of messages for tone and format, alignment with communication principles, cascade of information, and appropriate channel use
Collaborative communications planning This is a partnered approach on the creation of a message or a communications plan anticipated to impact a significant amount of team members or have a high impact to a select amount of team members, typical lead time is 1-2 weeks depending on bandwidth For projects with a defined DRI outside of the People Communications & Engagement team, we will often work together on a collaborative comms plan by reviewing and editing copy, reccomending channels, cascade of information, and communications best practices
Accountable for communications For project with change management complexity or a large communications component, we look to establish a comms DRI to be accountable for communications, typical lead time is 3+ weeks to understand the project and advise This means writing communications, getting neccesary stakeholder input, aligning to our typical template for leadership review, plus everything we would typically do for a review of communications
DRI for communication-based projects Often times an entire project may sit with People Comms & Engagement (i.e. a large cultural shift like a Value change, changes to a major policy) In these cases someone from the People Communications & Engagement team leads a cross-functional project team to deliver a defined piece of work

Depending on the level of support needed for a given project, the person assigned to that work from the People Communications & Engagement team can advise on process, standard templates and practices used, and suggest best practices for communicating at GitLab.

If asking for communications to lead communications when preparing key messages to be shared with all team members, we ask all departments to follow the process below:

  1. Share the need for communications support by completing a request for internal communications support template as completely as possible and share the need with a member of our People Communications & Engagement team.
    • These requests can be shared on Slack using the #internal-communications-requests channel, or if confidentiality is a concern, please connect directly with:
    • Kayla Golden, Senior Program Manager, People Communications & Engagement
    • Devin Rogozinski, Senior Director, Talent Brand & Engagement
  2. Upon receiving the project brief, our People Communications & Engagement team will socialize the need with the #comms-asks channel to determine who will be a DRI or partner from the People Communications & Engagement team or the broader talent & engagement team assigned to the project.
  3. A communications plan including release timing, cadence, and appropriate channels will be developed.
    1. At least ~48 hours advance notice is needed to plan a single message being shared
    2. For more complex internal communications requests, we request at least ~7-10 business days advance notice to effectively collaborate together on a communications plan. We will opt to move more methodically depending on the scope and timeliness of the communication.
  4. To expedite this process, you can create an initial communications plan using this template.
    1. Once you have created the initial communications plan, share it with the People Communications & Engagement team on Slack using the #internal-communications-requests channel, or if confidentiality is a concern, please connect directly with:
      • Kayla Golden, Senior Program Manager, People Communications & Engagement
      • Devin Rogozinski, Senior Director, Talent Brand & Engagement

People Communications & Engagement channels

We use a variety of channels to communicate with various audiences within GitLab. The top channels we use, the purpose of each of these channels, and how everyone can contribute to each is as follows.

  1. “While You Were Iterating” Newsletter… Communicating new updates that are important for all team members to be aware of on a twice a month basis.
    • 🤝 To contribute: Write a comment in the most current newsletter GitLab issue and tag @kaylagolden. Things to note when sending over content:
      • Is it globally relevant to more than 75% of GitLab team members?
      • Is this something all team members should know about and/or action?
      • Does it align with our GitLab values?
      • Make sure there is a team member action included
      • Send over a 1-2 sentence draft description of your content. If necessary, include additional context for internal comms team’s background and knowledge - this is helpful when reviewing and finalizing the messaging.
  2. Manager README Monthly Newsletter: Monthly proactive communication to people managers containing: what’s coming up, reminders of what’s important, guidance on team member talking points and what actions to take
    • 🤝 To contribute: Write a comment in the most current manager comms GitLab issue and tag @kaylagolden. Things to note when sending over content:
      • Is it globally relevant to more than 75% of GitLab People Managers?
      • Is this something all people managers should know about and/or action?
      • Does it align with our GitLab values?
      • Make sure there is a people manager action included
      • Send over a 1-2 sentence draft description of your content. If necessary, include additional context for internal comms team’s background and knowledge - this is helpful when reviewing and finalizing the messaging.
  3. All-team-member Slack channels (#company-fyi and #company-fyi-private): Timely important and action-oriented important updates to all team members
    • 🤝 To contribute: Read the Internal Comms Tiered System to determine if your message falls into Tier 1a/1b which would signal a #company-fyi or #company-fyi-private message. If that’s the case, create a copy of and complete the request for internal communications support template and share on Slack using the #internal-communications-requests channel, or if confidentiality is a concern, please connect directly with @kaylagolden.
  4. GitLab Handbook: For permanent and non-confidential updates, we consider how information should live in the GitLab Handbook.
  5. GitLab Assembly: All-company synchronous time to hear from GitLab leaders and answer team member questions
    • 🤝 To contribute: Content creation is determined by the People Comms & Engagement Team with review by members of the E-Group.

GitLab Assembly

GitLab Assembly is our quarterly all-company meeting and is an opportunity for team members to hear from leaders and teams across the company. Assembly provides a holistic view of top priorities, customer stories and data, cross-collaboration, department deep dives, and other team member stories to bolster team member engagement, shared visibility, and company connectedness. Assembly is a 50-minute meeting consisting of ~35 minutes of content and ~15 minutes of Q&A and is scheduled to take place late in the second month or early in the third month of each quarter (January, April, June, October). To give global team members an opportunity to join live, there will be two live-hosted Assembly events each quarter, with the first event at 5pm PT (12am UTC) and the second event the next day at 8am PT (3pm UTC).

To produce each quarterly Assembly, the People Communications & Engagement DRI:

  1. Works with the EBA team to schedule a date six to eight weeks in advance
  2. Engages a production partner for the live event production
    • Collaborates with the production partner on run of show
    • Coordinates with the production partner on pre-records
    • Meets weekly with the production partner for the 6 weeks leading up to Assembly
  3. Creates the agenda and sends out the Assembly calendar invites to all team members three to four weeks in advance of Assembly
  4. Creates the event in Slido to open question submissions prior to both Assembly events
  5. Partners with Functional Leaders on top-of-mind topics, and proposes a host, speakers, and segments
  6. Facilitates and secures People Leadership reviews and approvals of proposed host and topics
  7. Works with the CoS and CoS team to:
    • Determine CEO presentation specifics
    • Align on CEO key messages and themes to present
    • Schedule and attend feedback sessions with the CEO
  8. Partners with the host and additional speakers on their presentations
    • Determines presentation specifics
    • Drafts content or delegates additional team members to draft content as needed
  9. Partners with the production partner on the Assembly presentation deck and secures:
    • People Leadership review
    • Marketing and Design review
  10. Engages with the internal Digital Production team and the production partner to secure resources for editing pre-recorded video content
  11. Records the CEO presentation and facilitates the recording of any additional pre-recorded content
    • Uploads to Google Drive for the Digital Production team to access as needed
    • Adds video timestamp transitions for the Digital Production team
  12. Facilitates and secures final review and approval of video content and Assembly presentation deck by:
    • Host and speakers
    • People Leadership
    • Legal
  13. Facilitates a final technical check/dress rehearsal for the production company, host, and live speakers

On the day of Assembly:

  1. Assembly host, speakers, and E-Group join a separate speaker Zoom that is broadcasted to the all-team-member Zoom 15 minutes prior to the event start time for event one and 5 minutes prior to the event start time for event two.
    • Speakers are asked to keep their camera on and microphone muted (until time to speak) for the entire duration of the meeting. They will not be shown at all times, but toggling on and off cameras in the speaker Zoom can impact the live production.
    • Speakers and production team will be joined in the speaker Zoom by one member of the People Communications & Engagement team.
  2. The People Comms & Engagement DRI joins the all-team-member Zoom to facilitate any team member needs. The production company broadcasts the event countdown and facilitates the waiting room.
    • The chat from this Zoom will be backed up for reference.
  3. At each event start, the host begins leading the meeting once the countdown is complete, and moves through the event run of show.
  4. Team members are encouraged to submit questions to the Slido event and upvote questions they would like to see answered.
  5. At Q&A, the Host reads questions aloud in up-voted order.
  6. E-Group works collaboratively on a Q&A document to facilitate who will respond to each question.
  7. An assigned scribe tracks Q&A directly in the agenda document.

After the second Assembly event:

  1. The production partner shares the recording for both Assembly events with the People Comms & Engagement DRI.
  2. The People Comms & Engagement DRI shares the Assembly recording with the Learning and Development team to upload to Level Up.
  3. Once uploaded to Level Up, the People Comms & Engagement DRI shares final recording and any needed follow-ups with all team members in the next issue of the all-company newsletter, While You Were Iterating.
  4. The People Comms & Engagement DRI/team requests feedback from team members, People Leadership, and E-Group post-Assembly.

People Communications & Engagement Planning

We operate an internal communications editorial calendar (confidential to a small internal group) with key company-wide announcements, campaigns, and events. To get added to this list, please review the Internal Comms Tiered System to determine if your message falls into Tier 1a/1b which would signal a #company-fyi or #company-fyi-private message. If that’s the case, create a copy of and complete the request for internal communications support template and share on Slack using the #internal-communications-requests channel, or if confidentiality is a concern, please connect directly with @kaylagolden.

Planning large-scale communications & engagement efforts across multiple channels

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 constant and we have a lot that needs to be shared with team members.

We operate as a lean team and due to limited bandwidth, we are unable to service all communications fully. Please review the Internal Comms Tiered System to understand how and what type of communications we can assist with.

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

Your role in keeping GitLab team members engaged & informed

Everyone plays a role in keeping GitLab team members engaged and informed. If you’re partnering with the People Communications & Engagement team, please keep these best practices in mind:

  • 📈 Take ownership of your subject matter expertise: If you’re requesting something be communicated to team members, it’s likely that your expertise on the change will be key, sharing as much as possible about a given change will be helpful.
  • 🤝 Give feedback effectively and assume positive intent: Collaborating asynchrounously can require a few back and forths before there’s alignment, that’s expected.
  • 👣 Set a due date and embrace iteration: Understanding when something is needed or if there’s a different priority for a given piece of work helps us to prioritize.
  • 👁 Say why, not just what: Whether giving feedback or briefing in a need, add as much “why” as possible.

Cascading information to various groups within GitLab

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:

  1. E-group provides input and feedback
  2. People Group provided visibility to plan for team members questions
  3. Managers receive information to ensure there is time to digest (#people-managers-and-above and Manager README)
  4. All Team members receive the information with their managers and leaders already well-versed on the change (#company-fyi or #company-fyi-private and “While You Were Iterating…” newsletter)

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.

Runbook for contentious internal announcements

We have a runbook for internal announcements that could lead to heated conversation or disagreement among team members. It includes these steps:

  1. A DRI will inform @devinrogo that there is a need for a company-wide communication. The DRI will be resonsbile for drafting the communications using this internal communications announcement template. This will include, at a minimum:
    1. Who is responsible for posting
    2. Where the message will be shared
    3. When the message will be optimally be shared
    4. Main messages to be communicated and message content
    5. An activity and communications timeline that includes key participants and their responsibilities. It will specify any planned follow up in the minutes, hours, and weeks after the initial communications. This should include:
      1. Who will be on call to respond in Slack or other channels immediately after an announcement, including coordinated leadership participation. Key leaders, including members of E-Group and often members of VP-Directs Group, should be aware of when an announcement will happen and the response expectations for them. For example, if there is a contentious Slack announcement, a designated group of people should be monitoring the thread and responding immediately after the announcement.
      2. Any AMAs or other designated plans for discussion or follow up communications
    6. Who is required to sign-off on the message and plan
    7. The desired timeline for sign-off
  2. The DRI will share the draft communication with the Executive Sponsor and any other key senior stakeholders. If there are any questions around what can SAFEly be shared, the CLO or another legal representative should be included in the review.
  3. Both legal and corporate comms should review planned communications of this nature as well with the appropriate stakeholders from each team identified in the comms plan.
  4. Once the Executive Sponsors and Key Stakeholders are in agreement on the comms and plan, it should be shared with all of E-Group in #e-group-confidential or in the E-Group Weekly as a discussion item. Plan feedback should be incorporated.
  5. If applicable, once the plan has gone through E-Group review, it should be shared with the B.V. Netherlands Works Council and any other councils that have review rights. When possible, this should be done at least two weeks before a planned announcement to allow adequate time for review and feedback.
  6. When possible, share with managers in advance (1-2 days before a broader announcement) and ask for their support in following up with their teams. We should be clear on how we expect them to support (answer questions, cascade info, manager mention, etc.)
    1. When sharing announcements with the manager community, MR’s may be staged in document form to allow for changes and clarification prior to sharing the MR with the broader team member community.
  7. If the post includes a merge request (MR), we should ensure that we are following MR best practice before we post.
    1. If discussion is happening in an issue, we can ask for manager mentions.
    2. MRs should not already be merged. Team members should be invited to share feedback on a change and be clear on the intended merge timeline.
    3. We shouldn’t use separate MRs for removing and adding content. This makes it harder for team members to track changes.
  8. After a communication is shared, there should be a placeholder for the Executive Sponsor and designated team to connect synchronously to review feedback and (if agreed upon) respond. A calendar hold should be placed on the calendar for 25 to 50 minutes after the communication.
  9. A similar Executive Sponsor and designated team check in should be scheduled for the following day. This meeting can be canceled if it is agreed that it is not needed.
  10. If there will be an AMA or other synchronous touchpoint with team members, the Executive Sponsor or designated team member can choose to schedule a meeting shortly before the session (optimally 1-2 hours before), so participants can align on their roles and their plan for communication.

This runbook outlines key steps to be followed. Additional steps may be added based on the communication and level of coordination required.

More to come

As we continue to grow our People Communications & Engagement 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.

Last modified April 9, 2024: Updating table formatting (e5cdd8bb)
View page source - Edit this page - please contribute. Creative Commons License