Menu
Welcome to Multitudes! You’re here because you care about team improvement and because you want to use data responsibly to support that.
Here are 5 tips to get the most out of Multitudes. Take ~10 minutes to set these up, to hit the ground running with more accurate, insightful metrics about your teams.
⚡️ Action: Create teams in the app or sync with GitHub Teams
This is the most important step – make sure you’ve set up your teams in Multitudes! Our insights and alerts are most useful when they’re about the people you care about. It will also help you drill down into teams and departments that make the most sense when it comes to discussing or reporting metrics.
You can create teams via Settings > Teams. If your organization has layers of hierarchy (e.g., departments, product groups, pods, teams), then we recommend creating the top-level team groups first. This is so that when you create nested teams, you can select the “Parent team” from the dropdown. E.g. Create a team called “Product Group A”, then create the teams within Product Group A.
Alternatively, you can sync with your organization’s GitHub teams. This means that the team structure in Multitudes will exactly reflect the teams in GitHub, and will stay up to date with any changes you make there.
💡Adding contributors to teams does not automatically give them login access to view Multitudes (learn more about the difference here). You need to give login access separately – read here for how. We encourage you to give all team members access. Transparency is reassuring to team members – since then they can see the same data you’re looking at – and when team members have access to their own data, it enables them to own their own progress.
Multitudes remembers team histories, so if there is a team change, it will take effect from the time it is entered into Multitudes. For example, if Person A moves from Team 1 to Team 2 on Wednesday, their data will be attributed to Team 1 until Wednesday, and then appear in Team 2’s data from Wednesday.
⚡️ Action: Install our Slack integration
You can get insights from Multitudes in your existing workflow, whether that be Slack or email. Try setting up our Daily Blocked PRs alert for standups, our weekly or fortnightly Trend Summary alert for retros, and 1:1s prompts for some conservation starters based on data.
⚡️ Action: Set up a CI/CD integration (GitHub Actions or generic Deployments API) and an IMS integration (Opsgenie, PagerDuty)
DevOps Research and Assessment (DORA) metrics provide a standardized set of measures for the tech industry to evaluate team performance and maturity. Multitudes provides all of the key DORA metrics for your teams to easily benchmark against industry standards – check out the ⭐starred⭐ topics on our What We Measure And Why page.
While Change Failure Rate and Lead Time are provided out of the box, setting up 2 integrations (to your CI/CD and IMS tooling) will give you access to Deployment Frequency and Mean Time to Recovery – read on!
💡Setting up more integrations on Multitudes is free - we don’t charge extra for integrating with more of your tools.
When you first onboard onto Multitudes, you will have the Merge Frequency metric by default from your GitHub integration. This is the number of pull requests merged. However, this doesn’t always reflect how often you’re shipping to customers. For example, your team may collect up multiple PRs before releasing them in one large deployment.
There are two ways to let us know about your deployments to production:
This will give you a more accurate picture of how often your teams are shipping code.
💡Setting up a deployment integration (GitHub Actions or the Deployments API) also improves the accuracy of Lead Time. Out of the box, Lead Time defaults to measuring the time from a PR’s first commit to when it’s merged. But once you’ve integrated with a deployment tool, Multitudes will match the deployment information you send us with the PR(s) that they deploy, and use the deployed time instead of the merged time. This is a more accurate picture of how long it takes to deliver value to customers.
To get information about how long your teams take to recover from an incident or failure in production, set up one of our incident management tool (IMS) integrations – Opsgenie or PagerDuty.
⚡️ Action: Configure team members' preferred working hours
Multitudes provides wellbeing metrics like Out-of-Hours Work and Page Disruptions*, which takes into account each team member’s preferred working hours. Update the preferred working hours and timezone of your team members to get an accurate view. Team members can do this themselves by editing their profile, or you/team leads can update them in Settings > Team Members.
When you update working hours, you will be asked if you’d like to back-date these settings. This is because Multitudes takes team member histories into account, and remembers things like when team members moved teams, joined the organization, or changed timezones or working hours. If you’d like your changes to apply for all time, click “Yes, back-date these changes”. More information on back-dating working hour preferences can be found here.
*The Page Disruptions metric requires an IMS integration like PagerDuty, so make sure you’ve got that set up as well to get this wellbeing metric (Opsgenie coming soon)!
⚡️ Action: Customize your targets
The default targets in Multitudes are in line with DORA industry benchmarks. These determine the green “target zones” and insight text that you see on most charts, and other indicators of how the team is going like the thumbs on our At-a-glance table in My Insights or the emojis our the Slack Trend Summary.
However, all teams are different. Often you are working within specific contexts like a legacy codebase, or ramping up a newly formed team. For these reasons, we recommend customizing your targets. You can do that in Settings > Targets.
This is a good opportunity to have a conversation with your team about the goals you want to strive for. Ask your team, “Which metrics are most relevant for us right now? What would be a good target to strive for?”. You can check back & update these goals in future retros for accountability & continuous improvement.
We love feedback, so just let us know if you have questions or feedback as you go – either by joining our Tech Leader Chats community or by contacting us.
