You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 9 minutes
Key takeaways:
- Measure friction alongside output: half an hour a day lost to pipeline delays and troubleshooting costs a 50-developer team about 125 engineering hours a week.
- Design systems that explain their failures with clear diagnostics and documented fixes that let developers resolve common problems without waiting on another team.
- Faster coding moves the bottleneck downstream. If AI cuts coding time by 40% while your pipeline stays slow, delivery won’t speed up to match.
Engineering organizations have spent years trying to measure developer productivity. Leaders track code commits, pull requests, deployment frequency, cycle times, and increasingly, the amount of code generated with AI assistance.
These metrics provide useful insights into engineering activity, but they often overlook a more fundamental question: how much time do developers lose because the engineering environment makes their work unnecessarily difficult?
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
The productivity problem engineering leaders often overlook
Engineering leaders must shift their focus from measuring developer output to understanding developer frustration with the productivity dashboards they currently use.
These dashboards usually do not show any of the time and effort that is wasted by developers waiting for CICD pipelines, trying to resolve failed builds, trying to figure out why there are errors in their code, or coordinating with other teams to fix infrastructure issues.
The objective should be to build engineering environments that allow developers to work effectively and not simply to make developers work faster.
Developer output is not effectiveness
One of the most common misconceptions in engineering leadership is that developer productivity depends primarily on how quickly engineers write code. However, writing code is only one part of delivering software.
A programmer will be responsible for the development of a software application, as well as build, test, integration, deploy, diagnosis of failure, and maintenance of an application. The process of developing a software application is dependent upon tools, infrastructure, documentation, and/or procedures that can either aid in or impede progress.
Consider two engineering teams:
- Team A generates 100 pull requests weekly but has poor reliability with their builds, long times to complete deployment, and frequent disruptions in their production environment.
- Team B generates 70 pull requests weekly but has an efficient pipeline to test and can rely on diagnostic methods with very little interference with their operations.
Which team is more productive?
Pull request volumes do not determine whether or not a team is delivering the greatest amount of business value. In addition to possibly having lower amounts of rework and fewer delays than team A, Team B can have sustainable engineering processes.
Developer output measures activity. Developer effectiveness measures the level at which an engineer can convert their engineering efforts into successful results.
As organizations continue to invest in tools for automation and AI-assisted development, the difference between developer output and developer effectiveness will grow in importance.
More like this
The unseen costs of developer friction
Friction experienced by developers is defined as the wasted effort, delay, and cognitive load on engineers throughout the development, test, deployment, and maintenance process of software due to inefficiencies.
These are generally caused by small problems that occur during operations that teams either become accustomed to or tolerate overtime.
Some of the most common sources include:
- Slow CI/CD pipelines: developers must wait for pipeline validation (builds/tests/deployment) so they can continue their own work.
- Queue build delay: there is limited runner or infrastructure available to delay build runs.
- Flaky tests: unpredictable test results require developers to run their pipelines again and spend time investigating failures that were not caused by the developer’s changes.
- Repeated build failures: teams repeatedly fix known problems due to a lack of a permanent solution or documented workaround.
- Poor error messages: generic failure messages provide very little actionable information causing additional investigative time.
- Troubleshooting difficulties: incomplete or missing log information, inconsistencies in testing environment, and missing diagnostics information cause unnecessary complexity when attempting to diagnose a problem.
- Stale documentation: engineers rely upon “tribal” knowledge as the current troubleshooting guides do not accurately reflect the current system.
- Dependencies across teams: developers wait for approvals, permissions, infrastructure modifications, or specific support from another team.
For example, if 50 developers lose just 30 minutes daily to avoid pipeline delays and troubleshooting, the organization loses approximately 125 engineering hours every five-day working week.
Those represent greater than three (full time) engineering weeks of available capacity lost each week.
However, these losses are generally not reflected in typical productivity reports.
Supportability engineering: design systems that are easy to repair
Although organizations typically spend a significant amount of money on reliability engineering to reduce failures and increase overall system availability, it’s simply not possible to design out all potential failures.
Therefore, an equally important engineering goal is designing systems which are easier to understand, diagnose, fix, and restore from when they do fail. This is where supportability engineering comes into play.
Supportability engineering addresses the need to minimize the effort required to discover, comprehend, and resolve operational issues at every stage of the software development cycle.
In other words, supportability engineering provides a way for the troubleshooting capabilities of your engineering platform to be treated as intentional engineering components rather than afterthoughts.
An effective supportability engineering platform will provide:
Actionable diagnostics
Diagnostics (logs and/or monitoring) are expected to provide actionable information about which part of an application failed, in which component (i.e. service), with sufficient detail to allow for identification of the root cause(s). If a system simply produces “build failed,” as opposed to providing meaningful diagnostic data, then additional effort will be needed by the development team to investigate why this occurred.
Meaningful error messages
Error messages need to help developers move towards resolution. Categories of failures, relevant configuration data, and suggestions of how to correct the failure can greatly increase the speed at which failures can be resolved.
Troubleshooting without support
Where possible, developers should have the ability to resolve their own most common problems, without having to continually rely on platform engineering/DevOps/infrastructure support teams.
Operational knowledge
All troubleshooting guides, documentation of known issues, recovery processes, and all other previously established solutions should be documented and accessible. Documentation regarding past solutions should exist beyond those developers who created these solutions.
Automated recovery mechanisms
Any number of automated retry logic, environment validations, dependency check logic, and/or standardized recovery workflow logic can decrease the amount of manual intervention required to solve failures and improve overall speed to resolution.
Ultimately, the purpose behind creating systems that fail less often is secondary to creating systems that can clearly articulate their failures to users.
Therefore, through the practice of supportability engineering, we are increasing the impact on our developers’ productivity, reducing uncertainty in delivery timelines, and enhancing the operational resiliency of our applications.
New York • September 8 & 9, 2027
Loved LDX3 New York? Pre-sale tickets for 2027 are now available.
A practical framework for measuring developer friction
Engineering leaders do not need to abandon existing delivery metrics. They need to complement them with measurements that expose operational obstacles.
A useful developer friction framework can focus on five dimensions. Engineering leadership can use these numbers to determine answers to typical questions which most standard productivity tracking tools cannot provide.
What percent of developer time are developers spending doing things that do not produce progress? What types of failures consistently occur in the way that engineering work is done? How many engineers have issues related to each other? Are teams continually addressing and removing problems, or are they repeatedly using quick fixes (temporary solutions) until the real fix is made?
One of the easiest places to start would be calculating friction costs: developer friction costs = the frequency of an issue * the amount of time lost when dealing with the issue * the number of developers impacted by the issue
For example, if there was a recurring pipeline failure occurring two times per week, impacting 20 developers at a minimum, taking an average of 25 minutes to troubleshoot, this would equate to about 16.7 hours of engineering effort lost each week.
This type of calculation will not give you a perfect picture of your team’s productivity, but it can allow you to focus resources on areas that have the biggest operational impact.
In addition to estimating friction costs, engineering leadership must differentiate between avoidable friction and needed engineering activities.
For instance, all code created must go through a full cycle of testing. Security validations are needed. Code reviews need to happen. All of these are legitimate uses of engineering that need to be accounted for. The objective is to eliminate extraneous barriers to production and not sacrifice quality.
Ultimately, the purpose of these metrics is to drive changes to processes and systems and not to evaluate individual contributors.
AI speeds Up coding but it won’t remove every roadblock
Assistance via AI for developing applications creates new ways in which software can be developed.
Coding assistance programs can generate functions, implement existing ideas, define previously unknown code, and repeat tasks associated with coding repeatedly.
All of these potential benefits can result in reduced time spent by developers writing code.
However, increased speed in writing code does not automatically translate to increased speed in delivering applications.
Consider a company where AI assists in cutting down the coding time of its staff members by 40%. The company’s CI/CD pipeline still takes 45 minutes. Tests run poorly more frequently than expected. Deployment errors cause hours of investigation and debugging. In this case, the company improved the first stage of the application development process by accelerating it, yet left every other stage in place.
This demonstrates a key concept: optimizing coding productivity without enhancing the overall engineering system shifts the bottleneck down stream. Therefore, the next great challenge for AI in engineering may well extend beyond assisting developers with generating code.
Possible opportunities include utilizing AI-assisted diagnostics, AI-driven failure identification systems, systems to assist with finding the underlying causes of failures, search-based diagnostic systems, and systems providing step-by-step guidance for recovery from failures to assist with reducing friction experienced by developers throughout the entire delivery life cycle.
However, such systems must remain grounded in solid data used for diagnostic purposes. Additionally, humans must maintain sufficient oversight authority for high-stakes recovery decisions.
The largest advantage of using AI-enabled engineering support will likely lie not only in enabling developers to write more code but also in allowing developers to spend less time trying to figure out why their systems failed.
The leadership mindset change
Engineering leadership should certainly continue to track delivery performance, reliability, and business results. These are essential metrics.
However, they should also acknowledge that developers work within large-scale engineering systems. Ultimately, how effectively those systems’ function affects what developers are able to achieve.
If an organization’s pipeline is moving slowly, it is not just a convenience issue for developers – it is a systemic efficiency problem. If there are recurring build failures occurring for an organization’s developers, it is not just a simple technical deficiency. It represents wasted developer effort that could be utilized to develop something more valuable. Poor diagnostics and lack of documentation represent significant operational shortcomings.
Ultimately, engineering leadership should focus on a different question. Instead of asking “how can we make developers produce more?” ask “what is preventing our developers from making progress, and how can we remove it?”
After all, the most effective way to improve developer productivity is not always to make developers faster. It is to stop making them wait.
