TeamOps is a new people practice that brings precision and operations to how people work together. It's rooted in reality and objectivity, and focuses on the behaviors that make for better teams. It's supported by actionable tenets and concrete, real world examples.
At its heart is a belief that creating the environment for better decisions and improved execution of them makes for better teams — and ultimately, progress.
TeamOps is how GitLab scaled from a startup to a global public company in a decade. Now we're opening it up to every organization.
The four guiding principles of TeamOps are below.
Organizations must create a system where everyone can consume information and contribute, regardless of level, function, or location.
When people don't have the opportunity to contribute because of their background, or where they live, or their life stage, we miss out on valuable perspectives.
Action tenets and real-world examples are below.
In conventional organizations, there's often inherent pressure to present a complete and polished project, document, or plan. This expectation slows progress and expends valuable time that could be used to exchange multiple rounds of feedback on smaller changes.
A key aspect of TeamOps is incorporating iteration into every process and decision with a low level of shame. This means doing the smallest viable and valuable thing, and getting it out quickly for feedback. Despite the initial discomfort that comes from sharing the minimal viable change (MVC), iteration enables faster execution, a shorter feedback loop, and the ability to course-correct sooner.
This philosophy mirrors the GitLab product from a cycle-time standpoint. GitLab is built to reduce the time between making a decision and getting the result to market. Iteration enables cycle time reduction to be applied in day-to-day decision making.
Here's an example: Iterating on promotional videos to launch TeamOps
In the development of TeamOps, our team at GitLab aspired to produce two high-quality videos to introduce the first, internal iteration of this certification. When it became clear that TeamOps's brand identity would be changing in the coming weeks, we decided to produce only one video — an example of Minimal Viable Change (MVC) — and iterate as new information came in. This showcases a maturity in embracing iteration. It celebrates the boring solution (one video, the minimum required to inform GitLab team members), and enabled faster decisions throughout the launch phase.
To empower even more of your team to make fast decisions through iteration, consider hosting Iteration Office Hours.
An organization's speed of decision-making can be dramatically slowed if teams are concerned about "stepping on others' toes" by contributing to work outside of their immediate job description. This is often fueled by a fear of conflict, which is one of the five dysfunctions of a team.
Adopting a TeamOps mentality means having short toes and feeling comfortable with feedback, suggestions, and contributions to the work you "own". It also means speaking up when you see an opportunity for iteration. Eliminating a territorial mindset allows for better collaboration, more diversity of thought, and ultimately faster decisions.
In a People Group Conversation at GitLab, the following question was asked: "What can we do from a company side to make sure people aren’t overworking?" At conventional organizations, people outside of the People Group may not risk "stepping on their toes" by proposing iterations and solutions. At GitLab, a proposal was offered by a team member in Marketing. This proposal added an automated message within Slack to remind people to consider taking time off, and to add the note to their next manager 1:1 if they felt that they could not take PTO. Following a healthy discussion, the proposal was added to GitLab's handbook and implemented in its tool stack.
Traditional organizations may use synchronous meetings to host brainstorming sessions. Research shows that these session have many flaws, including production blocking.
TeamOps unlocks faster decision-making by defaulting to asynchronous brainstorming, which requires a team member to make a proposal first. This empowers people to brainstorm when it suits them instead of on a forced schedule. The forcing function of documenting an idea or feedback generates clarity.
In a TeamOps organization, everything is in draft by default. When people share an understanding that everything is open for discussion and iteration, it helps reduce bureaucracy and politics and creates an environment where teams can ship smaller changes, faster.
Here's an example: Support Engineering documenting a proposal to catalyze an async brainstorm
During a team call, GitLab's Support Engineering team came up with the idea to increase efficiency by automatically assigning tickets to active team members.
Rather than gathering a large number of colleagues in a Zoom call to brainstorm, team lead Lee M. created a GitLab issue and asked others to contribute brainstorm ideas there. This led to faster decisions on captured ideas, including several that were deemed not a priority. The documented brainstorm serves future decisions as well. By capturing context, teams can avoid rehashing concepts and make faster (future) decisions.
In TeamOps, it's crucial that each project or decision is assigned a single directly responsible individual (DRI) who is solely responsible for its success or failure. The DRI isn't responsible for doing all of the work: they are the ultimate decision-maker.
This model combinines the best of both hierarchical and consensus organizations. It helps avoid unclear expectations and delays from having too many people involved in a decision.
Leaders must foster a culture where DRIs are empowered, able to escalate to unblock, and willing to share their ideas in the open. This unlocks the team's highest potential. A successful DRI should consult and collaborate with all teams and stakeholders and welcome input from a broad range of diverse perspectives as they form their thoughts.
A member of GitLab's Learning & Development team was responsible for developing mental health awareness content. Given that she was the one doing the work, and her result metric was the one impacted, she was given latitude to be the Directly Responsible Individual. This enabled her to make fast decisions about content type and structure, as opposed to waiting for a more senior person to sign off or appoint her as the lead for this piece of work.
An intentional approach to informal communication is crucial in a fast-paced organization with a bias for asynchronous workflows and text-based communication. 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.
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.
In TeamOps, decisions are two-way doors, meaning they're easy to reverse. That's why a DRI should go ahead and make the decision without approval or consensus. The only time a decision should require a more thorough discussion first is when you can't reverse it or break it down into smaller, reverseable components.
This requires a reframing of the conventional management mindset. Reverting work back to a previous state is a positive thing, because you're quickly getting feedback and learning from it. Making a small change quickly prevents a bigger revert in the future.
Engineers at GitLab collaborated on a change to clarify that GitLab Community Edition can have support. Following discussion in the merge request, it was merged into production. Hours later, a member of GitLab's Support Team reverted the change with context on why. This two-way door decision enabled faster decision making. Even though we returned through the same door we entered (hence, two-way), it hastened decision making on the topic by generating an async brainstorm issue following the reversion.
Return to the TeamOps homepage.