Software.com Overview
Measuring Productivity and the Theory of Constraints
This guide outlines how your company and engineering teams can use data to measure and improve developer productivity. We’ll begin by exploring the core principles behind effective engineering metrics, then demonstrate how our product helps you put these concepts into action.
Deliver Working Software Frequently
Software.com is built around the foundational principles of agile development, supporting organizations as they evolve toward faster, more efficient software delivery — from adopting agile and DevOps to implementing CI/CD and beyond.
A key principle of agile methodology is the frequent delivery of working software. Software.com helps you optimize the flow of completed work across your entire development lifecycle, enabling continuous improvement and measurable progress for your team.
Rapid Acceleration of Deploys
While the core tenets of agile remain the same, what’s now possible under those principles has dramatically expanded. Over the past two decades, we have seen a rapid acceleration in code deployment. Companies shifted from waterfall to agile, then to DevOps, and now operate in the world of CI/CD.
Frequent delivery once meant shipping every few weeks — today, it can mean deploying changes continuously, at any scale. Advancements in generative AI are further accelerating this transformation.
Companies like Meta and Google exemplify this shift to faster software delivery. They reached a high rate of innovation not seen before, deploying new software millions of times per year. These teams aren’t just moving fast — they’ve built systems, culture, and processes to unlock the full potential of their engineering teams.
Software.com is built on the same principles: enabling any team to achieve their maximum rate of software development by focusing on flow, feedback, and continuous improvement.
Top KPI: New Deliveries per Developer
While our product gives you visibility into deployments, it’s important to understand that deployment frequency alone doesn’t capture the full picture of engineering productivity. Teams can deploy frequently and still not deliver new value to its customers—bogged down by code churn and rework.
That’s why we track New Deliveries. New deliveries are calculated by multiplying the number of pull requests by the percentage of new code they contain. They represent the new, original component of your pull requests as they move through to production.
By design, New Deliveries introduces a vital quality balance to deployments. Time spent on rework or refactoring that doesn’t introduce new functionality won’t contribute to the metric.
Among the many KPIs you can track, New Deliveries is the most meaningful, because it measures the real value—net new innovation—your team delivers to the business. It’s a universal metric that can be tracked consistently across teams, projects, and even organizations.
How We Measure Deliveries
When measuring New Deliveries, we automatically ignore pull requests in development workflows—such as dependency updates, back merges, and releases—that are not representative of developer productivity. For instance, this includes pull requests authored by bots (e.g. dependency updates), back merges to sync changes from your default branch, release branches that don’t have any unique commits, and long-lived feature branches with more than three authors.
New Deliveries also excludes changes to manifest files (e.g. package.json, gemfiles). Changes to these files often represent infrastructure, configuration, or dependency updates rather than direct feature development.
Optimal New Deliveries per Developer
Data from over 700,000 developers and 10,000 companies shows that shipping 10+ new deliveries per developer per month is the optimal rate companies can sustainably achieve. This roughly translates to shipping one pull request per developer per day, assuming half of pull request changes are new over a 20-workday month.
Theory of Constraints
Our approach to productivity is fundamentally a systems approach. The entire SDLC matters—tools, processes, and collaboration impact total productivity. The primary benefit you’ll get from our platform comes from identifying and addressing systemic blockers that impede the flow of work for your entire team.
To do this effectively, we rely on a proven framework: the Theory of Constraints. With so much data, it can be challenging to pinpoint latent, unreleased productivity. The Theory of Constraints provides a clear roadmap for where to invest your efforts.
It’s based on the idea that every system has at least one bottleneck that limits its ability to achieve its goals. You can only meaningfully improve the performance of the entire system by identifying and releasing your biggest constraint. Trying to optimize other parts of the system that are not your biggest constraint will have little or no impact on overall productivity.
By removing your biggest constraint, you will unlock the most significant improvements in productivity. Our product, particularly Leading Indicators and Objectives, help you set, track, and achieve improvement goals directly against those constraints.
Next, read Identify and Release Your Biggest Constraint to learn how to find your team bottleneck and set an objective.