Instead of relying on hierarchical management, organizations must create systems and channels where everyone can equally consume and contribute information, regardless of level, function, or location.
If people don’t have the opportunity to contribute because of their background, where they live, or their stage of life, we miss out not only on team members’ valuable perspectives but also on the creative solutions and essential productivity each provides.
When building a foundation for equal contributions, the goal is to create a model where everyone can contribute, but not everyone is required to contribute. This is especially important when preparing for decision making. Anyone is welcome to voice their ideas and opinions, but requiring universal consensus prior to implementation undermines operational efficiency.
Action tenets of facilitating equal contributions, including real-world examples of each, are below.
Working asynchronously does more than free up calendar space. TeamOps prioritizes asynchronous communication as a way of enabling equal opportunities for team members to participate in conversations, receive updates, share insights, or deliver results no matter where or when they are working. In conventional organizations, information exchanges are tightly linked to meetings, which severely limits contributions to only those who are in attendance and are comfortable in a live, spontaneous discussion dynamic.
Instead of spending time scouring schedules and time zone differences to discuss something synchronously, shift the focus to creating clear documentation that will allow team members to contribute both on their own time and with greater intentionality. This gives agency, reinforces a bias for action, and bridges the knowledge gap, resulting in more total iterations.
Establishing a thriving asynchronous culture also requires leaders to celebrate incremental improvements and fight the urge to seek immediate gratification. To do this, they can encourage their team to strive for iteration; transparency; and progress, not perfection.
Examples and resources for asynchronous workflows
In many organizations, altering the expense report policy would require —at minimum— one meeting. In an organization powered by TeamOps, the proposal begins as documentation. Robert M., a senior engineer at GitLab, identified the need to reverse a policy change. He documented his reasoning in a merge request, and notified the Procurement team and other stakeholders. This allowed feedback to be gathered and the appropriate owners of the policy to consider the changes at a time that worked best for them.
Scaled across an organization, this meeting-free approach to making decisions enables more decisions to be made. This approach allows a more diverse array of perspectives to influence the decision, as there was no requirement to align thirteen individuals to a single time slot on a given day for a synchronous meeting.
Resource: Placeless Taxonomy: A Simple Framework for Adopting Async (framework)
Change management support for asynchronous workflows
Quick Start Tips:
- Individual: Confirm that your team has a dedicated channel on your company’s asynchronous communication platform (such as Slack, or Microsoft Teams). Build the habit of prioritizing that channel over all others and starting each work day by catching up on all new messages from your team members.
- Team: Conduct a meeting audit – Are there certain topics that could be discussed asynchronously? Are there any attendees that could be marked as optional? Are there any unnecessary meetings that could be canceled?
- Company: Update your company’s onboarding and continuing education programs to include training about asynchronous workflows.
Recommended TeamOps Partners:
Directly responsible individual (DRI)
In organizations practicing TeamOps, every project or decision has a single directly responsible individual (DRI). Assigning this person is crucial. The DRI is the person solely responsible for a project’s success or failure. To be clear: that person isn’t responsible for doing all of the work; the DRI is simply the ultimate decision-maker.
This decision-making model combines beneficial dynamics from both hierarchical and consensus-guided organizations. It opens decisions to a wider collection of voices and perspectives while avoiding unclear expectations and delays that might result from having too many people involved in reaching a conclusion.
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.
Examples and resources for DRIs
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 was responsible for her results, 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.
Change Management Support for DRIs
Quick Start Tips:
- Individual: When assigned a task or project, confirm explicitly that you are the DRI. Confirm with the assigner exactly which decisions you are and aren’t able to make without approval.
- Team: Create a field in your project management plan template for listing the DRI.
- Company: Update your company’s onboarding and continuing education programs to include training about the responsibilities and expectations of DRIs.
Recommended TeamOps Partner: Workplaceless (training and consulting)
Even though TeamOps teams prioritize asynchronous workflows, it still treats synchronous discussions as a critical element of organizational operations. Well-managed meetings maximize the efficiency and productivity that shared time permits, so meetings shouldn’t just be gatherings of people for a conversation. They should be a resource for decisions and tasks that are best made with immediate feedback and collaboration from multiple people. This means that any conversations that could be facilitated asynchronously should be, including unidirectional presentations, company announcements, results reporting, and brainstorming.
Documenting parameters for meeting management and participation help maximize the investment of time for all participants, and prevent meeting fatigue throughout the company. These guidelines could include rituals such as 25- or 50-minute “speedy meetings”, mandatory agendas, or thorough note taking in a live doc.
Examples and resources for well-managed meetings
Example: GitLab’s Group Conversations
GitLab’s Group Conversations highlight using meeting time for activities that benefit from a synchronous component. This intentional meeting is open to the entire organization and puts emphasis on not presenting live; rather, those running the meeting are expected to distribute presentation materials, including any pre-recorded videos, at least 24 hours ahead of time.
The editable agenda document, which is attached to the company-wide calendar invite, is also used to gather questions ahead of the meeting and organize the order of speakers. The agenda itself becomes an artifact to share or reference later. Plus, recordings of the sync sessions are uploaded as videos on the GitLab Unfiltered YouTube channel.
Resource: Anatomy of a perfect blended meeting (article)
Change management support for well-managed meetings
Quick Start Tips:
- Individual: Create a meeting agenda template and share team-wide (or company-wide).
- Team: Announce and enforce a “no agenda, no attenda” rule.
- Company: Update your company’s onboarding and continuing education programs to include training about well-managed meetings.
Recommended TeamOps Partner: Stop Meeting Like This (consultant)
To address the challenge cross-functional execution at high velocity, TeamOps advocates a stable counterparts model. It works like this: every functional team (e.g., Support) works with the same team members from a different functional team (e.g., Development), so each member of one function always knows who their partner in another function will be. Stable counterparts enable greater trust and familiarity across the organization, which in turn speed up decision making, facilitate stronger communication flows, and reduce the risk of conflicts.
In addition to standard communication channels, recurring opportunities dedicated exclusively to updates and knowledge sharing can help optimize awareness, questions, and feedback about an ongoing project. These Key Review Meetings allow a functional group to stay updated on and discuss essential success measurements, such as: progress towards goals such as OKRs and KPIs, blocked tasks, new assignments, workstream changes, etc.
In conventional organizations, this is apt to be a more informal conversation between a department head and their manager. Broadening the audience of attendees for a Key Review Meeting—to include, for example, the Chief Executive Officer (CEO), Chief Financial Officer (CFO), the function head, stable counterparts, and (optionally) all other executives and their direct reports—broadens the pool of people who can contribute feedback, insights, and advice. It also forces the presenting department to be more mindful of execution, consider areas where they are falling short, and gather input for potential iterations toward progress.
Similarly, cross-departmental conversations—known as Group Conversations within GitLab—can provide the same visibility and inclusion to other projects and teams, to help consider how a project may impact OKRs for teams throughout the organization. Such recurring meetings offer regular updates across all teams on a rotating schedule. It’s the same concept and content as key review meetings with one major difference: all team members are invited! These meetings are designed to give the entire workforce context on what other teams outside of their own are focused on (and how they’re executing). In this way, TeamOps stresses that execution isn’t solely about executing your own goals; it’s about understanding what and how others are executing, too.
Stable counterparts, key review meetings, and cross-departmental conversations help keep operational pace, policies, and practices consistent throughout the organization, while also fostering a sense of inclusion.
Examples and resources for key review meetings
GitLab’s User Experience (UX) department livestreamed a Key Review meeting on GitLab Unfiltered. A distinct element of these meetings is that few presentations are allowed. For context, each attendee was able to view a presentation prepared ahead of time, with a shared Google Doc agenda used to maintain an orderly and inclusive flow of questions and conversations. You’ll notice that executives and their direct reports provide questions and suggestions throughout. There’s a distinct conversation on usability beginning at the 13:51 mark where leads from various functions contribute to improved execution on a 25-second lag recognized in the product.
GitLab’s Learning and Development team hosted a livestreamed Group Conversation in June 2021. Few presentations are allowed in Group Conversations. Attendees look at the prepared presentation deck in advance and document questions in a shared Google Doc. At the 6:35 mark, an attendee (who is sharing their screen) notices that a button does not link to the appropriate place. This enables the L&D team to create an action item, plan an iteration, and continue to execute on their OKRs/KPIs.
Resource: Top 4 Cross Functional Collaboration Examples (article)
Change management support for cross-functional collaboration
Quick Start Tips:
- Individual: Design and implement a personal plan for internal networking, such as participating in team member resource groups, scheduling coffee chats, attending local employee events, volunteering for cross-departmental working groups, or asking a mentor or sponsor for introductions.
- Team: Create a field in your project management plan template for listing the project’s stable counterparts from other departments. Be sure to include their contact information, time zone, and expected level of contributions. (We recommend the RACI matrix.) Also include dates for Key Review Meetings.
- Company: Assign each department director to schedule an open-invitation “Ask Me Anything” meeting (Group Conversation) for every quarter this year.
Recommended TeamOps Partner: Lance Robbins (consultant)
In virtual-first environments, software becomes the shared workplace – instead of an office, it’s a new, digital location for information to be shared, results to be stored, and team members to collaborate together. The tool stacks that comprise these work environments can often be infrastructures built from a combination of dozens (or even hundreds!) of tools.
To create an efficient navigation experience and prevent information overload for your team members, it’s important to classify and prioritize each of the tools that you use. In TeamOps, three categories are recommended:
- Primary – Your core digital infrastructure, or the few tools that all of your staff members use every day and have full public access to.
- Supplemental – Tools that enhance the user experience of one of your primary tools or provide a niche functionality for certain departments. For example, bots that you might integrate into an asynchronous communication platform (like Slack), or graphic design software for the marketing department.
- Substitute – Tools to use instead of the primary tool for certain scenarios. Use these sparingly to prevent redundant costs and conflicting sources of truth.
Examples and resources for tool prioritization
As a visual guide for when to use which tools in their digital infrastructure, fully-remote company Doist created a Pyramid of Remote Team Communication Tools that has not only made their company operations more efficient, but also inspired all-remote teams from around the world to do the same.
Change management support for tool prioritization
Quick Start Tips:
- Individual: Audit your tool usage habits. If you tend to have conversations with team members in more than 1-2 channels throughout your workday, redirect as many as possible to be hosted on the default communication platform for your team.
- Team: Whenever starting a new project, confirm what the default channel for communication will be. Agree to certain channel changes, words, or emojis that indicate that a message is a higher or lower priority than usual.
- Company: Publish your team’s tool prioritization chart in your SSoT. Indicate which are default tools and what level of urgency they indicate.
Recommended TeamOps Partner: Distribute Consulting (consultant)
An organization’s speed of decision-making slows dramatically if its members are worried about sharing their thoughts quickly and honestly. This hesitation typically stems from an absence of trust or fear of conflict, which are two 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, greater diversity of thought, and ultimately faster decisions.
Adopting a TeamOps mentality means providing the psychological safety necessary for all team members to feel confident while sharing ideas, giving transparent feedback, owning impactful project decisions, and managing themselves independently. Eliminating a territorial mindset allows for better collaboration, greater diversity of thought, and ultimately faster results.
To create stronger psychological safety in a virtual-first team, try communication-based tactics, such as:
- Create internal catchphrases and code words to use as reinforcing language
- Leverage shared values and informal communication to express care, get to know your team members’ various working styles, and remind your team what they have in common
- Provide positive feedback when you see courageous behaviors and impressive contributions, just as much as you provide constructive feedback when you see results that need improvement
- Create time and prompts in both synchronous and asynchronous channels for collaborative support and questions
- Include conflict resolution training in both onboarding and leadership development curriculum
Examples and resources for psychological safety
Often, the polite feeling of “I don’t want to step on anyone’s toes,” can contribute to stifled contributions, which is a direct contradiction to GitLab’s mission. To foster a company culture that encourages employees to take initiative in driving positive change, the organization adopted a “short toes” operating principle that empowers team members to contribute to projects and objectives outside of their direct domain.
During employee onboarding, Help Scout teaches new team members that if they ever feel like their integrity is being questioned, to assume it’s a communication misfire, and not because their team member actually thinks they’re bad at their job. It helps to remind staff that the way people share concerns or feedback is often informed culturally, and critical feedback is rarely personal.
Resource: What is Psychological Safety at Work? (article)
Change management support for psychological safety
Quick Start Tips:
- Individual: Give positive feedback and use your team’s catchphrases for psychological safety often, so that others feel comfortable doing the same.
- Team: Add a line item to all relevant agendas for collaborative support and questions.
- Company: Confirm that your handbook includes protocols for how to report and resolve when a team member doesn’t feel psychologically safe at work.
Recommended TeamOps Partner: Flourish (consultant)
Return to the TeamOps homepage.
Continue the learning experience by exploring [TeamOps - Decision Velocity](/teamops/decision-velocity/)