This page is about one of the four Guiding Principles of TeamOps: Measurement Clarity. 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.
Outdated workforce supervision tactics often trigger bias and presenteeism. Evaluating productivity differently requires unique methods of recording and managing results.
Measurement is important in any organization. As Peter Drucker famously said, "If you can't measure it, you can't manage it." But in conventionally managed organizations, too often the model of "successful work" involves physical presence—a team member needs to be in a certain building in order to be "at work."
Teams working via TeamOps should employ methods of measuring productivity, value, and results that don't depend on physical supervision as a measure of contribution. Re-prioritizing what, _how), and _when) the organization measures enables a higher frequency of success analysis, greater accountability for objectives, lower workforce discrimination, and wider reach for company communication.
In short: TeamOps treats "work" as a verb, not a noun.
Action tenets of measurement clarity, including real-world examples of each, are below.
Conventionally managed organizations often increase pressure to present complete and polished projects, documents, or plans when work "has finished." But this expectation slows progress and expends valuable time that could be used to conduct multiple rounds of feedback on smaller changes.
Executing on a decision shouldn't be a singular, one-time event. TeamOps reframes execution as an ongoing series of iterations—small, compounding results each worthy of celebration. This encourages smaller steps, which are more amenable to feedback, course correction, easy delivery. Breaking decisions into manageable components makes obtaining desired results more feasible.
A key aspect of TeamOps is incorporating iteration into every process and decision. This requires team members to act with a relatively low level of shame—that is, to resist the urge to conceal work until it's perfect for fear of making mistakes. Working this way means doing the smallest viable and valuable thing (the minimal viable change, or MVC) as quickly as possible in order to solicit feedback. Despite initial discomfort involved in this kind of sharing, iteration enables faster execution, shorter feedback loops, and an ability to course-correct sooner.
Ultimately, the goal for fast-moving teams is to reduce the time between making a decision and getting the result to market. Taking an iterative approach to everyday operations can help a project, team, or company in any industry achieve this goal.
Tip: To empower even more of your team to make fast decisions through iteration, consider hosting Iteration Office Hours.
Example 1: Iterating on promotional videos to launch TeamOps
During development of TeamOps, our team at GitLab aspired to produce two high-quality videos to introduce the first, internal iteration of TeamOps certification. When it became clear that TeamOps' 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 brand guidelines took shape. We celebrated this boring solution (one video, the minimum required to inform GitLab team members), which enabled faster decisions throughout the launch phase.
Example 2: Adding an MVC GitLab Citation Index to GitLab for Education homepage
A conventionally managed organization might treat a homepage revision in a binary fashion: it's either complete or it's not. This merge request details a minimum viable change (MVC) to add one element to the GitLab for Education homepage. In the comment thread, GitLab team members agree that this iteration moves the page one step closer to an ideal state. By embracing and celebrating each iteration as execution, team members accelerate execution on other projects rather than being stuck on a prior project.
While often associated with the Agile software development movement, "definition of done" is a practice that teams in any industry can use to enhance measurement clarity. For organizations practicing TeamOps, developing a definition of done helps teams identify the conclusion of one iteration and the beginning of the next. For software development teams, this usually means that the code is verified as working; for other teams, it may mean that a certain output has been created and delivered.
A team's definition of done may take different shapes. It might outline the success criteria for a quarterly OKR, explain when a project or working group should be considered "closed," or enumerate the fulfillment criteria for a small task. Regardless of the scope of impact, clearly communicating and documenting completion criteria as a definition of done helps TeamOps teams align more closely on methods for measuring and define success.
Even better, definitions of done are prompts for important team-building communication. When all of the criteria are complete, that's a signal to your team to review the contributions each team member has made to the work, collaboratively brainstorm future iterations, and celebrate the fulfillment of your shared reality goals.
Example: TeamOps Course Updates
Every quarter, GitLab's Workplace team adds new features and enhancements to the free TeamOps course in LevelUp. Each project management plan includes a Measurement Clarity section outlining a list of completion criteria. This creates a very clear distinction between work that's In Progress and Closed, and generates a signal to close the issue.
TeamOps may not treat elapsed time as a success measurement, but it does require due dates. Under TeamOps, however, due dates aren't a means of creating unnecessary rigidity or measuring the duration of contributions; they exist to force mechanisms that enable teams to execute on decisions and enforce accountability.
An organization practicing TeamOps will always set a due date and, if necessary in light of changing circumstances, will cut project scope to meet that due date rather than postpone that date. This encourages teams to think iteratively, recalculate the scope of current work, and better determine which aspects of a project are best saved for future objectives. Working this way limits loss of momentum.
Example 1: Maintaining a monthly release cadence for 10+ years
As of 2022-12-01, GitLab has shipped a monthly product release for 134 consecutive months. That's more than 10 years! A decade of consistent execution is made possible by cutting scope instead of pushing ship dates.
Conventional management philosophies glorify "metrics," which is a nonspecific term that often lacks connection to objectives, mission, values, workflows, strategy, or a shared reality. TeamOps prefers Key Performance Indicators (KPIs), which are smaller, incremental measures linked to Objectives and Key Results (OKRs) that, well, indicate performance. These offer greater context on both daily operations and the relevance of ongoing productivity to a function or the entire company.
While KPIs measure smaller units than OKRs do, the former aren't dependent on the latter. In fact, the two should be symbiotic in nature, informing and influencing each other to enhance operational visibility, measurement accuracy, and team empowerment. If you're not creating OKRs to improve KPIs, then you're either missing KPIs or you have the wrong OKRs.
Crucially, under TeamOps every functional department shares its KPIs transparently shared across the organization. This aids visibility and enables everyone to contribute.
Example 1: Chief Executive Officer OKR and KPIs
In Q3-FY23 at GitLab, a CEO OKR was Improve user and wider-community engagement. This is the initiative to improve a series of KPIs, a subset of which are documented below:
These are documented in a tool that's accessible to the entire organization. Any team member can see any function's OKRs and KPIs for the quarter, reinforcing the value of transparency.
Every organizational operational model aims to optimize the efficiency with which teams produce results. But conventionally managed teams make a critical error when they conflate "efficiency" with "speed." Doing so means time often becomes the team's highest priority—and working hours become a principal success metric for the organization.
In organizations powered by TeamOps, team members understand that the root of "productivity" is "to produce," and therefore focus on executing business results, rather than executing on presenteeism. TeamOps therefore encourages success measurements based on outputs, not inputs.
Note that outputs aren't just tangible deliverables. Results include any form of value a team member contributes to the organization's shared reality: helping a teammate, satisfying a customer, shipping code, brainstorming a new idea, writing a revision, or researching a competitor. All quantifiable reports, messages, insights, or submissions are evidence of productivity.
Example 1: Measuring impact of GitLab's 10 year campaign
Producing the 10 Years of GitLab integrated marketing campaign and associated website demanded a cross-functional effort. Working group members established a GitLab issue to explicitly define elements to be tracked and measured in order to provide an adequate report of the campaign's overall impact. By focusing on results over hours spent (or if a given team member was online at a certain time, or in a certain office), everyone involved in the project could focus energy on executing the campaign.
Achieving measurement clarity involves more than evaluating whether your team was successfully achieved its goals. It also involves evaluating how your team was successful during the process. So just as a team's measurements should be as transparent as possible, so too should be a team's feedback about those results.
Transparent feedback means that constructive criticism is immediate, specific, and documented. Like all information shared on a team practicing TeamOps, the impacts and action items a message triggers shouldn't rely on a recipient's subjective memory or interpretation. Sharing feedback is a great start to improving an individual's future work; sharing it transparently means that the entire team can improve together.
To optimize the efficacy of delivered feedback, consider how other TeamOps tenets can support actionability. For example:
Example: A member of GitLab's L&D Team Giving Feedback to the CEO
At GitLab, our mission that [everyone can contribute] even influences our feedback guidelines—suggesting that any team member, at any level, can give feedback to any other team member, at any level. In this video about Guidance on Giving and Receiving Feedback, the CEO of GitLab, Sid Sijbrandij, discusses this challenge in more detail, and asks for performance feedback from a member of the Learning & Development team.
In organizations built on information-based operations, team members' collective sense of stability, security, and well-being is an outgrowth of their knowing when future opportunities to receive and exchange knowledge will occur. A Single Source of Truth (SSoT) and asynchronous workflows ensure that existing information is continuously accessible. But what about informational updates? Not knowing about emerging decisions, forthcoming goals, or adjustments to long-term visions can compromise a team's focus, efficiency, and trust.
This is why establishing a transparent cadence for decision-making activities, informational updates, and feedback opportunities is important for teams practicing TeamOps. A regular cadence sets a pace for productivity and creates predictable, comfortable intervals for work. Establishing and documenting a cadence for everything from operational workflows and due dates to company announcements and team meetings can prevent the kinds of distraction and burnout that often result from context switching, distractive research, or individual uncertainty.
Example: GitLab’s Quarterly All-Hands Meeting
At the same time each quarter, executive leadership hosts GitLab Assembly—a company-wide recap of the past quarter's accomplishments, summary of the new quarter's objectives, and an open-floor Q&A for any employee to resolve questions or concerns. Knowing exactly when this meeting will occur, who will be in attendance, and what will be discussed gives GitLab team members full confidence of when they can have direct access to the executive team about company growth.
Restart the TeamOps model by learning about TeamOps - Shared Reality, or return to the TeamOps homepage.
