What is TeamOps and how you can implement it at your company

A few months ago, I took the TeamOps Foundations course on the GitLab University website. I was impressed! TeamOps reflected exactly how I see companies functioning and growing. So what is TeamOps, and why should you care?

TeamOps Definition & Objectives

TeamOps is defined by its creators as a "performance-centric operational approach designed to optimize team dynamics, streamline decision-making, and enhance productivity within organizations." In other words, it's a modern way to efficiently run companies and teams. Created and practiced by GitLab, TeamOps's main objectives are:

• Maximizing productivity, both individually and collectively by making the decision-making process faster.
• Building documentation to make sure knowledge is shared and all organization members are aligned.
• Increasing flexibility by adopting a remote-first and async-first approach that will give members location and schedule flexibility.
• Empowering the team by increasing ownership, promoting autonomy, and tolerating failures.

The Four Pillars of TeamOps

The TeamOps framework lies on four pillars: shared reality, equal contributions, decision velocity, and measurement clarity. Here's an overview of each of these pillars.

Shared Reality

TeamOps optimizes for the speed of knowledge retrieval, not transfer. All teams should be informed by the same reality, usually shared in an easy-to-use handbook. This handbook serves as a Single Source of Truth (SSoT), and includes information related to the company, the available tools, and how to work together.

Some notes about the handbook:

• It has only one version, i.e., the current version. It's meant to be frequently updated.
• The handbook should be public by default. Non-public sections should be explicitly mentioned.
• There should be no unwritten rules.
• Company information includes objectives, values, DNA, etc.
• Tools information covers internal tools used to do the work, administrative tools, and everything that an organization member would need to know.
• Collaboration information is both about formal communication (meeting guidelines, dev culture, programming standards, etc.) and informal communication (social interaction, introduction about each person, etc.).

Equal Contributions

Everyone at the organization can equally consume and contribute information, regardless of level and function. There is however a Directly Responsible Individual (DRI) for each project or decision. The DRI is solely responsible for its success or failure.

Meetings are only necessary for decisions and tasks that are best made with immediate feedback and collaboration. Most work should happen outside of meetings. A well-managed meeting includes a mandatory agenda and thorough note-taking in a live document.

One concept I particularly liked at GitLab is "short toes". People collaborating together should feel comfortable with feedback and suggestions. They shouldn't be offended that their colleague is "stepping on their toes" by contributing to the discussion. This policy aims at creating a psychologically safe environment where everyone can pitch in.

Decision Velocity

One of TeamOps's objectives is to increase the quality and quantity of decisions a team can make. Here are some steps that will help achieve this objective:

• Documenting decision workflows for better clarity.
• Executing a sub-optimal decision with full conviction rather than executing on a full decision with sub-optimal conviction. In other words, it's better to release an incomplete product rather than delaying its release date.
• Adopting a bias-for-action mindset while at the same time tolerating mistakes and failures.
• Using a low-context communication approach: assume the person you're communicating with has little or no context about the topic at hand. Be explicit and say Why, not just What.

Measurement Clarity

TeamOps is all about measuring the output instead of the input. It doesn't matter where and when you're working - as long as the job is done.

An interesting concept for accurate measurement is the definition of done. For each iteration, teams should define its conclusion and the beginning of the next iteration.

The measurement clarity tenant considers the following:

• Outputs are not only tangible deliverables; they could be helping a teammate, satisfying a customer, brainstorming a new idea, researching a competitor, etc.
• Result measurement is prioritized over time measurement.
• KPIs are small increments linked to Objectives & Key Results (OKR).
• Evaluating how the team succeeded is more important than evaluating whether the team succeeded.
• Feedback should be immediate, specific, and documented.

Implementing TeamOps

As Annie Dean from Atlassian says: "The office is not where you do work. The internet is." TeamOps is an approach valid for both on-site and distributed companies. Here's a quick guide to start implementing it:

• Document all unwritten rules.
• Include informal connection guidelines in the handbook.
• Mention explicitly that async communication is the main way of communication in the virtual workplace (Slack, Teams, etc.).
• Document a workflow and convert it to async format.
• Conduct a meeting with a strict agenda for the purpose of making a decision.
• Mention "why" when communicating the next decision.
• Define “done” for a task or project you are working on.
• Give immediate and specific feedback to a team member.

At Supportful, we've started implementing TeamOps. Let me know if you're considering TeamOps for your company or share your learnings if you've already implemented it.

‍