Measurement Clarity

GitLab TeamOps teamwork illustration

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, greater accountability for objectives, lower workforce discrimination, and wider reach for company communication.

In short: TeamOps treats “work” defines work as something we do, not somewhere we go.

Action tenets of measurement clarity, including real-world examples of each, are below.

Transparent measurements

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

Examples and resources for transparent measurements

Example: Chief Executive Officer OKR and KPIs

In Q3-FY23 at GitLab, a company 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:

  1. Evolve the resident contributor strategy by conducting 5 customer conversations with current “resident contributors” in seat
  2. Certify 1,000 team members and 10,000 wider-community members in TeamOps
  3. Enhance Corporate Processes and Successful Corporate Development Integration & Prospecting

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.

Resource: Performance Management on Remote and Hybrid Teams (article)

Change management support for transparent measurements

Quick Start Tips:

  • Individual: Confirm that your personal task and project management systems sharing settings are public by default. Inform your team members how and where to access them if they’re ever wondering what you’re working on.
  • Team: When starting a new project, define and document the contributions of each team member, and how “success” will be measured both individually and collectively.
  • Company: In performance review agendas, add a section to revisit (and update, if needed) each team member’s weekly, monthly, quarterly, and yearly OKRs and KPIs. Specifically discuss and answer the question, “What does productivity look like in this role?”

Recommended TeamOps Partner: Lance Robbins (consultant)

Measure results, not hours

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.

Examples and resources for measure results, not hours

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

Resource: Time is Not a Measure of Productivity (article)

Change management support for measure results, not hours

Quick Start Tips:

  • Individual: When writing your daily to do list, note which three tasks are your highest priority, and use the completion of those tasks to measure “a good day’s work.” Consider shedding or delegating any tasks that don’t directly relate to your OKRs.
  • Team: Confirm that the assigned objectives and key results (OKRs) of each team member are prominently displayed in each project management plan.
  • Company: Confirm that your HR or People department is measuring and monitoring presenteeism, and that work location is not being discussed during performance reviews.

Recommended TeamOps Partner: Lance Robbins (consultant)

Definition of done

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 not always be the same. 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 on methods for measuring and defining 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.

Examples and resources for definition of done

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.

Resource: Definition of Done by Leading Agile (article)

Change management support for definition of done

Quick Start Tips:

  • Individual: When conducting any kind of retrospective discussion, start the conversation with whether or not the Definition of Done was fulfilled (as a baseline for success measurement), then move on to feedback and learnings.
  • Team: Create a field in your project management plan template for listing the project’s definition of done.
  • Company: When approving OKRs, include a Definition of Done as a minimum requirement for fulfillment, then supplement with more ambitious goals for the team or individual to work toward.

Recommended TeamOps Partner: Lance Robbins (consultant)

Prioritize due dates over scope

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.

Examples and resources for prioritize due dates over scope

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

Resource: Project Scope: How to Meet Deadlines and Keep Stakeholders Happy (article)

Change management support for prioritize due dates over scope

Quick Start Tips:

  • Individual: Whenever a status update or project review conversation indicates that a result is falling behind schedule or that contributing team members feel overwhelmed, immediately ask the question, “What can we do to simplify this result so that we can stay on track?”
  • Team: Confirm that the due date of a project is prominently displayed in each project management plan for your team.
  • Company: Update your company’s onboarding and continuing education programs to include training about how to produce iterative results.

Recommended TeamOps Partner: Lance Robbins (consultant)

Transparent feedback

Achieving measurement clarity involves more than evaluating whether your team successfully achieved its goals. It also involves evaluating how your team succeeded 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
  • 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:

  • Exercise your bias for action to share feedback as quickly as possible
  • Use low-context communication by sharing specific examples that support your feedback
  • Leverage asynchronous workflows to allow time for review and reflection
  • Encourage iterative growth to build up to aspirational goals
  • In appropriate scenarios, share feedback (both positive and negative) publicly with an entire group whose other members can also learn from the insights.
  • As a manager, prioritize building psychological safety during group collaboration by encouraging healthy controversy and by investing time in informal communication to build trust and camaraderie that can withstand negative criticism.
Examples and resources for transparent feedback

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.

Resource: Guide to Giving Remote Feedback (playbook)

Change management support for transparent feedback

Quick Start Tips:

  • Individual: Commit to sharing sincere compliments and/or constructive criticism with each of your peers at least once a week. (While you’re building the habit, set reminders on your calendar for reminders and accountability.)
  • Team: Add a section for group feedback into every meeting agenda.
  • Company: Create a ritual for company leadership to receive and share feedback on certain projects or tasks, to set a top-down example of healthy feedback dynamics.

Recommended TeamOps Partner: Code Traveller HR (consultant)


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.

Examples and resources for cadence

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.

Resource: How to use a business cadence to promote collaboration (article)

Change management support for cadence

Quick Start Tips:

  • Individual: Design and document a cadence calendar for personal rituals, such as internal networking, SSoT updates, or operational transparency reporting.
  • Team: Design and document a cadence calendar for team rituals, such as delivery cycles, team offsites, or performance reviews.
  • Company: Design and document a cadence calendar for company rituals, such as OKRs, stakeholder meetings, or workforce retreats.

Recommended TeamOps Partner: Lance Robbins (consultant)


Return to the TeamOps homepage.


Restart the TeamOps model by learning about TeamOps - Shared Reality.

Last modified July 10, 2024: Fix broken links and spelling (680a0bc8)