Ready to start?
Software development teams are held to high standards for engineering productivity and excellence — as user research continues to show, high quality software and user experience are a key driver of repeat business and satisfied customers. As user expectations rise, engineering teams face an increased need to prove the productivity of their teams, the sophistication of their site reliability strategies, and how they manage costs.
Engineering managers typically expect to measure their developers’ performance, but measuring their productivity and effectiveness requires a more specific set of metrics and strategies. We’ll discuss the subset of engineering metrics you can use to measure productivity, how to establish best practices for productivity, and review tools that can help you track and improve productivity.
What is engineering productivity?
Engineering productivity is a measure of your engineering effectiveness. Your team can produce a lot of code, handle incidents quickly, or even maintain immaculate documentation, but none of it means anything if it doesn’t help you achieve your business goals.
In contrast to engineering performance, which typically measures the speed, efficiency, and reliability of your software development lifecycle, engineering productivity focuses on how effective your team is at producing new value for the business. For R&D departments, producing new value can look like:
- Launching new features
- Improving high-usage flows
- Reducing time spent on tech debt or managing incidents
- Reducing developer turnover by prioritizing opportunities for meaningful work
- Lowering your change failure rate or mean time to recovery
New value can also look like making structural changes to your team’s workflows, which we’ll discuss in more detail in our section on tools.
{{cta-demo-baner}}
Why is measuring engineering productivity important?
There are two key reasons to measure your engineering productivity. The first is that without productive engineers, your software company or website will struggle to attract and retain users. This is because of the link between productivity and usability: more productive engineers are those who push new features quickly, push code regularly and successfully, and increase the user’s satisfaction with their software.
And then there is another answer: new value projects are often what development teams dream of enabling in their software development lifecycle. A happier developer is one who is satisfied with not just the speed of their production, but the quality of the code they push.
According to a recent Microsoft survey, developers report that “bad days” are mostly the result of what is referred to as “engineering system friction.” This friction arises when developers aren't able to do what they do best — write code — and are instead stuck managing routine maintenance tasks or pushing bug fixes, developers become dissatisfied.
Though these tasks are essential, spending too much time on them reduces the actual value of the website and the R&D department overall — if a website constantly needs fixing, to the point where there is little else to do, developers will grow disillusioned with their sense of value within the company. This drives up the cost of hiring new developers, while also making existing developers less productive as they need to dedicate more time to onboarding.
With this context, measuring productivity gives engineering leaders the ability to spot areas of friction early, before they significantly impact developer experience or output. These insights surface actions they can take to reduce friction, improving both engineering productivity and satisfaction simultaneously.
How to measure engineering productivity
Measuring your engineering productivity can be tackled from several perspectives — you can remove bottlenecks in your delivery pipeline or set new standards for code quality and PR reviews — but the metrics you choose should be relevant to your specific R&D team.
Engineering leaders who are interested in measuring and improving their team’s productivity have a few options for getting started. Take cues from your developers and share a survey asking about their pain points. Sit down with product managers and prioritize your roadmap against business goals.
It’s important to keep in mind that this is different from developer productivity, which is focused on the individual. Engineering productivity comprises the R&D team as a whole, focusing not just on what each person is doing, but how teams are and are not achieving their goals as a unit.
With this in mind, some ideas for metrics to use include:
- Cycle time: This accounts for the entire time it takes your team to bring new code to production, from feature pickup all the way to successful merge.
- Merge frequency: As opposed to deployment frequency, merge frequency accounts for the number of times your developers create pull requests (PRs) in aggregate. Measure this for each sprint, starting fresh after each retrospective.
- Planning accuracy scores: This is where product management comes in because they are responsible for setting sprints and planning work. Review the amount of work planned vs. completed for each sprint, and track your overall “score” to determine this metric.
- Resource allocation: Look at where, and on what, your team spends their time working. Spreading one team thin while another doesn’t have enough to do is a quick way to degrade your developer satisfaction on both sides.
{{cta_1}}
Top strategies to improve engineering productivity
Generally, tracking DORA metrics and conducting developer surveys are useful ways to begin understanding your SDLC. Working with developers individually at first may give you a clearer sense of how to resolve issues or reallocate teams with resources.
But developing a mature understanding of your operations and its quirks will require a broader scope. Surveys can’t necessarily report accurately on the underlying cause of a routinely failing service or incident — at least not the same way sophisticated alerting and monitoring tools can. Consider not only what developers think of the tools in place, but whether there are better options or configurations for your teams.
Using an internal developer portal
An internal developer portal abstracts away the complexity of deployment and promotes the use of automations to routinize work in a standard way. It also unites your SDLC data with your business context; rather than spending time trying to make connections between disparate data points, you can easily see whether a service that meets some expectations (but not all) is efficient enough, or if it needs to be revised.
With a portal in place, teams across your R&D department can use the portal to access productivity boosts:
- Developers gain a unified, end-to-end deployment experience through their entire software development pipeline. This addresses one of the most important pain points developers face — engineering system friction — which mainly refers to context switching between tools, interacting with unfamiliar coding languages, and going through inefficient processes. Self-service actions help developers ship code faster while maintaining any specific standards your larger organization adheres to.
- Team leads gain unprecedented insight into the entire SDLC, from the same UI the developers use, which means they can see real-time information about their teams’ workloads, incident responses, on-call rotation, and more, without spending time gathering this data from multiple tools. This information can also be viewed in dashboards customized by project or team, making it easier to get at-a-glance insights on productivity and reducing the need for daily meetings or check-ins.
- Engineering managers gain similar benefits to team leads, but across the entire organization. This makes it easy to report on R&D costs, resource needs and allocation, value-based development time, and more. With the benefit of custom dashboards, engineering managers can also routinely check in on key metrics with real-time data, improving reporting quality and data integrity.
Initiatives, a common feature of internal developer portals, enable managers to clearly communicate routine tasks like dependency and version updates, standards implementation and compliance, and other types of reporting. This makes it easier to drive change while also reducing the need for check-in meetings, report creation, data gathering, and performance measurement.
Boosting engineering productivity with AI and automations
Your SDLC may be inefficient because too much of it is manual. If teams are manually deploying code or conducting manual testing, they are likely spending more time than they should on other manual tasks as well. Automating deployment pipelines can help speed up cycle times, while automating notifications can help PRs get out of review in less time.
Test automation is an area where both automation and AI can help you, and should likely be done in any case to avoid the introduction of human error during testing. Automated tests can also be configured for a number of different scenarios, which adds value to each round of testing that humans can’t provide.
Though AI code generation has taken a big bite out of how much code developers need to write, it’s worth noting that the 2024 State of DevOps survey found that AI-generated code still needs extensive testing before successful deployments. It’s possible that you may want to review your developers’ use of AI in coding or create new standards for code early on to ensure the AI-generated code does not delay deployment frequency too close to reaching production.
Best tools for boosting engineering productivity
We’ve previously considered the top 10 tools for developer productivity in a separate post, which can greatly improve the day-to-day efficiency of your developers. These low-level efficiency gains add up quickly to additional development hours your teams aren’t spending performing manual tasks.
When it comes to tools that can boost your entire software development organization’s efficiency, there are some scalability factors you’ll want to consider. We compiled a list of the top 10 tools for platform engineering that offers tool recommendations and further discussion of each tool’s features, if you want to consider options.
In researching, you’ll also want to be cognizant of tool sprawl, also known as tool creep, wherein you attempt to add multiple productivity tools to boost your efficiency and instead end up managing and configuring the different systems instead of using them. When choosing tools that will help make you or your team more productive, you’ll want to consider:
- The tool’s feature set: How much can one tool do for you versus another? If you can consolidate and use one tool to achieve multiple tasks, it is likely a better (and cheaper) purchase than two separate tools
- Implementation complexity: Some tools require a lot of manual work to set up — even tools that promise efficiency gains! It’s worth taking a look at software reviews and other research about your chosen tool (if it’s available) to understand what implementation may look like for your team, tech stack, or business goals.
- Integration capabilities: If a tool can integrate with multiple parts of your tech stack or align data from multiple sources (i.e., PRs in Jira and incident reporting from incident.io), it will provide more long-term value by allowing you to gain deeper insights into your engineering performance.
- Automations: It may sound obvious, but if you can automate certain repetitive tasks out of your daily routine, you’ll gain time back for other, more important tasks like new feature development. Automation on higher levels, however, can remove the need to perform many manual steps — in the case of automated deployment pipelines, a high-level productivity strategy, teams can focus on high-priority work.
Tools that can enable two or more of these factors are likely to be better implemented, have shorter times to value, and offer more valuable insights than tools that do not meet these criteria.
Wrapping up
There is a lot to consider when choosing your tools, strategies, or combination of the two to address engineering productivity. But it’s important to keep in mind that the solution that will ultimately work best is the one that works for your team specifically. Involve your team in making decisions that affect their productivity — ask what works, what doesn’t, and what can be improved.
Port’s open internal developer portal offers flexibility by integrating with all of your systems and uniting them together in one place, making it easy to incorporate insights from multiple sources to make reporting more accurate. Port can also help with collaboration and transparency across teams: it provides fine-grained RBAC to give teams specific permissions to read or write dashboards, self-service actions that give developers autonomy to deploy new code, and a clearly defined space for tracking compliance with any standards you and your teams set.
Port also scales well, providing an easy way to create reusable actions and experiences that make it easier to onboard new developers and align teams. Check out our live demo, or book a demo with one of our team members.
Check out Port's pre-populated demo and see what it's all about.
No email required
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Check out Port's pre-populated demo and see what it's all about.
(no email required)
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Book a demo right now to check out Port's developer portal yourself
Apply to join the Beta for Port's new Backstage plugin
It's a Trap - Jenkins as Self service UI
Further reading:
Example JSON block
Order Domain
Cart System
Products System
Cart Resource
Cart API
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Component Blueprint
Resource Blueprint
API Blueprint
Domain Blueprint
System Blueprint
Microservices SDLC
Scaffold a new microservice
Deploy (canary or blue-green)
Feature flagging
Revert
Lock deployments
Add Secret
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version
Development environments
Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days
Cloud resources
Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource
SRE actions
Update pod count
Update auto-scaling group
Execute incident response runbook automation
Data Engineering
Add / Remove / Update Column to table
Run Airflow DAG
Duplicate table
Backoffice
Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer
Machine learning actions
Train model
Pre-process dataset
Deploy
A/B testing traffic route
Revert
Spin up remote Jupyter notebook
Engineering tools
Observability
Tasks management
CI/CD
On-Call management
Troubleshooting tools
DevSecOps
Runbooks
Infrastructure
Cloud Resources
K8S
Containers & Serverless
IaC
Databases
Environments
Regions
Software and more
Microservices
Docker Images
Docs
APIs
3rd parties
Runbooks
Cron jobs