Shared Reality

GitLab TeamOps collaboration illustration

While other management philosophies prioritize the speed of knowledge transfer, TeamOps optimizes for the speed of knowledge retrieval in company-wide documentation.

All teamwork must be based on and informed by an objective — and shared — reality. A collective team member experience that your team shares to develop trust, direct contributions, motivate productivity and empowers new team members to quickly ramp up in their roles. Typically, this shared reality is composed of three elements:

  • Information - All team members should be able to autonomously consume the information and resources that enable productivity in their role.
  • Objectives - Ironically, the day-to-day of your shared reality is usually defined by what you are trying to bring to reality – a result that you’re collaborating to develop.
  • Values - Team member experience is influenced by more than company operations, it’s most directly manifested as team behaviors which can be observed, recorded, and quantified.

Once defined and activated, this reality then is preserved for continuous and universal access and accountability through documentation in a knowledge management system, or “single source of truth.”

Action tenets of building a Shared Reality, including real-world examples of each, are below.

Single Source of Truth (SSoT)

To maximize universal information accessibility, TeamOps intentionally structures all information (policies, objectives, workflows, instructions, values, etc.) in a virtual knowledge management system referred to as a single source of truth (SSoT). The concept of the SSoT is founded on the thesis that decisions are better informed when there is no such thing as a “latest version.” There is only the version.

Teams and functions may choose different mediums as the SSoT depending on the nature of their work. TeamOps allows for this type of SSoT flexibility, but requires that those who dictate the SSoT share that information transparently and crosslink where appropriate.

This type of system scales and maintains workforce awareness and empowerment with much less effort than word-of-mouth updates or memos. By writing guidance down transparently — in a way that others can modify, validate, or contribute to — leadership scales beyond an individual or team, and even beyond the organization. GitLab refers to this approach as handbook-first. A core outcome is that individuals are less dependent on others for the information they need to do their job.

Examples and resources for Single Source of Truth

Example: Maintaining a single list of all applications used within a company

Maintaining a single source of truth for elements that few individuals need isn’t difficult (e.g., using a single shared document for a 1-to-1 meeting between a people manager and direct report). Honoring the single source of truth is harder for elements that are cross-functional by design, such as a list of all applications used across the entire organization.

In conventional organizations, multiple departments may maintain their own version of this list. Crucially, this is either not acknowledged as a problem, or there is no known solution to removing duplication. In an organization powered by TeamOps, duplicate sources may exist initially, but the goal is to remove duplication. Once duplication is discovered, everyone can contribute to the solution by collaborating to create an SSoT. At GitLab, the application list lives in our handbook, and its integrity is ensured thanks to version control.

Resource: The importance of a handbook-first approach to documentation (article)

Resource: How Strong Documentation Powers Async Work (article)

Change management support for Single Source of Truth

Quick Start Tips:

  • Individual: Set a cadence (including calendar reminders!) to update your SSoT with information relevant to your role and its FAQs at least monthly.
  • Team: At least once per quarter, schedule a 1-2 day sprint to audit and update your team’s section of the SSoT. Confirm that all documentation is complete and current, including team member information, workflows, templates, policies, protocols, hyperlinks, etc.
  • Company: Update your company’s onboarding and continuing education programs to include training about how to navigate and utilize your SSoT.

Recommended TeamOps Partners:

Public by default

Conventional management philosophies may rely on intentional information silos or a “need-to-know-basis” approach to knowledge sharing. This approach restricts transparency, with the intention of reducing misinformation. TeamOps flips this paradigm: information should be public by default, with the goal of allowing maximum contribution. “Public by default” requires an organization to designate which information is explicitly not public, creating a bias for transparency across all functions of a business.

A traditional business problem is “how do we get the right information to the right people at the right time?” A TeamOps organization asks: “How do we create a system that allows everyone to access information and make contributions, regardless of role or function?”

In practice, a TeamOps organization uses a knowledge management system that allows any team member to view information related to all other functions. A marketing manager, for example, would be able to view a sales teams’ work and data, without requesting special access. The system is free of walls and information silos. The result is that, instead of needing to create a system for unblocking access to information, management’s role is to educate team members on how to use the information system, how to organize data, and how to self-serve.

This type of system scales with much less effort, and scalable leadership is effective leadership. By writing guidance down transparently — in a way that others can modify, validate, or contribute to — leadership scales beyond an individual or team, and even beyond the organization.

Examples and resources for public by default

Example: Livestreaming company meetings on a branded YouTube channel

Shortly after GitLab Chief Revenue Officer Michael McBride joined the company in 2018, he livestreamed a 1-to-1 meeting with GitLab co-founder and CEO Sid Sijbrandij. As part of McBride’s onboarding, Sid was asked to provide an impromptu pitch of GitLab.

In a conventional organization, this interaction would likely be private and not recorded. By recording it and streaming it to the public on a branded YouTube channel, everyone is more informed — the two individuals on the call; GitLab team members past, present, and future; the wider community; customers and partners; candidates; et al.

Change management support for public by default

Quick Start Tips:

  • Individual: When a team member initiates a non-confidential conversation via email or direct message, move the thread to a public channel for visibility and broader contributions.
  • Team: If team members refer to conversations, decisions, or approvals that were hidden or inaccessible, ask if they can share documentation of the conversation with the rest of the group. Or, at least, ask for a commitment for those conversations to be facilitated in public channels in the future.
  • Company: Confirm that all engagement and employee satisfaction surveys are measuring feelings of isolation, information accessibility, and effective communication.

Recommended TeamOps Partner: Distribute Consulting (consultant)

Collaboration guidelines

Many organizations are so focused on finalizing a decision that they neglect the critical precursor to a successful agreement: setting standards for how that decision will be made. TeamOps stresses intentionally designing, building, and reinforcing shared workstreams and collaboration environments through which decisions and projects flow. This helps align expectations, reinforce the shared reality, and minimize unexpected barriers to success.

When shared realities are based on effectively and efficiently sharing information, it means that communication practices need to be as aligned as possible. Collaboration guidelines are the articulation and documentation of the cultural norms, software standards, and behavioral expectations that help standardize team member experience within an organization. These include details such as how company values are visible in workstreams, etiquette for various communication channels, organizational rituals, and guidelines for tool use. Codifying expectations facilitates more effective and universal collaboration, and helps ensure that miscommunication doesn’t stall a decision or result.

Guidelines should be included in your team’s Single Source of Truth (SSoT) for easy reference and continuous accountability. Depending on the format of your knowledge management system and the volume of codification you have, it could either be a dedicated section, or woven throughout all of the pages.

Examples and resources for collaboration guidelines

Example: Setting Internal Communication Guidelines for Standardized Tool Use

To minimize miscommunications that can stem from cultural diversity, contextual interpretations, or various levels of software experience, GitLab maintains a handbook page about internal communication guidelines. These rules, instructions, and examples ensure that our internationally distributed workforce is using the same tools in the same way, and handing off results to one another without the risk of important information getting “lost in translation.”

Resource: How to Create a Team Working Agreement (article)

Change management support for collaboration guidelines

Quick Start Tips:

  • Individual: Confirm that your SSoT includes a section for collaboration guidelines. If it does, commit to making at least one contribution to it per week. If it doesn’t, contact the DRI for the SSoT to resolve.
  • Team: Build a “suggestion box” communication channel or form where all team members can make suggestions for Collaboration Guideline additions.
  • Company: Update your company’s onboarding and continuing education programs to include training about collaboration guidelines.

Recommended TeamOps Partner: Code Traveller HR (consultant)

Shared values

The reality of your teams’ day-to-day life at work – or team member experience – is influenced by more than company operations; it’s manifested as team behaviors that can be observed, recorded, and quantified. These behaviors are best designed and managed in the context of a shared set of organizational values, which are one of the prerequisites for TeamOps. Without explicit cultural values, there is no group identity or basis for group cohesiveness.

Each organization may create its unique values, but whatever they are, values must be recorded in the SSoT for reference and accountability, then operationalized through habits, rituals, and workflow practices. Include definitions, examples, and measurable success criteria so that any team member within the organization can understand and activate them.

Shared values also create guardrails that provide freedom for individual decision making. This leads to more informed decisions by removing guesswork on whether (or how) values were applied during operational processes.

Examples and resources for shared values

Example: 20+ ways GitLab values are integrated into decision making

GitLab reinforces its values in 20+ ways, including what we select for during hiring, our default software settings, criteria for discretionary bonuses and promotions, and what we explicitly call out when making decisions. These intentional integrations increase the likelihood that decisions are informed by shared values.

Example: How to work with external teams

Starting communication and collaboration with an external team (be it prospective clients, vendors, partners, etc.) who are not familiar with GitLab’s TeamOps culture may be daunting. Every organization has their own culture. We want to empower our team members to foster communication and education to build an understood shared reality. We start with three main points to support this conversation.

Resource Virtual and hybrid teams with shared values perform better (research report)

Change management support for shared values

Quick Start Tips:

  • Individual: When responding or providing feedback to team members, highlight when their contributions activate one (or more) of your company values.
  • Team: When beginning a new project, discuss which values should be specifically prioritized for project success, and how they will influence the project roadmap or group dynamics.
  • Company: Update your company’s onboarding and continuing education programs to include training about your company values.

Recommended TeamOps Partner: Code Traveller HR (consultant)


TeamOps encourages and supports a culture of respect.

Decisions and results are better informed when they include a maximally diverse array of perspectives. While team members should always be empowered to work autonomously, they should still remain included as a collaborator, informed as a colleague, and valued as a critical component of success.

In TeamOps, a bias for asynchronous communication fosters inclusion of many diverse personas, including underrepresented groups, people from different cultural or geographical locations, and neurodiverse individuals. By defaulting to written, asynchronous sharing, everyone contributes in the same way, which standardizes and equalizes the weight of each written message. People of all backgrounds, abilities, and work styles are invited to participate in a way that serves their needs. The best idea—not the loudest voice in the meeting—wins.

TeamOps frees contributors from the conventional bounds of time zones and meetings, and invites a wider audience to participate in a shared reality. This generates more informed contributions from more parties, more thoughtful conversation, and more archived context for retrospectives and evaluations.

Examples and resources for inclusivity

Example: Changing a company operating principle

Samantha L., a leader in GitLab’s Learning & Development team, hosted Crucial Conversations cohorts for six months. She noticed a common theme: people consistently struggled to say “no” at work. Rather than hosting a closed-door meeting to change an operating principle to address this, Samantha proposed a change in a public forum (a GitLab merge request).

Additionally, she posted a Slack message in the public #values channel asking for feedback and suggestions from anyone who felt compelled to contribute. Ultimately, the DRI of the impacted handbook page — GitLab Values — came to a decision that was more informed, as it included a more diverse range of perspectives. The feedback is also well-documented for future reference and iterations.

Resource: Reimagining the virtual workplace around inclusion and engagement (article)

Change management support for inclusivity

Quick Start Tips:

  • Individual: Commit to spending 1 hour per week to building professional relationships with your team members. Prioritize team members that work in independent roles, have quiet personalities, or you suspect are at risk for feeling underappreciated.
  • Team: Connect with your company’s diversity and inclusion director to ask for ideas on how to support your company’s current goals. To help measure your status, specifically request scores, resources, events, or trainings that might be available.
  • Company: Confirm that all engagement and employee satisfaction surveys are measuring feelings of connection, belonging, and trust.

Recommended TeamOps Partner: Flourish (consultant)

Informal communication

An intentional approach to informal communication is crucial in a fast-paced organization with a bias for asynchronous workflows and text-based communication. Understanding a colleague’s unique personality will help teams collaborate more effectively, so leaders should encourage team members to prioritize informal connections (e.g. coffee chats, social calls, special interest chat channels) and get to know the people behind the text. This builds trust, prevents conflict, and enables better communication during work-related interactions.

Building this level of trust also enables DRIs to make faster decisions, as there’s a foundation of confidence in interacting with others.

Examples and resources for informal communication

Example 1: Scheduling coffee chats during team member onboarding

To set the precedent for informal communication at GitLab, each team member is required to schedule and conduct several coffee chats and consider applying to join a Team Member Resource Group as mandatory tasks during their onboarding. This ensures that they have the skills and confidence to initiate casual conversations and build cross-functional relationships during their time with the company.

Example 2: Sharing READMEs (personal operating manuals) to build trust with new team members

Two GitLab team members have never worked together before, so they set up a coffee chat and exchange READMEs prior to a new project starting. They learn a lot about each other, their work styles, and their backgrounds in the 25-minute video call and the asynchronous README reviews. The project runs more smoothly because of their shared trust beyond transactional work interactions.

Resource: Informal Communication Definiton by BambooHR (article)

Change management support for informal communication

Quick Start Tips:

  • Individual: Add 5 minutes of casual conversation time to the beginning or end of every meeting agenda.
  • Team: After a break, holiday, or company closure, reconnect as a team in your asynchronous communication platform by each sharing pictures of how you spent your time off.
  • Company: Build channels in your asynchronous communication platform dedicated exclusively to informal communication about topics like hobbies, local culture/events, pets, caretaking, etc. (Check out GitLab’s Slack channel directory for inspiration.)

Recommended TeamOps Partner: Flourish (consultant)


Return to the TeamOps homepage


Continue the learning experience by exploring TeamOps - Everyone Contributes