Many tech startups experience rapid growth. This means they have to scale and develop many new features quickly. Often, these startups put an excessive focus on growth while trying to not lose sight of code quality. On top of that, rapid onboarding puts further stress on the engineering team to keep technical debt at a minimum. For many tech startups, the combination of rapid growth and technical debt slowly kills engineering productivity.
It may be hard to detect that your team’s engineering productivity is starting to slow down. However, you can measure several metrics to define engineering productivity and detect the early indicators of reduced productivity.
This article explores how engineering productivity works, how to measure it, why measuring it is essential, and step for improvement.
But first, let’s take a look at a definition for engineering productivity.
What Is the Engineering Productivity Paradigm?
The engineering productivity paradigm tries to measure and optimize the engineering process by tracking various engineering-related metrics. The goal here is threefold:
- Identify problems within the engineering process
- Reduce the time needed for the engineering team to deliver new features
- Allow for experimentation with different processes, techniques, and tools to further improve the engineering process.
Asim Husain, VP of Engineering at Google, explains engineering productivity’s impact on Google’s product delivery.
“It’s humbling to see how engineering productivity has improved so many products and teams across Google through innovative infrastructure and engineering rigor. When you work in Engineering Productivity at Google, you can see your impact: better products, faster releases, and greater reliability.”
You might wonder how to measure the productivity of developers. It’s not easy to track data related to a particular job and draw conclusions from that data without a Software Delivery Intelligence solution. Imagine trying to measure the productivity of a doctor. You could measure the number of patients they work on, but this isn’t the best approach. By focusing solely on the number of patients, you’ll may find that they work on a lot of cases, but the quality of their work suffers because they are trying to do too much.
Now imagine that you tell your developers to finish as many features as possible. What will you get? Developers who deliver many more features, but with lower quality. For instance, features will have lower test coverage, or developers will spend less time on the architecture. On top of that, you’ll create a competitive environment among developers. This won’t improve your team’s cohesion or overall happiness.
What am I trying to tell you? Try to resist the temptation to focus solely on the volume of work. It’s better to focus on team-based metrics that reflect output. So, how does it work?
How Does Engineering Productivity Work?
The engineering productivity approach starts with measuring data. This data will form the basis for comparisons. I suggest you don’t change anything about your current engineering process before you can collect four weeks’ worth of data about your processes. You want to have sufficient historical data to make comparisons. On top of that, many teams work in sprints of two weeks, so four weeks of data allows you to collect data for at least two sprints.
Next, we want to make gradual changes to the engineering process to see what improves or slows down the development team. It’s best to only experiment with one change at a time so that you can see the effect of each change, with all other things being equal.
For instance, if your development team suffers from technical debt, you may decide to implement an extra task related to feature completion. Every time a developer completes a new feature, they must document the new feature. This might mean describing the feature and the reasoning behind the design decisions.
By continuously measuring engineering productivity metrics, you can determine if this change has positively impacted the developers’ productivity.
How Is Engineering Productivity Measured?
Here are four key metrics that will help you to get started with measuring engineering productivity.
1. Cycle Time
Software development cycle time measures the amount of time from work started to work delivered. It is a metric borrowed from lean manufacturing, and it is one of the most important metrics for software development teams. In plain speak, cycle time measures the amount of time from first commit to production release.
2. Deployment Frequency
You want to measure how often you deploy new changes to your production environment. Furthermore, you enrich your data by tracking deployments to various branches, such as feature branches, hotfix branches, or QA branches. This data can show you how long it takes for features to move through the different development stages. In addition, the deployment frequency reflects the throughput of your team. It’s a great metric to keep track of your team’s velocity.
3. Number of Bugs
Make sure to track the number of bugs that your team has to resolve within four weeks of completing a feature. This metric helps you to understand the quality of your code better. Higher-quality code should display fewer bugs after feature deployment.
4. Review to Merge Time (RTMT)
This is an interesting metric suggested by GitLab’s development handbook. You want to measure the time between asking for a pull request (PR) review and merging the PR. Ideally, you want to reduce the time a feature spends in the review state. A high RTMT prevents developers from progressing while they wait for feedback and encourages context switching between different issues.
So, why would you measure all these engineering productivity metrics?
Why Is Measuring Engineering Productivity Important?
When a tech startup grows rapidly, it’s important to keep an eye on engineering productivity. It frequently happens that these startups start to favor growth through feature delivery over effectively scaling the engineering team and ensuring the team’s efficiency.
In these cases, technical debt can quickly grow, which will slowly kill your team’s productivity. Technical debt can have many negative consequences:
- More bugs for your team to fix
- Lower code quality—not only bugs but also worse code design
- Harder to debug code
- A decline in overall happiness and job satisfaction
To avoid all of these scenarios, we want to measure the engineering team’s efficiency and avoid technical debt buildup. Avoiding these problems before they occur will have a significant impact on your organization, not only time-wise, but also cost-wise!
In addition to preventing your team’s productivity from slowing down, the engineering productivity approach allows you to safely conduct experiments to improve your team’s efficiency. Therefore, the goal is to improve the engineering process itself, by for example, introducing new tools or applying new techniques. Next, you can measure the impact of these changes on your team’s productivity.
How Can You Improve Engineering Productivity?
To recap, there are various ways to improve engineering productivity. For example as we mentioned above, you can implement a process change that requires developers to document new features.
Next, you want to set a hypothesis you can test when you implement a process change. In this case, we can easily formulate a hypothesis: Documenting new features will reduce technical debt.
Now, you want to pick a couple of metrics that can prove your hypothesis that a change improves your productivity. For instance, if the cycle time improves, it can indicate that you’ve reduced technical debt.
To get a better overview and spend less time tracking metrics, it’s a great idea to use a tool like LinearB. Software Delivery Intelligence tools helps you to automate your metrics program so you can drive continuous team improvement. They also offer many visualizations that make it easier for you to test hypotheses and draw conclusions.
One of the most exciting metrics they suggest tracking is the rework ratio. “Rework ratio measures the percentage of your code that is being rewritten within 21 days of being merged. It’s a predictor measurement of downstream quality issues or an indication that a requirement was missed.”
To conclude, make sure to measure the right data and test your hypotheses one at a time. It’s vital to base your decisions on data and not on feeling.
Ready to start tracking the metrics that will uncover opportunities to boost engineering productivity? Sign up free for LinearB.