Measuring & Increasing Software Engineering Productivity

Measuring productivity is not the same across teams. An accounting team might track its productivity by the number of invoices processed per month, whereas a sales team might track its productivity by the number of deals closed per month. 

For engineering teams, productivity is tracked very differently. And if you’re working in a SaaS (software as a service)-based company, the productivity of your engineering team is a critical measure that is directly correlated with your company’s overall growth goals. Knowing how to measure and increase output from your team means that you can support your organization’s plans to scale upwards.

• Why measure software engineering productivity?
• Engineer productivity metric examples
• The SPACE framework
• Problems with measuring software productivity
• Ways to improve developer productivity

Why measure software engineering productivity? 

When you can measure how well your team is performing today, you equip yourself with the data to see if your team is truly performing better in the future. Measuring productivity enables you and your team members to have a benchmark for continuous improvement, which you can also use to hold team members accountable on their growth goals. Without a quantifiable metric in place, it becomes difficult to measure productivity or ensure accountability.

Additionally, measuring software engineering productivity can help you identify specific areas in which your team needs improvement the most, so it helps you to build targeted goals for your team.

Engineer productivity metric examples

Measuring engineering productivity might not be natural or easy for some, so we’ve put together a few examples of what you could measure:

• Lead time from feature description to implementation in production.
• Cycle time, which measures the full amount of time it takes your team, or a member of your team, to complete a specific task from start to finish.
• Amount of context switching, which looks at the number of times a member needs to switch from one task to another due to challenges in a project.
• Deploy frequency or the number of times that code is deployed to production within a given timeframe.

The SPACE framework 

Developed by Nicole Forsgren, Margaret-Anne Story, and several Microsoft researchers, the SPACE framework considers five important factors:

• Satisfaction and well-being
• Performance
• Activity
• Communication and Collaboration
• Efficiency and flow

Satisfaction and well-being

• How much are your employees enjoying their jobs?
• Do your team members feel motivated and purpose in their roles?
• Do your employees have the tools and resources needed to conduct their work?
• Are there preventative measures in place (such as work-life balance policies) to ensure that employees don’t experience burnout?

Performance

• How reliable is your team?
• How often are bugs found in code, and what is the severity of these bugs?
• Are customers satisfied with your products?
• How quickly are your products being adopted by customers?

Activity

• How many times a week is your code reviewed?
• How many times a week is your code deployed?
• Does your team have formal processes for quality assurance testing or incident response mitigation?

Communication and Collaboration

• Did every member of your team receive a thorough onboarding?
• Does your team have an organized internal communication channel?
• How frequently do your team members check in with each other?
• What happens when there is a problem in the group?

Efficiency and flow

• How many hand-offs are required in the software development life cycle?
• How often are employees engaging in context switching?
• What is your average cycle time?

Problems with measuring software productivity 

1. Many metrics correlate weakly with revenue. If you can’t justify how a change in process will improve the company’s revenue, it can be hard to demonstrate return on investment (ROI) for your proposed efforts. This includes efforts like team communication or the number of hand-offs in a project, which don’t directly tie to revenue (but which impact other directly contributing factors).
2. Some metrics are difficult to attribute to performance. Some metrics, such as the amount of context switching, might not actually measure employee performance. For example, context switching may be due to external factors like new customer requests or a delay in obtaining project resources. 
3. Some metrics penalize performance. Time-based metrics can encourage employees to rush through projects and ultimately decrease the quality of results (therefore, improving one metric will cause another to decrease). For example, asking employees to deploy code faster can cause an increase in the number of bugs. 

Ways to improve developer productivity 

• Focus on outcomes
• Measure teams, not individuals
• Build onto current workflows
• Implement feature flags
• Have regular one-on-one meetings
• Give and receive feedback

1 Focus on outcomes

Different employees have different ways of working. Applying metrics to the process might force employees to work differently than their most productive or comfortable method, which can ultimately lead to a decrease in the quality of results. 

Instead, trust your team members to work in the ways that are best for them, and measure them on the results. For example, this can mean allowing your team to work during the hours that are most beneficial for them, avoiding pressuring the team to meet specific time-based metrics if possible, and getting regular status updates on project results rather than practicing always-on supervision. 

2 Measure teams, not individuals

The success of your application depends on all the members of your team. Even if one individual falls short on productivity short-term, having good communication processes and ways to work around the issue will ensure that your goals are still met on time. 

Putting a team focus on metrics encourages your developers to work well together. This includes effectively sharing and delegating tasks, communicating project updates or blockers, and building a knowledge-sharing base. Through this, hopefully your team will also develop new knowledge and skills to further their professional development.

3 Build onto current workflows

Rather than overhauling your entire system, consider building onto your current workflows. Optimizing what’s already there makes it easier for your team to adapt. Over the long-term, you can slowly optimize your full system towards a completely different system—but this change should not be made overnight. Making changes too quickly will decrease productivity as change adds more learning time for your developers.

When making any new changes to the process, bring your team into a meeting to discuss the upcoming changes well ahead of when you plan to adopt the updates. Also, include an explanation of why these changes are happening so your team has contextual understanding of the purpose of their new projects.

4 Implement feature flags

Feature flags is a software development practice of turning code functionality on/off without deploying it. This is also called feature toggling. 

Some benefits of using feature flags include lowering risk through “soft rollouts,” and enabling teams to modify the system’s behavior without requiring a disruptive merge and deployment of new code. Additionally, it can help your team validate feature functionality by enabling quality assurance (QA) testing—ensuring that your code deploy has fewer bugs and keeping productivity high.

5 Have regular one-on-one meetings 

One-on-one meetings are a great time for a manager to check in with each team member individually. These meetings are usually held weekly or biweekly, depending on the project cadence, complexity of the work, and the experience level of the individual contributor. 

Even though you should be measuring team-level metrics for productivity, individual contributions will still have a big impact on team results. Improving employee well-being and satisfaction by fostering work-life balance, providing sufficient career development opportunities, and providing support on blockers can all increase an individual’s productivity, therefore increasing the team’s.

6 Give and receive feedback

Being able to give and receive feedback is an underrated trait of a great manager. Giving feedback helps your team see where to improve on their work. Likewise, creating a safe environment for employees to provide feedback to you can further improve the overall productivity of the team. If your developers have trust in you as a leader to take feedback and implement it towards optimizing team processes, you have a much better chance at fostering a strong, creative, value-driving team environment. 

If you aren’t actively giving and receiving constructive feedback across your team yet, try adding feedback as an action item in your one-on-ones. As well, you can consider adopting sprint retrospective meetings which look back at your latest software sprint to see what went well or not so well, with the purpose of improving the next sprint.

Parting advice

Whether you’re a new engineering manager or you’ve been working with your team for a long time, it’s never too early to start applying metrics to your team’s performance. Doing so can help you build strong, repeatable processes to scale high-quality development. As your engineering team grows stronger, your products will be adopted faster and company revenue will grow as well—a result that your C-level executives are sure to love!