LogoLogo
  • Getting started
    • Welcome
    • Introduction to Multitudes
    • How Multitudes Works
  • Configuration & Setup
    • Setup: Integration Permissions
    • Permissions and roles
    • Adding Users & Teams
    • Configuring your Team
    • User Linking
    • Configuring Working Hours
    • Customize Work Categories
    • Alerts Configuration
    • Customize Targets
  • Metrics & Definitions
    • Multitudes Insights
    • Our Approach to Metrics
    • Process Metrics
      • Flow of Work
        • Change Lead Time
        • Coding Time
        • Review Wait Time
        • Editing Time
        • Deploy Time
        • PR Size
        • Focus Time
      • Value Delivery
        • Deployment Frequency
        • Merge Frequency
        • Types of Work
        • Feature vs Maintenance Work
      • Quality of Work
        • Change Failure Rate
        • Mean Time to Recovery
        • Mean Time to Acknowledge
        • Number of Pages
        • Deployment Failure Rate
    • People Metrics
      • Wellbeing
        • Out-of-Hours Work
        • Page Disruptions
        • Meeting Load
      • Collaboration
        • PR Participation Gap
        • PR Feedback Given
        • PR Feedback Received
        • Feedback Flows
    • Deployment Metrics
  • Integrations
    • Deployments API
    • GitHub Actions
    • Google Calendar
    • Outlook Calendar
    • Jira
    • Linear
    • Opsgenie
    • PagerDuty
    • Slack
  • Knowledge base
    • Annotations
    • Exporting your data
    • Types of Alerts
      • Daily Blocked PRs alert
      • Trend Summary alert
      • Multitudes AI Coach
      • 1:1 Prompts
      • Annotations alert
    • Troubleshooting Missing Commits
    • Bot Activity
    • Collaborative PRs & All PRs Toggles
  • Account Management
    • Billing & Payments
    • Security & Privacy
Powered by GitBook

© Multitudes 2025

On this page
  • What is Multitudes?
  • Who is Multitudes for?
  • Our approach
  • We are not another creepy monitoring tool
  • We are different from other engineering effectiveness tools
  • We don't ingest your codebase

Was this helpful?

  1. Getting started

Introduction to Multitudes

Learn how we help engineering teams and how we're different from other analytics tools.

PreviousWelcomeNextHow Multitudes Works

Last updated 1 month ago

Was this helpful?

What is Multitudes?

Multitudes is a software tool that provides analytics and recommendations to unlock happier, higher-performing teams.

We integrate with the collaboration tools you use at work – e.g., for version control, CI/CD, issue tracking, or incident management – and then pull out research-backed insights about where work is blocked, how your team is collaborating, who’s at risk of burnout, and more.

We bring metrics like DORA, SPACE, and DevEx to life with nudges in the daily workflow, so you can help your team take action.

Who is Multitudes for?

Multitudes is for human-centric engineering teams who want research-backed metrics to improve together. It’s for teams that want the holistic view – not just of team performance, but also about people dynamics like collaboration and wellbeing.

Our insights and actions are useful to all members of an engineering organization, whether you’re an engineer, manager, or CTO. That said, our #1 focus is on empowering engineering teams to take action – because the best way to get continuous improvement is to build a daily habit across teams.

Our approach

We are not another creepy monitoring tool

We get it – a lot of us have been burned by tools that reduced people down to lines of code written, PR's opened, or some blackbox “efficiency score”. We don't do that – not only are these measures not useful, they can be harmful for people.

Instead, our focus is on helping teams create the right conditions for people to do great work. Are people getting enough support? Is anyone working long hours? When we do look at “performance” measures, it’s at a team level – for example, looking at the Lead Time for the whole team. PRs are a team sport, and we know that individuals do their best work when they’re in an environment that’s supportive and good for people’s wellbeing. We're careful about how we show individual metrics, and only when it can bring value to the person who the data is about. You can learn more about .

We also hold ourselves (as a team) to rigorous standards of ethics and consent. We design for transparency; managers and team members see all the same data and insights. We’ve publicly shared our , and we welcome feedback on how we’re doing.

And finally, if you’re someone who’s been burned in the past and don’t have the energy for a tool like this, we get that too! If someone on the team feels uncomfortable with Multitudes, we recommend that the team not use us. Our goal is to support team trust and collaboration, so we recommend that the team make a unified decision on whether our tool is a fit.

We are different from other engineering effectiveness tools

Our second key point of difference is our focus on empowering teams, not on micromanaging them. Our goal is to give teams, including individual contributors, the insights they need to make their own decisions about how to work together. As part of that, we encourage transparency – everyone on the team should have access to their own Multitudes data. We do this for our own team, and we've seen how useful it is for building trust and supporting behavior change.

We don't ingest your codebase

Multitudes pulls in code metadata from GitHub; our app does not ingest your codebase. This metadata includes information about pull requests – such as when they were created, who the author was, commits made on the pull request, number of lines changed, etc. and about comments – including comments written on pull requests and reviews submitted. When you set up the GitHub installation, you can see the full list of permissions that Multitudes requests.

Multitudes also gets some data from teams about their structure, e.g., which teams people are on, their roles, and their seniority levels.

At Multitudes, we know that PR's are a team sport. People dynamics are what determine team performance, so even if we only wanted to improve team performance, we would still need to provide insights & coaching on how the team works together. As evidence of this, see research, which showed that psychological safety is the number one determinant of team performance. That’s why we look at things like collaboration trends and wellbeing on top of the team performance metrics that you often see in other tools.

Metrics & Definitions
data ethics principles
Google’s Project Aristotle