In the pursuit of engineering excellence, the volume of code shipped is often seen as a hallmark of productivity.
However, this perception can be misleading. A team may appear highly productive, consistently delivering large quantities of code, but this doesn't necessarily equate to efficiency or value creation.
The real measure of productivity lies in the impact of the code on project goals, user satisfaction, business outcomes, and the ability to meet deadlines without compromising quality.
Understanding the nuances behind what truly defines productivity is crucial for teams aiming to optimize their engineering processes for better outcomes.
In this blog, we'll explore engineering productivity, why it matters, how to measure it, and strategies you can employ today to optimize it.
What Is Engineering Productivity?
Engineering productivity can be best thought of as an organization's ability to align to the engineering leader’s dual mandate: delivering operational excellence and driving business outcomes.
In a world where every company is a software company, improving engineering productivity is a high priority for R&D and business leaders alike. An organization’s ability to bring high quality software to market quickly is one of the greatest competitive advantages in today’s business landscape. At a high level, optimizing engineering productivity is a matter of:
- Identifying workflow bottlenecks within your engineering pipeline as informed by core metrics (like DORA metrics), resource allocation data, and industry benchmarks
- Setting data-backed operational and business alignment goals using these metrics and industry insight
- Unclogging your delivery pipeline with programmable workflows that foster better collaboration, keep teams aligned to the mission, and remove friction in the pre-merge process
Following this formula helps engineering teams boost quality and efficiency–all with the same team. But more importantly, this approach drives smooth, consistent, and predictable software (read: value) delivery–which is the core of engineering productivity.
Why Is Measuring Engineering Productivity Important?
Measuring it correctly–i.e. not using lines of code as the metric–provides insights into the effectiveness and efficiency of the development process. It helps identify bottlenecks, inefficiencies, and areas for improvement. And it provides a view into how engineering is contributing to the health of the business.
On the other hand, when organizations don’t measure and optimize productivity–or measure it incorrectly, focusing on lines of code, for example–it can result in:
But if you begin without measuring software engineering productivity, you can hinder teams’ progress. Teams that aren’t working efficiently might look like they’re getting a lot of work done, but it won’t be high-quality work, and technical debt will pile up. And we all know tech debt is a productivity killer, because it results in:
- Less new value creation
- Higher CFR and MTTR
- Lower code quality and more bug work
- More tech debt and harder-to-debug code
- Decreased overall developer happiness and job satisfaction
By measuring productivity, organizations can make informed decisions to streamline workflows, optimize resource allocation, and ultimately deliver higher quality software faster with the same team. This not only improves customer satisfaction but also enhances team morale by promoting a culture of continuous improvement and achievement.
How Does Engineering Productivity Work?
Engineering productivity involves optimizing the software development process to maximize efficiency and output quality. It works by identifying and eliminating bottlenecks, streamlining workflows, and utilizing metrics to guide improvements. This approach enables teams to deliver software more quickly and with higher quality, while also fostering a culture of continuous improvement and innovation.
Want to learn more about being an elite engineering team? Check out this blog detailing our engineering benchmarks study and methodology.
We’ll cover this in more detail in just a bit but at a high level engineering productivity (and improving it) works like this:
- Measure and benchmark teams and the organization as a whole with metrics
- Set unified, data-backed goals for operational and business alignment improvement
- Use automation to improve processes and remove developer toil
- Constantly measure progress, report/celebrate success, and calibrate as needed
How NOT to Measure Productivity in Software Engineering Teams
A quick search on measuring software engineering productivity will present you with varying methods, tools, and metrics. It can be time-consuming to sift through them and determine which engineering productivity metrics will add real value to your org.
To help you navigate all that noise, we’ve identified three of the most common mistakes to avoid making when you measure engineering productivity.
1. Don’t Prioritize the "Need" for Speed
Some engineering organizations use velocity to estimate how much work their teams can do within a given timeframe. But high velocity only means work is getting done–it doesn’t distinguish between planned and unplanned work (a common bottleneck), if priority projects are resourced appropriately so devs aren’t burning out, or whether teams are working on high value initiatives (like new features). And it ignores a crucial consideration: consistency and uniformity in operational cadences.
In short, when measuring engineering productivity, don’t get stuck thinking the only thing that matters is how fast your teams get their work done. If this is all you focus on, you may end up releasing software that hasn’t been properly built or tested or isn’t actually fit for purpose.
Find out why agile velocity is the most dangerous metric for software developers. Look at 12 alternative metrics instead.
2. Don’t Measure Individual Productivity
Many engineering organizations believe devs who complete lots of story points in a sprint are productive. But here’s a scenario: what if one member of the team is highly knowledgeable in many areas of the code base and primarily conducts reviews? Are they unproductive? The short answer is no–they’re invaluable.
Measuring individual productivity in engineering can lead to a focus on short-term outputs over long-term value, potentially encouraging behavior that isn't aligned with team or organizational goals. It may overlook collaborative efforts and discourage teamwork, as individuals might prioritize tasks that enhance their metrics over those that contribute to overall success. This approach can also lead to burnout, as workers push themselves to meet quantified benchmarks at the expense of their well-being and work-life balance.
Attempting to measure engineering productivity individually, can lead to blind spots that don’t surface the real issues in your workflows or processes. Instead, measure productivity as a team dynamic to find the real bottlenecks clogging your pipelines.
3. Don’t Focus on Output-Based Metrics
Output-based metrics only quantify the amount of work your teams do and can be gamed. So focusing on metrics like story points or lines of code won’t help you understand what your teams are working on or whether their work aligns with business needs.
Instead, focus on measurements that actually give you data on productivity. These metrics will help you know when you need to make changes and where to make them rather than leading you into a false belief that your teams are on track.
4 Best Productivity Metrics in Software Engineering
Metrics can make or break how you measure software engineering productivity. We’ve rounded up the four best software engineering productivity metrics that empower you to take action with insights into when and where your workflows need work.
1. Merge Frequency
Your org’s merge frequency is the total number of pull or merge requests within a period of time. Most of the bottlenecks in a development pipeline (like lots of idle time in the PR process) occur pre-merge.
A high merge frequency indicates a healthy software delivery pipeline without PR review bottlenecks that frustrate developers and impact productivity. Put simply, merging devs are happy devs.
LinearB’s gitStream tool can help with this. It makes the PR process more efficient by automating merge approvals for small and low-risk PRs while routing larger, more complex PRs to appropriate reviewers. It can also provide more context to reviewers, show you who’s got the most knowledge of that part of the code base, flag security risks, and much more! This prevents the PR review process from getting stuck, ensuring your teams continuously merge.
Want to learn about the impact GenAI is having on software development organizations? Looking to measure the impact of your GenAI initiative? Check out this report!
2. Cycle Time
Measuring your cycle times shows you where your teams are falling behind and where issues exist in your process. Shorter cycle times mean your processes are optimized and efficient. This can result in increased more features being released, higher revenue, and better customer retention rates. Your devs will also be happier with a more efficient process.
LinearB’s engineering productivity platform breaks cycle time down into four segments: coding, pickup, review, and deploy times. You can use this information to determine exactly where you need to make changes in the software development process.
3. Accuracy Scores
Accuracy scores are invaluable for accurately forecasting project delivery. Planning accuracy measures the amount of work completed in an iteration compared to the amount of work planned. Capacity accuracy measures all completed (planned and unplanned) work as a ratio of planned work. Together, they can tell you a lot about how well your team scopes and executes on project plans.
With LinearB, engineering leaders can use the Project Delivery Tracker to view accuracy scores for projects and teams. Which when combined with operational and business alignment metrics, provide the leading and lagging indicators of on-time, in-scope project delivery. As an example, assuming your PRs are small, your cycles are fast, you’re working on the “right” things, and your projects are resourced appropriately, determining if you’ll meet a deadline comes down to Accuracy Scores.
You can see Accuracy Scores in action by booking a demo today!
4. Resource Allocation
Resource allocation measures what your teams are working on and how much each dev is working. It’s an important metric because it helps you understand how your resources are being put to work, whether you have enough resources to complete your projects, and whether the most important projects have the resources needed to be completed on time.
Investment Profile shows you how development efforts are allocated across different customizable investment categories. They also provide benchmarks based on industry best practices for each of these categories. Using this view, leaders can quickly determine if too much time is being spent on Keeping the Lights On (bug work, as an example) vs. New Value (new features or enhancements as requested by customers).
These business alignment metrics offer a comprehensive view of your initiatives, full-time employee effort, and delivery status in a single location and provide the data needed to determine the risk/benefit of moving resources around when the need arises.
How to Improve Engineering Productivity
- Build a Metrics Program: Determining an engineering organization’s current state of productivity starts with building a holistic metrics program. With visibility into key metrics, as well as context leveraging industry benchmarks from 2000+ dev teams and 3.6 million pull requests, a clear productivity picture begins to emerge.
You’ll want to be sure your metrics program also includes resource allocation and investment profile data as these inputs will help you determine business alignment–a key consideration of productivity.
- Set Improvement Goals and Reporting: After that, you can begin to set your productivity improvement goals leveraging this insight. Goals and OKRs should be set at both the team and organization level and need to align to each other. In addition to setting goals, you’ll want to build audience-specific reporting (for the business and for your engineering org) to showcase success and impact of execution against these goals.
Pro Tip: Don’t push team members to improve every metric at once. Instead, focus on one metric at a time to foster healthy growth. 😉
- After metrics are in place and goals are set, then you’ll need to adopt programmable workflows that foster better collaboration, keep teams aligned to the mission, and remove friction in the pre-merge process. These tools help devs reach their targets by automating tons of manual tasks, automating PR routing based on context, offloading reviews for small changes so they get merged quickly, and giving context to PRs via tags. These capabilities ensure quality, speed up the review process, and increase merge frequency–all of which boost engineering productivity.
