Decision Velocity

GitLab TeamOps contribution illustration

Achieving faster, better results depends on decision-making velocity – a team’s ability to increase the quality and quantity of decisions made in a particular stretch of time through behavioral and logistical agreements.

Decisions are the fuel for high-performance teams, and represent a key success metric in the future of work. The more decisions are made, the more results can come from them. Conventional management philosophies often strive for consensus to avoid risk instead of developing a bias for action, which can result in delays, confusion, or unnecessary conflict.

In TeamOps, success is correlated with the group’s decision velocity, which is evidenced by the average duration of a collaboration process; and quality, value, or accuracy of the changes made from a decision.

Action tenets of maximizing decision velocity, including real-world examples of each, are below.

Documented workflows

Building on the tenet of creating a shared reality with a Single Source of Truth, decision velocity is maximized when documentation is applied to operational processes and expectations. Establishing a common set of procedures and best practices for the workflows of your team ensures that each team member is equipped to fulfill the expectations of their assignments, while replacing the objectives of physical supervision – quality assurance and as-needed clarification of instructions.

Having a shared guide in a team promotes measurement clarity, results standardization, worker autonomy, efficient onboarding, continuous improvement, and operational scalability. By providing a common reference point, these documented workflows enhance efficiency and consistency, ultimately leading to improved team productivity and outcomes.

Examples and resources for documented workflows

Example: GitLab Support Workflow Library

To keep their globally-distributed team equipped with instructions for a variety of unexpected customer services scenarios, the GitLab Support team built a workflow library. This always-accessible archive guides team members through the triaging process and subsequent protocols, and also helps them navigate to relevant policies, advice, and tools.

Resource: Documenting workflows to streamline business processes from Notion (article)

Change management support for documented workflows

Quick Start Tips:

  • Individual: As you are implementing a documented workflow, update as needed through the process in order to maintain the accuracy of the documentation.
  • Team: When starting a new project, discuss and document the anticipated workflow in either the SSoT (if the workflow will be repeated) or in the project management plan.
  • Company: Review the SSoT to confirm that the relevant departments have a documented workflow for every item in the cadence calendar.

Recommended TeamOps Partners:

Give agency

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.

Examples and resources for give agency

Example: 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.

Resource: High agency: how to feel more in control in your life and work (article)

Change management support for give agency

Quick Start Tips:

  • Individual: Ask your team members what their preferred task management systems, work environments, and typical working hours are. Set an example by publicly publishing your own. Celebrate the diversity of each.
  • Team: Replace your instinct to supervise with a mindset of support. Instead of asking, “Is this task going to be done by the due date?”, offer “Is there anything you need to ensure the task will be complete by the due date?”
  • Company: Update your company’s onboarding and continuing education programs to include training about what expectations are for operating as a manager of one.

Recommended TeamOps Partner: Workplaceless (training and consulting)

Push decisions to the lowest possible level

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:

  • enhance agency by empowering people to directly and immediately make necessary changes to their work,
  • increase efficiency by eliminating delays while waiting for approval, and
  • free senior leaders from the burden of making decisions that stunt their own productivity.

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 a 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.

Examples and resources for push decisions to the lowest possible level

Example: Updating Developer Advocate mentoring guidelines

A Senior Developer Advocate 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 Advocates to make more decisions on their own — he documented and merged feedback examples. The person doing the work is empowered to make the decision, which 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.

Resource: Decision-making: how leaders can get out of the way (article)

Change management support for push decisions to the lowest possible level

Quick Start Tips:

  • Individual: If/when you see a task or decision that could be completed by a more junior team member, flag it and offer to facilitate the transition.
  • Team: When designing a project management plan, determine which decisions will be made by which team members. For decisions from anyone other than the DRI, document why the approval authority was moved to that level.
  • Company: Update your company’s management training program to include training to prioritize delegation and employee empowerment.

Recommended TeamOps Partner: Lance Robbins (consultant)

Bias for action

A bias for action accelerates ideation, collaboration, and execution better than alignment and consensus. This bias stems from the agency and ownership with which every individual is empowered in an organization practicing TeamOps. People can then use that autonomy to optimize their own proactivity, self-efficacy, and creativity. A team member operating in a conventional organizational context might feel compelled to ask “Should I?” A team member operating via TeamOps can instead think “I will.”

When facing decisions that may involve imperfect information or failures, having a bias for action ensures a more rapid pace of execution. This may require a greater organizational tolerance for mistakes and an appreciation for two-way door decisions, which teams should discuss as part of their shared reality and their collaboration guidelines.

Examples and resources for bias for action

Example: 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.”

Resource: What is a bias for action, and how do you build it? (article)

Change management support for bias for action

Quick Start Tips:

  • Individual: Every time you’re about to ask for approval to do something, stop to consider, “Do I already have approval to do this as the DRI?” or “Is there any part of this task that I can get started on without approval?”
  • Team: Publicly recognize and celebrate when a team member demonstrates a strong bias for action for positive reinforcement.
  • Company: Update your company’s onboarding and continuing education programs to include training about proactivity and self-efficacy.

Recommended TeamOps Partner: Workplaceless (training and consulting)

Low-context communication

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.

All low-context communication should be:

  • Explicit, not implicit
  • Direct, not indirect
  • Simple, not complex
  • Comprehensive, not narrow

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.

Examples and resources for low-context communication

Example: 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: 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).

Resource: Almanac’s Guide to Asynchronous Communication (playbook)

Change management support for low-context communication

Quick Start Tips:

  • Individual: Before sending an asynchronous message to a team member that is any kind of request, proofread it at least once before sending while pretending that you have started working in this team today and know nothing about the project. Confirm that the “why” and the “ask” of the message are explicit and easy to find.
  • Team: Add “good” and “bad” examples of asynchronous messages to the collaboration guidelines section of your SSoT.
  • Company: Update your company’s onboarding and continuing education programs to include training about low-context communication.

Recommended TeamOps Partner: Workplaceless (training and consulting)

Operational transparency

The importance of transparency in TeamOps is critical – the opportunities for learning that used to be available through observation in a physical workplace now have to be replaced with information-based observation, or documented updates. In this environment, your colleagues and supervisors don’t have the same visibility into your daily activities as they would in a traditional office setting. Therefore, actively demonstrating your transparency and productivity becomes even more important.

Your team’s ability to be transparent in your virtual-first ways of working is crucial for building trust, improving collaboration, and showcasing your productivity and value to each other and the rest of your organization. Easy ways to provide better operational transparency are:

  • Set clear goals and communicate them
  • Update the project management system and SSoT often with your progress and status
  • Maintain an organized calendar and share it with all team members
  • Communicate frequently (both asynchronously and synchronously)
  • Proactively share achievements, feedback, and questions (both personal and professional)
  • Schedule a cadence of recording and showcasing your work (eg: weekly Slack post and quarterly OKR report)
  • Be responsive and available for team communication

By being transparent in your virtual work, your team can easily prove productivity and fulfillment of both individual and collective KPIs, which over time ensures accountability, improves the perception of performance, and builds trust.

Examples and resources for operational transparency

Example: GitLab’s “While You Were Iterating” Newsletter

Digital notifications from various tools can be noisy, distracting, and overwhelming. To help GitLab team members feel comfortable incorporating deep focus time into their schedule with full confidence that they won’t miss any important announcements, the internal communications team writes and distributes (via email) a twice-monthly newsletter that includes all important announcements, invitations, amd reminders.

Resource: Operational Transparency by HBR (article)

Change management support for operational transparency

Quick Start Tips:

  • Individual: In a 1:1 with your manager, ask them, “What is a time that you were most impressed with my productivity?” Then, consider how you can recreate that performance visibility.
  • Team: Design a cadence and channel for operational transparency between your team, such as asynchronously a weekly recap.
  • Company: Design and document suggestions for increasing operational transparency. Include a protocols for how to report and resolve when a team member doesn’t feel adequately valued at work.

Recommended TeamOps Partners:


Home

Return to the TeamOps homepage.

Next

Continue the learning experience by exploring TeamOps - Measurement Clarity