We’ve added support for nesting groups within groups, allowing you to more easily visualize data according to your organization's structure. Changes to child groups will be reflected in parent groups, reducing the time required to manage and update groups.

Here’s a quick overview of the improvements you’ll see across the platform:

Nested Group Filter

The group filter is now organized by group hierarchy, allowing you to navigate through groups according to your organization’s structure.

Drilldowns

Filtering to a parent group also displays child groups within the group breakdown table, allowing you to more easily compare metrics across groups.

Group Settings

You can now assign child groups to a parent group. Parent groups will automatically inherit the members and repositories assigned to child groups.

Here’s an example of how it all works:

• You create a group called Product Engineering.
• You add three child groups to Product Engineering: Mobile App, Web App, and APIs.
• Product Engineering inherits the members and repositories assigned to each of the three child groups. That means removing a member or repository from a child group will also remove them from the parent group.
• You can assign additional members directly to Product Engineering (e.g., Managers or Staff Engineers that might oversee all three teams) without affecting child member inheritance.
• If you choose to assign repositories to Product Engineering, repositories will not be inherited from child groups. This allows you to ignore contributions to certain child group repositories that may not be representative of the parent group’s work.
• Members can have multiple membership records. For example, if someone leaves and then rejoins a team, you can set join and departure dates to accurately capture that member’s tenure and contributions on each team.

Child Membership Updates for Imported Groups (GitHub Teams and GitLab Groups)

• Previously, members of a child group were automatically added as direct members to the parent group.
• With this update, child group members are now shown as inherited members of the parent group instead of being added directly.
• To support this change, their former direct memberships were marked as “removed,” which is why they now appear in the Past members list.
• This change will have no effect on your data.

These updates give you more control and visibility into group structures and history—especially useful for large or dynamic teams.

If you have questions, please reach out to us at support@software.com.

We’ve rolled out an important update to our role-based permissions to give you more control over your organization's security and settings. These changes are designed to ensure that only Admins can modify critical settings, providing clearer roles and better control over your organization's workspace.

Here’s a summary of what has changed for the Member role:

• Organization Settings: Members can no longer edit organization-level settings (e.g., display name, industry reference class).
• Git User Management: Members can view the Git Users list, but cannot change user exclusions.
• Strategic Events: Access to the Strategic Events tab is now restricted, unless an Admin has granted access to Comparisons.
• Billing & Connected Apps: The Billing and Connected Apps tabs are now only visible to Admins.

Our updated documentation on roles and permissions can be found here.

As we continue to improve our role-based access controls, these changes will ensure that your organization's data and settings are secure by default. If you have questions, please reach out to us at support@software.com.

We’re excited to announce that our Developer Insights page now supports organizations using Azure DevOps. Previously, this feature was only available for GitHub, Bitbucket, and GitLab (cloud) users. 

Developer Insights provides personalized metrics that give you a deeper understanding of your engineering contributions. These insights are designed to help you understand your impact, spot bottlenecks, and continuously improve your development workflow.

Only you can see your Insights page. You can download your report if you'd like to share.

We've made a few small fixes and improvements to the Deployments report:

• Slowest and Least Successful Deployments: To provide you with more relevant and timely insights, Slowest Deployments and Least Successful Deployments will now reflect data from the last complete month instead of the last three months.
• Highlights: The 3-month rolling averages no longer include the in-progress period, providing a more accurate representation of historical performance.
• More Accurate Group Representation: When selecting a Git provider group (e.g. a GitHub team), data starts after the group was created, providing a more representative group history. This matches the behavior on newer reports, like the KPI report.
• Time to Deploy: We’ve corrected a discrepancy in Time to Deploy between the Deployments report and KPIs report. This adjustment ensures that the Time to Deploy metric now aligns with the drilldown and KPI views.
• Batch Size: We've resolved a bug affecting a small number of teams where line changes may have been counted twice.

 If you have questions, please reach out to us at support@software.com.

We have corrected an issue in the weekly group email report to ensure it consistently displays the most recent week’s data. This resolves a problem where reports sent in May and June inadvertently showed data from a prior week. No other reports were affected.

We have released a fix and added enhanced monitoring to prevent this from happening again. We apologize for any confusion this may have caused.

We’ve made a few important updates to improve groups—including more robust configurations, easier management, and clearer representation of memberships. There is no change to any of your metrics as a result of these changes.

—

New Membership History

Set a Join and/or Departure date on a group member to limit their data to a specific window of time. Members with a Departure date can be found under the Past tab under Members.

Use this feature to more accurately reflect teams where members are changing over time. You can also exclude data for managers that were previously ICs while retaining the data before they changed roles. To compare AI coding tools, use this feature to limit data for each developer in the group to after they started using the tool.

History of members joining or departing a group is automatically retained for teams synced from your Git provider (e.g. GitHub Teams). You will now see Join and Departure dates displayed for members of these synced groups. There is no change to your metrics as a result of this change, unless you choose to manually modify Join and Departure dates.

Faster, More Efficient Group Management

We’ve implemented a faster, more efficient user interface for adding members to groups. You can now add members to groups from the Git Users page.

You can add multiple membership records for a single user, spanning different periods of time. Use this feature to capture users that joined, left, and then rejoined a group. There is no change to bulk add or delete members from a group, aside from a small change to the terminology (“delete” vs. “remove”).

Clearer Representation of Group Membership

Group membership counts—as shown next to each group for context—have been updated to include Git users marked as excluded (e.g. managers) or bots. Previously, these users were not included in the count.

Contextual member counts are no longer displayed for groups in KPIs, Leading Indicators, and Comparisons to avoid confusion. Instead, a count of developers—anyone who created a pull request in the last 90 days—is now shown for metric drilldowns when it is relevant, such as for New Deliveries per Developer, Code Review Participation, and Open Pull Requests per Developer.

As a reminder, you can exclude pull requests created by a user (e.g. managers, product managers, designers, and other Git users outside of engineering). Reviews and approvals from these users will still count towards the progress of your pull requests to preserve accuracy (e.g. calculating Time to Review), but they will not factor into contributor-based metrics (e.g., Developer, Reviewer, and Contributor counts). You can also exclude all pull request activity for a specific user. Their reviews and other pull request activity are not factored into any metrics.

—

These changes aim to provide more accurate data and a more intuitive interface for managing group memberships. If you have questions, please reach out to us at support@software.com.

We recently released Leading Indicators to help you identify your top constraint. Now, we're giving you a powerful way to take action on those insights. Introducing Objectives—a new feature designed to help you set, track, and achieve improvement goals directly against your biggest bottlenecks.

Once you've identified your top constraint, you can set a clear, measurable objective against the corresponding Leading Indicator. From there, you can conduct data-driven reviews of your progress with insights on key trends and performance, helping you optimize your efforts and unblock your team.

Objectives create a clear path from actionable inputs (Leading Indicators) to better outcomes (your KPIs). By setting a goal against a specific constraint, you can confidently drive measurable improvements throughout your entire development process.

Ready to set your first objective? Schedule time with us to review your top constraint and define a goal together, or feel free to reach out to us at support@software.com.

We recently identified and addressed a discrepancy in our Deployment Frequency calculation on the KPIs page. Over the last week (approximately May 20th - May 27th), the metric did not include deployments that exclusively contained pull requests authored by excluded users and bots. This behavior has been changed, providing an accurate count of deployments.

We’ve made several improvements to make it more clear how we track Git users and added support for excluding pull requests created by specific users. 

Git Users include anyone in your GitHub, GitLab, Bitbucket, or Azure DevOps organization. You can view a list of Git Users in your organization’s Settings under the Git Users tab.

Git Users include both Current and Past users contributing to repositories in your organization. Past Git Users are included in your historical data.

You can manually exclude pull requests created by managers, product managers, designers, and other Git users outside of engineering. Reviews and approvals from these users will still count towards the progress of your pull requests to preserve accuracy (e.g. calculating Time to Review), but they will not factor into contributor-based metrics (e.g., Developer, Reviewer, and Contributor counts).

Pull requests created by bots are automatically excluded from your data. Their reviews and other pull request activity are not factored into any metrics. If we are unable to automatically detect bots in your Git organization, you can manually exclude all pull request activity from those users.

Open source contributors are also automatically excluded from your data. An open source contributor is any user that is not an organization member and only contributes to public repositories.

If you have any questions, please reach out to us at support@software.com.

To ensure your lead time metrics reflect work that is actively in the review and merge pipeline, we've refined how draft pull requests are handled. All stages, including "Time to Approve," now consistently exclude drafts, giving you a cleaner signal on the efficiency of your active development efforts (note: there is no change to how “Time to Review” is calculated, which still starts when a pull request is opened or marked as ready for review).

These updates are designed to give you a truer, more actionable understanding of your team's development velocity. If you have any questions, please reach out to us at support@software.com.