This page is about one of the four Guiding Principles of TeamOps: Shared Reality. To learn more about the other three principles, return to the main TeamOps page for a complete overview of TeamOps, or enroll in the free TeamOps Course.
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:
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.
To maximize universal information accessibility, TeamOps intentionally structures all information data (policies, objectives, workflows, instructions, values, etc.) in a virtual knowledge management system referred to as a single source of truth (SSoT). It 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 task and the nature of their work. TeamOps allows 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.
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, persistent 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 which 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. Once duplication is discovered, everyone can contribute to the solution (collaborating to create an SSoT) and one's default is to actively work to remove duplication. At GitLab, the application list lives in our handbook, and integrity is ensured thanks to version control.
Conventional management philosophies may rely on intentional information silos or a "need-to-know-basis" model. This approach restricts transparency, with the goal of reducing misinformation. TeamOps flips this: 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 project management system that allows any team member to view data 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.
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; etc.
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 a 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 items like these facilitates more effective and universal collaboration, and helps ensure that miscommunication doesn't unnecessarily 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.
Example 1: 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 demonstrations 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.”
Low-context communication assumes that the person you're communicating with has little or no context about the topic at hand. This means the person delivering the information is responsible for providing everything the recipient will need to understand the situation and make an informed response—such as SSoT links, definitions, relevant team members, or updates. This empowers individuals to make decisions and take action without needing to ask unnecessary follow-up questions that could have been avoided.
Assuming that recipients of your communication do not know anything about the topic at hand and wish to learn as much as possible in as little time as possible, all low-context communication should be:
A critical principle of low-context communication is to Say Why, not just What. TeamOps organizations recognize that up-front transparency is a foundational element to team member autonomy, transparent documentation, and business continuity. This requires announcements, updates, and decisions to be shared not only with what the change is, but also why it's being made. While saying "why" does not mean justifying every decision against other alternatives, it does require a leader to articulate their reasoning. This prevents speculation, contributes to institutional memory, and builds trust, which is one of the traits of being a great remote manager.
Also note that each business function may have unique expectations on low-context communication (e.g. what classifies as low-context in sales may not in engineering). If decisions within a function appear to be ill-informed, audit the expectations on context first.
Example 1: Making a company-wide announcement that meaningfully changes a policy
At GitLab, a department leader will typically send out a company-wide message to a Slack channel that includes every team member. Crucially, this message does not include only the news, but a link to a GitLab merge request detailing what changed (diffs).
The merge request which added the very copy you're reading now is an example of low-context communication in practice. Darren M., the DRI for the change, also shares a link to the handbook and/or project page ("the news"). The merge request includes context on what's changing, and details on where to ask questions and contribute new iterations (including an optional Ask Me Anything (AMA) session). This gives any team member enough context to share feedback and apply these changes to their own teams in an informed way.
Example 2: Updating GitLab's recruitment privacy policy
GitLab's Recruitment Privacy Policy was updated. Rather than updating the policy behind closed doors, the merge request outlines the why. It provides context into how the change enables cross-functional groups to work more efficiently. The explanation of why enables more thoughtful conversation around a potentially polarizing topic (privacy).
The reality of your teams’ day-to-day life at work – or 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. 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 more freedom for individual decision making. This leads to more informed decisions by removing guesswork on whether (or how) values were applied during operational processes.
Example 1: 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 2: How to work with external teams
Starting communication and collaboration with an external team (be it prospective clients, vendors, partner, 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.
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, folks from different cultural / 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.
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.
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 helps enable DRIs to make faster decisions, as there's a foundation of confidence in the experience and judgment of others.
Example 1: [Scheduling coffee chats during team member onboarding]
To set the precedence of 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 prior. The project runs more smoothly because of their shared trust beyond the transactional work interactions.
Continue the learning experience by exploring TeamOps - Everyone Contributes, or return to the TeamOps homepage.
