This page is about one of the four Guiding Principles of TeamOps: Everyone Contributes. 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.
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 life stage, 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 if all voices are required to agree before implementation begins, operational efficiency will be sabotaged.
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.
Example 1: Adjusting expensable entries in GitLab's expense report policy
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 13 individuals to a single time slot on a given day for a synchronous meeting.
Efficient execution requires granting agency by default. A critical component of workforce autonomy, agency empowers team members to independently and proactively make decisions without permission, review, or approval—in other words, to self-govern as a manager of one. Leaders who grant this kind of agency also communicate their trust in individual team members to do what they feel is necessary to accommodate their unique needs and to design custom strategies to focus their time and attention on what they deem most important for the organization's success.
Valuing agency so highly doesn't mean assuming all organizational decisions will be made completely independently. Collaboration is still a critical component of TeamOps. But does every organizational decision require collaboration? To enhance their teammates' sense of agency, leaders can start by removing rules or permissions for smaller operational components such as meeting attendance, personal task management systems, or working schedules.
Agency is the antidote to micromanagement, which crushes execution, stifles creativity, and diminishes retention. Greater individual autonomy brings about a shared reality in which all team members feel encouraged to design how and when they want to contribute—and that fuels both individual and collective success.
Example 1: Normalizing that it's OK to look away in video calls
Giving agency begins in the most typical of places. Video calls are a natural part of day-to-day work for many knowledge workers, yet cultural expectations about presenteeism and attentiveness may restrict agency. GitLab explicitly documents that it's OK to look away during meetings and that no one should be embarrassed to occasionally ask for something to be repeated. By creating a culture where people are free to manage their own time and attention, they're able to direct energy on a minute-by-minute basis to execute. No one's path to execution looks the same. It may involve breaks to connect with friends, taking a walk outside, or watching a recording of a meeting during a more suitable time.
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 combinines 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.
It's important to note that TeamOps still allows flexibility for team members to disagree, commit, and disagree, but it reduces the risk that disagreement or dissent will prevent a bias for action.
Example 1: Learning & Development team member owns decisions related to her result metrics
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.
As many decisions as possible should be made by the person doing the work (the DRI), not by their manager or their manager's manager. Fostering this kind of ownership can:
In the spirit of iteration, TeamOps encourages executing a sub-optimal decision with full conviction—then returning to it later to improve upon it based on post-decision feedback—rather than executing on a full decision with sub-optimal conviction. Each project's DRI knows that project's moving parts and the impacts of a particular choice more than anyone else does; that person should be trusted with full accountability over it.
Example 1: Updating Developer Evangelism mentoring guidelines
A Senior Developer Evangelist at GitLab recognized that many coaching and mentoring sessions are shared in private 1:1 conversations. In an effort to add context and transparency to the process — thereby enabling other developer evangelists to make more decisions on their own — he documented and merged feedback examples. The person doing the work is empowered to make the decision. In this example, the decision involved many micro decisions: to document or not, what context to add, where to document, what examples to share, and how to share within the company.
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, or brainstorming.
Documenting paramaters 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.
When working with external teams, follow our three main points to foster communication and education regarding our shared values.
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.
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: OKRs, KPIs, how the team is trending toward achieving goals, 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 goals; it's about understanding what and how others are executing, too.
Both 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.
Example 1: GitLab's User Experience (UX) department Key Review meeting
GitLab's User Experience (UX) department livestreamed a Key Review meeting on GitLab Unfiltered. A distinct element of these meetings is that no 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.
Example 2: Learning and Development Cross-Departmental Conversation
GitLab's Learning and Development team hosted a livestreamed Group Conversation in June 2021. No 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.
An organization's speed of decision-making slows dramatically if its members worry excessively about "stepping on others' toes" when proposing an idea or contributing to work outside of their immediate job descriptions. Often the source of such worry is 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, greater diversity of thought, and ultimately faster decisions.
Example 1: Marketing team member contributing a proposal to improve a People function process
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.
Continue the learning experience by exploring TeamOps - Decision Velocity, or return to the TeamOps homepage.
