GitLab Strategy and Operations (Workplace) Team Handbook

GitLab Strategy and Operations (Workplace) Team Handbook

About the GitLab Strategy and Operations (Workplace) Team

The GitLab Strategy and Operations (Workplace) Team evolved from the All-Remote Marketing team. It is responsible for:

  1. The creation, curation, and continued iteration of GitLab’s guide to all-remote, a deep library of guides that covers every facet of how GitLab functions as a remote team.
  2. Stewarding, iterating, and evangelizing GitLab’s management philosophy and people practice, TeamOps.
  3. Building an overarching methodology for the modern workplace.

This page is the single source of truth for TeamOps and all-remote positioning, evangelism, approvals, vision, and strategy.

Mission Statement

The mission of GitLab’s Strategy and Operations (Workplace) team is to define, evolve, and scale TeamOps. We also evolve and champion the company’s all-remote culture.

This involves close collaboration with GitLab’s CEO and Chief of Staff; Corporate Marketing (PR, corporate events); People Group (employment branding) and Diversity, Inclusion & Belonging.

All-Remote Flywheel

The All-Remote Flywheel is focused on continually evolving and refining GitLab’s all-remote environment (e.g. tooling, approach to meetings, collaboration, and communication, total rewards/compensation) in order to drive stronger brand awareness, marketing potential, and thought leadership. If our organizational design principles continue to stay ahead of the curve, we’re able to lead marketing conversations on all-remote and the future of work. This also drives happier, more efficient team members, and impacts elements such as time-to-hire and team member retention.

Strong all-remote marketing may bolster industry trust in the GitLab brand and product due to the halo effect. E.g., If The Remote Playbook inspires a firm’s remote transition blueprint, said firm is likely to show favoritism to GitLab’s product offerings and services.

graph BT;
  id1(Savvier Operations)-->id2(Stronger Marketing);
  id2(Evolving/Refining All-Remote Operations)-->id3;
  id3(Happier, More Efficient Team Members)-.->id1(More Users);
  id1(Stronger Marketing of All-Remote Leadership)-.->id4(Improved Team Member Acquisition and Retention);
  id3-->id1;
  id4(Greater Trust in GitLab Brand/Product)-.->id5(Improved Team Member Acquisition and Retention);
  id5(Improved Team Member Acquisition and Retention)-.->id3;

Vision

GitLab is an influencer and educator in remote work and people operations. It serves the community by creating valuable content that furthers the proliferation and ubiquity of remote-first and all-remote organizations, while enhancing the operations of colocated and hybid-remote companies by sharing implementable remote-first practices.

We believe that the people practice and [operating principles]({{ ref “values#operating-principles” >}}) relied on by GitLab are applicable even to colocated companies, and educating on pillars such as asynchronous workflows and informal communication can benefit all organizations.

Goals (OKR)

Follow our work and collaborate in the TeamOps Q4-FY23 Epic.

The team’s KR is defined within GitLab CEO’s OKR.

In Q4-FY23, our KR is: Certify at least 100 GitLab team members and 1 person in each department as TeamOps Trainer: Level 1

TeamOps Trainer

TeamOps is how GitLab works. It is an operations model that helps teams maximize productivity, flexibility, and autonomy by managing decisions, information, and tasks more efficiently.

TeamOps Trainers are team members who are internal champions of GitLab’s values, operating principles, and ways of working, inclusive of all functions and departments. They aspire to mentor and share with others GitLab’s ways of working, both inside and outside of the organization.

A TeamOps Trainer transitions through three stages of TeamOps understanding. 1) Recall => 2) Apply => 3) Teach

In Q4-FY23, we are hosting TeamOps Trainer Pilot Workshops.

The purpose of the first version of this program is to collect feedback and resources as part of a larger go to market strategy, including:

  • Focus Group – Content testing, feedback, and iteration as beta test before TeamOps is released to the public market with a more formal sales strategy.
  • Content/Model Prototyping – Test the viability of creating a network of TeamOps representatives for future phases of TeamOps growth. (“Train the Trainer”)
  • Content Creation – Scale content related to TeamOps by empowering all of GitLab to contribute blog posts and social threads.

Creation of and participation in this program also supports the FY23-Q4 OKR to Grow Careers of GitLab team members.

Apply to become a TeamOps Trainer and learn more about the program in this GitLab issue.

Requirements for TeamOps Trainer: Level 1

  1. Complete the TeamOps practitioner course
  2. Be able to answer questions (interview by existing trainer)
  3. Enthusiastic presentation of about 3-5 minutes on advantages of TeamOps on YouTube (GitLab Unfiltered)
  4. Contribute proposals to the materials (1+ MRs) on iterating TeamOps content to be market-ready (e.g. more applicable to your specific team or function)
  5. One blog post (or similar) published on GitLab, LinkedIn, Medium, Twitter thread, etc.

Evangelism Materials

GitLab all-remote team

Anyone can be a remote evangelist! Help yourself to these materials for your presentations, blogs, and consultations.

Remote Work Essentials

We’re often asked to share how GitLab thrives as an all-remote team. Here are the foundational resources you can share to start the conversation:

In scenarios where you need a quick link to vocalize, tweet, email, or otherwise share, we have established a memorable redirect: https://allremote.info/ ("All Remote Dot Info")

Why remote?

GitLab’s overview video on its all-remote culture can be viewed here.

Presentations (slide deck)

GitLab’s Workplace team collaborated with Brand and Corporate Communications to create a TeamOps Presentation Template on Google Slides, entitled Making Teamwork an Objective Discipline. Please make a copy of this presentation to edit photos and names, personalizing it to your specific need.

You may be asked to give a presentation on how GitLab works as an all-remote team, including requests that are specific to your role (sales, engineering, finance, people, etc.).

In these instances, you’re welcome to use this Google Slides presentation, Managing a Thriving Remote Team: A foundational toolkit. (This link is only viewable by GitLab team members.) A suggested script following this presentation is available for your use.

For a video of GitLab’s Head of Remote walking through this presentation to a group of founders, click here. This presentation will serve as a guide to narrating the slides and connecting GitLab’s approach to remote with the current reality of your audience.

Expand this section for more slide decks you can use.

Usage guidelines:

  1. Please make a copy of the presentation and script instead of overwriting the template.
  2. Swap out existing names/headshots for your own.
  3. Feel welcome to add a slide or two related to the specifics of the request.

Teaching other companies how to go remote

For a glimpse at how GitLab’s Strategy & Operations (Workplace) team speaks about remote through presentations, watch the embedded video above or visit the GitLab Unfiltered (YouTube) links below. These presentations were shared at GitLab Connect EMEA in March 2021.

  1. Remote Teamwork: How to thrive in a post-office world
  2. Making Remote Work

GitLab is unique in that every single team member is remote. All-remote is the common thread that we all share, regardless of what department we serve. This means that each GitLab team member is uniquely equipped to share best practices with other leaders and companies.

The requests may be varied, from small firms looking to unwind their office strategy and go all-remote, to multi-nationals which are looking to implement remote-first best practices to account for more of their team working outside of the office (or in different offices).

Top questions from suddenly or newly-remote companies

It is useful to empathize with those you speak with. GitLab is a very advanced remote work environment, making it all the more important for team members to understand alternative baselines and speak to other realities, all while forecasting what's possible if an organization invests in remote-first principles today.

Below are the most common questions asked by suddenly or newly-remote companies, linked to relevant handbook pages that you can study prior to presenting. These shed light on their challenges, and will help you proactively speak to common needs, misconceptions, and struggles.

  1. How do you maintain and build company culture in a remote work environment?
  2. How do we maintain and build new work relationships without seeing each other in-person on a regular basis?
  3. How do we prevent burnout, isolation, and mental health crises?
  4. How do we combat Zoom fatigue (e.g. exhaustion associated with nonstop video calls)?
  5. How we do handle compensation changes if people permanently relocate to work remotely?
  6. How do we ensure that employees are productive when we cannot physically see them?
  7. How does one become a great remote manager?
  8. How do you effectively lead remote teams?
  9. How do you onboard and train/educate remotely?
  10. How do you collaborate and whiteboard remotely?

Key Points to Cover

Regardless of the nuance in the request, here are the foundational areas that should be covered. Be sure to describe how GitLab implements these tactics using low-context communication, leaning on examples and detail such that a non-GitLab company can envision how such a tactic could be useful in their own organization.

  1. Forced work-from-home isn’t remote work. In speaking with suddenly or newly-remote companies, preface everything with the following sentiment: Forced work-from-home, triggered by external factors such as a global pandemic, is not the same as intentionally designed remote work. It is vital to disentangle the two concepts. The stress one feels from working at home with no preparation — possibly with a significant other also working from home while juggling childcare or virtual schooling — is more closely linked to life during a pandemic than it is remote work.
  2. Set the stage. GitLab is the one of world’s largest all-remote companies, which is why our advice matters.
  3. Remote requires a different mindset. All the tools and processes in the world will falter if leadership doesn’t lead with trust and transparency rather than micromanagement and fear.
  4. Lead with data. GitLab’s Remote Work Report surveys thousands of global remote workers. As leaders and team members grapple with going remote, this report provides insights on what matters to those who adopt this way of working, charting a path for building culture around autonomy and flexibility.
  5. Remote-first practices aren’t just for remote companies. Empathize with challenges. Offer up common issues that teams who are going remote will face. Although GitLab is all-remote, we should make clear that our advice applies to colocated companies and hybrid-remote companies as well.
  6. How do I manage a remote team?
    • What tools do we need?
    • How much communication is too much?
    • What is in charge of our remote transition?
  7. Guidance is about the here-and-now, but approach this for the long-term.
    • Recognize that companies forced into work-from-home need communication gaps filled now.
    • The reason to do this with intention is that it will become a core part of a company’s talent and operational strategy.
    • Remote de-risks a company, making it less susceptible to socioeconomic swings and crises.
  8. Three biggest challenges!
    • Workspace challenges and work/life separation.
    • Communications in a remote world, and keeping everyone engaged/informed.
    • Mindset and culture, leaning into the reality that change takes time, and a focus on iteration.
  9. How does GitLab do it?!
    • This is your moment to showcase specific examples of how GitLab does things differently. If you are addressing an department-specific audience (sales, engineering, HR, finance, etc.), surface examples germane to that audience.
    • Feel welcome to share that GitLab uses GitLab. It’s a tool built by an all-remote team to enable remote practices such as asynchronous workflows and prevent typical challenges such as communication silos.
    • Share our GitLab for remote teams solutions page.
    • Prepare for minds to be blown. These things feel like second nature to GitLab team members, but are revolutionary to most.
  10. You must have a single source of truth
    • It’s not about blanket documentation. It’s about working handbook-first.
    • Start now! Designate a scribe if you have to. Start small, as an FAQ, and build it out.
    • Show an example of a handbook page — a great example is our Communication page.
  11. Asynchronous over synchronous
    • Explain how GitLab requires each meeting to have an agenda and someone documenting.
    • Explain how meeting takeaways then need to be contextualized and added to relevant handbook pages.
    • Explain how this added burden on meeting is a forcing-function to work first in GitLab, and rely on a meeting as a last resort.
  12. “OK, but where do we start?”
    • Start small, don’t be overwhelmed. Get your executives out of the office and have EA’s document the communication gaps that emerge. (Hint: That’s your priority list of what voids to fill.)
    • Establish a team responsible for communication. Everything that comes next requires clear, frequent, transparent communication and an understanding of where to communicate and who are the DRIs for various functions.
    • Provide a feedback mechanism. It’s impossible to know everything, so ask your team members what’s missing in their remote approach. Prioritize those asks as you see themes forming.
    • Remind people that GitLab has two Getting Started guides: one for leaders/companies, another for workers.
  13. Minimize your tool Stack. The fewer moving pieces when transitioning to remote, the better. GitLab (the product) is at the heart of our workflows.
  14. “But wait, I still need help!” Fret not! GitLab’s entire library of remote guides are available at https://allremote.info/ ("All Remote Dot Info")

In case you as a subject matter expert are invited to write an Unfiltered blog post or create other written content, please feel free to make a copy of the “Going remote in ____” blog post template and tailor based on your audience.

More examples of how to talk about remote work

If you're looking for examples of the GitLab team describing our experience with remote work, have a listen at the podcasts below.

‘How to Manage a Remote Team’ course on Coursera

Mention in panels and consultations that GitLab’s expertise in managing a remote team can be digested as a free course on Coursera.

The course, titled “How to Manage a Remote Team,” provides a holistic, in-depth analysis of remote team structures, phases of adaptation, and best practices for managers, leaders, and human resources professionals. It is being offered free of charge, with an optional paid certificate available.

GitLab Remote Work Foundation Certification

Anyone in the world (yes, this includes those who are not employed by GitLab) may take the GitLab Remote Work Foundation Certification and TeamOps practitioner certification to improve their remote fluency.

Social media assets and guidelines

This is the issue to get everything you need in order to evangelize remote work on your social media accounts. It includes:

  • Goals
  • Perspective
  • Hashtags to use
  • Topics to follow
  • Tips for writing your own posts
  • FAQ

How does a company create their own handbook?

GitLab all-remote team

Learn more in GitLab’s Handbook-First Documentation guide about how GitLab (the company) uses GitLab (the product) to build and maintain its handbook, as well as tools and tips for other companies who wish to start their own.

All-remote guide creation

GitLab’s growing library of remote guides is designed to be bolstered by new pages. Below is an overview of the process for adding a new guide.

  1. Check this GitLab Issue to ensure that your proposed guide isn’t already being scheduled
  2. If it’s a net-new idea, please put each new guide idea/topic in a new issue within Corporate Marketing
  3. Put Proposal: [NEW ALL-REMOTE GUIDE] as the subject
  4. Add the label mktg-status::triage
  5. Assign to @streas to evaluate and provide feedback

What’s the difference between an all-remote guide and a traditional GitLab handbook page?

See below for an A/B comparison of how an inward-facing GitLab handbook page is written vs. an external-facing all-remote guide is written.

Design and illustration assets

GitLab all-remote team

GitLab’s Brand and Digital Design team are building out images and illustrations to visualize all-remote.

This section will be refreshed upon completion of the FY23 remote work brand refresh.

Approvals

Any GitLab team member is welcome to offer 1:1 advice or consultations on remote work. If you’re asked to give a broader presentation or webinar to a group, private or public, please create a new issue in Corporate Marketing.

An example of these details in an issue can be found here.

Please be sure to wait for approval before you confirm, if possible. Review this guidance on speaking about GitLab before your engagement, and ask the Corporate Communications team if you have questions. (This document is only viewable by GitLab team members.)

Once you have done this, please share in the #teamops Slack channel.

The team will be available to help direct if you feel unprepared, or pair the creator of the issue with someone else on the GitLab team if there’s opportunity to add another layer of expertise (e.g. a DevOps expert, an HR expert, a Finance expert) depending on the company that’s requesting.

Other assets

The Remote Playbook by GitLab

The Remote Playbook by GitLab is our premier guide to understanding and implementing remote work. It has been downloaded over 150,000 times by leaders and teams across the globe.

GitLab Remote Work Report

GitLab’s Remote Work Report sheds light on the current reality of remote work during a critical time in its global adoption. As leaders and team members grapple with going remote, this report provides insights on what matters to those who adopt this way of working, charting a path for building culture around autonomy and flexibility.

For example, 86% of respondents believe remote work is the future and 62% of respondents said that they would consider leaving a co-located company for a remote role. Contrary to popular belief, we found that most remote workers aren’t digital nomads, and 52% are actually likely to travel less than their office working counterparts.

Work-from-Home Field Guide

The Work-from-Home Field Guide was co-created by GitLab and Herman Miller. It combines GitLab’s expertise on remote work and management philosophy with Herman Miller’s deep understanding of workspaces and design.

Remote Work playlist on GitLab Unfiltered

GitLab is a very transparent company. As such, our AMAs, webinars, and other conversations with team members and other companies are uploaded to a dedicated Remote Work playlist on the GitLab Unfiltered YouTube channel.

Universal Remote webcast playlist on GitLab YouTube channel

Universal Remote is GitLab’s weekly web show focused on helping teams transition to a fully remote world. The running playlist of episodes can be found on GitLab’s YouTube channel.

All-Remote on the GitLab blog

Our audience

The audience we aim to reach with our all-remote and workplace initiatives is both internal and external to GitLab. It closely aligns with our employment branding audience, and expands to cover key segments in the investor and business communities.

  • Venture capitalists
  • Entrepreneurs
  • Business founders
  • Talent, talent acquisition, and HR leads
  • Media (business, lifestyle, workplace, finance)
  • Educators and researchers
  • GitLab team members
  • Job candidates and future team members
  • The broader GitLab community
  • People interested in remote work
  • Executives, Managers and HR that are finding a need for resources to support a remote workforce
  • Educators suddenly needing to support remote teaching
  • Industry analysts
  • People suddenly working remotely

Key Messages for All-Remote and Workplace

GitLab all-remote computer

GitLab: The Remote Strategy

  • GitLab is an all-remote company. Hiring managers are able to find candidates not limited to tech hubs like San Francisco, New York or Boston.
  • When you can hire around the world, you can pay market wages and offer people an at-market or above-market wage while still reducing costs for the company.
  • Without office rent, an organization saves a significant amount of money. GitLab, for example, has experienced rapid growth and would’ve had to move offices seven times in the last few years. We save a significant amount of money on rent, utilities, office equipment, and additional team members to manage the office.
  • GitLab has grown from 350 employees at the beginning of 2019, to over 1,600 employees across 65+ countries and regions currently. We chose the all-remote structure so we can hire people irrespective of location and we’re able to find the most talented people in the world rather than within a commutable distance.

Best practices for managing teams and communications remotely

Managing your team

  • Prioritize impact over activity
  • Don’t require people to have consistent set working hours or say when they’re working
  • Don’t encourage or celebrate working long hours or on weekends
  • Encourage teamwork and saying thanks

Communication

  • Encourage people to write down all information
  • Allow everyone in the company to view and edit every document
  • Consider every document a draft, don’t wait to share until it’s done
  • Use screenshots in an issue tracker instead of a whiteboard, ensuring that everyone at any time can follow the thought process
  • Encourage non-work related communication for relationship building
  • Encourage group video calls for bonding
  • Encourage one-on-one video calls between people (as part of onboarding)
  • Host periodic summits with the whole company to get to know each other in an informal setting

Connecting to GitLab’s values of iteration and transparency

Iteration

  • We do the smallest thing possible and get it out as quickly as possible. If you make suggestions that can be excluded from the first iteration, turn them into a separate issue that you link. Don’t write a large plan, only write the first step. Trust that you’ll know better how to proceed after something’s released. You’re doing it right if you’re slightly embarrassed by the minimal feature set shipped in the first iteration.
  • This value is the one most underestimate when they join GitLab. The impact both on your work process and on how much you achieve is greater than anticipated. In the beginning, it hurts to make decisions fast and to see that things are changed with less consultation. But frequently the simplest version turns out to be the best one.

Transparency

  • Be open about as many things as possible. By making information public we can reduce the threshold to contribution and make collaboration easier. Use public issue trackers, projects, and repositories when possible.
  • An example is the public repository of our website that also contains our company handbook. Everything we do is public by default, for example, the GitLab CE and GitLab EE issue trackers, but also marketing and infrastructure.
  • Transparency creates awareness for GitLab, which allows us to recruit people that care about our values. It gets us more and faster feedback from people outside the company, and makes it easier to collaborate with them. It’s also about sharing great software, documentation, examples, lessons, and processes with the whole community and world in the spirit of open source, which we believe creates more value than it captures.

Connecting GitLab sellers to individuals

At times, our remote team members speak with GitLab prospects on joint media panels, interviews, webinars, etc. focused on the topic of remote work. If appropriate, the GitLab team member with the contact should consider introducing the prospect to the GitLab sales member. In order to make this connection to the GitLab seller (if it is not known to the All-Remote team member), the All-Remote team member should open an issue in the Field Marketing project and tag the correct regional Field Marketing leader.

Field Marketing will look up account ownership in SFDC (Salesforce.com) and make the connection between the GitLab seller and the All-Remote team member so they can establish next steps in connecting to the prospect. The All-Remote team member should also feel comfortable asking about account ownership in the #fieldmarketing or #sales Slack channels before opening an issue.

Channels

GitLab all-remote illustration

Web

The team’s primary home for publishing informational guides and content is the all-remote section of GitLab’s handbook. This will be the preeminent home to all-remote content, positioned for consumption by media, investors, prospective customers and candidates. This links readers to the guides that make up The Remote Playbook, as well as TeamOps. Future web experiences are being evaluated.

Video

GitLab is a very transparent company. As such, our remote-centric AMAs, webinars, and other conversations with team members and other companies are uploaded to a dedicated Remote Work playlist on the GitLab Unfiltered YouTube channel.

Events, panels, keynotes and webinars

All-remote and Workplace events should elevate GitLab as a thought leader in the remote work space, create new partnerships, generate leads and generate media interest/coverage. We will consider physical events, virtual events and events that combine an in-person presence with a livestream option.

We believe that all-remote is for everyone, and that almost every company is already a remote company. This includes all company sizes, from solo enterprises to multi-nationals, and geographies. Our event strategy should reflect this, offering education, insights, and actionable advice that applies to a wide spectrum of remote companies.

Events should create an inclusive atmosphere, welcoming and beneficial to those who are not receptive to remote or are working in a company where remote is not feasible/acceptable.

REMOTE by GitLab

We gathered the workplace design community in June 2021 for REMOTE by GitLab, a half-day symposium exploring the future of workplace design, strategy, and culture. Learn more about the event, and watch the recorded sessions.

This epic outlines the workstreams associated with bringing REMOTE by GitLab to life.

Social media

We incorporate all-remote content on GitLab’s social media accounts, and are investigating a visual approach to new mediums that are aligned with culture and lifestyle stories.

We are working with talent branding to surface relevant all-remote stories from GitLab team members to talent acquisition channels and review sites, such as Glassdoor, LinkedIn and Comparably.

There are also a number of videos on GitLab’s YouTube channel that relate to working here:

How to contribute (working with us)

To contribute an idea or proposal to further GitLab’s all-remote mission:

  1. Please put each new idea/topic in a new issue within the Office of the CEO project
  2. Put Proposal: [IDEA] as the subject
  3. Assign to @streas
  4. Please set a due date using GitLab’s Due Date feature and provide context for the deadline(s).

Requesting guidance

To request guidance on a panel or speaking engagement:

  1. Provide an overview of the opportunity, and whether you or someone else is being requested, in the #remote Slack channel (for remote engagements) or #ceo-chief-of-staff-team Slack channel (for broader/more general engagements)
  2. We will evaluate the opportunity and provide guidance; if we decide to proceed, the participating GitLab team member will be asked to create an issue using this Corporate Marketing issue template to track progress.

Async weeks

In 2021, the All-Remote team began pilot testing asynchronous work: every sixth week, the team blocks our calendars and declines all non-critical meetings. 1:1 meetings are carried out asynchronously via a process detailed in the All-Remote Async Guide.

The goal of this initiative was to create dedicated space for deep work and creative brainstorming. We encouraged other teams to join us or to find other ways to implement asynchronous workflows.

The pilot test was a big success, inspiring not just GitLab team members (see Sam Beckham’s blog) but even other companies: for example, Twitter adopted Focus Weeks.

We will continue Async Weeks as a regular process for 2022. Our challenge is to reduce synchronous meetings, not to reschedule them. If your meeting with an All-Remote team member is declined during an async week, we encourage you to:

  1. Consider whether the discussion can be conducted asynchronously instead
  2. Look for opportunities to combine this discussion with others in a single meeting
  3. Reschedule only if there are no workarounds

To read more about the results of the Async Weeks pilot, see this slide from the All-Remote Group Conversation (GitLab team members only).

For a good template to roll this out for your team, see the Growth team’s planning and feedback issue. If you have additional feedback on this initiative, please let us know in the #all-remote_action Slack channel. We appreciate hearing your thoughts and ideas.

Team

Contact us

  • Slack: Find us in #remote, #teamops, and #ceo-chief-of-staff-team

Return to the Office of the CEO Handbook.

Last modified December 9, 2024: Updating to impact, not activity (6a91ed4a)
View page source - Edit this page - please contribute. Creative Commons License