Skip to main content

​
Overview

Developer productivity is the ratio of the output obtained to the input invested in development. The term covers a wide range, however: what people picture when they hear it varies from a team’s work efficiency to the value a whole product delivers. Discussions of developer productivity therefore start by making the definition explicit. First, this page organizes what developer productivity is and why improving it matters. It then covers the product goal as a premise, the definition of output and input, the three levels of productivity with measurement and initiatives for each, what improvement brings, and finally cautions when pursuing it.

​
Before talking about developer productivity

​
Start from the product’s goal

For most products built by a business, creating the product itself is not the goal; the goal is the result obtained through the product. What matters are the KPIs achieved by users adopting the product, and the revenue and profit that follow. A product that cannot support its business cannot continue. Improving developer productivity is considered on this premise: contribution to that goal.

​
Identify where to work on it

A product is built through a sequence of activities: problem discovery, planning, design, engineering, and QA. Developer productivity sometimes refers to the productivity of the product as a whole, not just engineering. If any stage is unproductive, or coordination between stages is poor, overall product productivity stays low even when engineering productivity is high. When starting small, however, the part a team can control most directly is the engineering-specific portion. Cross-organizational efforts take time for information sharing and aligning on problems, so start by raising productivity within your own scope or your team’s, then expand from there.

​
Defining developer productivity

Productivity is expressed as output obtained ÷ input invested. The output and input can take many forms. What to treat as output and input differs by organization, team, and project. What matters is making explicit what counts as output, what counts as input, and what your organization calls developer productivity. Sharing the definition and its measurement method across the whole organization, and improving continuously, leads to product success. Conversely, without a shared definition, perceptions diverge and the effort stops being understood.

​
The three levels of developer productivity

Developer productivity is viewed at three levels (Levels 1–3), defined by what counts as the “result”.

​
Level 1: Work volume productivity

Level 1 evaluates productivity purely in terms of work volume, without considering contribution to value or revenue. Because it relates directly to engineering and can be controlled by engineers alone, it is the easiest level to work on and the quickest to show visible results.

​
Measurement

Start by quantifying the daily activity of individuals and the team. Observing metrics such as the following at fixed intervals and graphing them over time reveals work volume and its trend.
  • Commits and pull requests per day
  • Average time pull requests stay open
  • Time spent on code review
  • Average time to fix bugs
  • Implementation rework rate (rework completed within implementation, such as review fixes)
  • Automated test coverage
  • Build success rate and duration

​
Improvement initiatives

  • Improving maintainability (thorough documentation, stronger unit tests, regular refactoring)
  • Automating repeated tasks such as builds and deployments
  • Making code review efficient (catching trivial errors early with linters and CI/CD)
  • Strengthening teamwork through pair programming and knowledge-sharing sessions

​
Level 2: Expected value productivity

Level 2 considers how much value each initiative brings to the product, not just the amount of work. Because the impact on actual value appears only some time after release, it focuses on how much of the expected value was released. In many cases, Scrum or agile development frameworks are used to measure how many valuable tasks were realized.

​
Measurement

Track whether the right tasks are selected and expected value flows to release without waste. Indicators such as the following can be used.
  • Share of valuable features (the proportion of developed features that actually bring value to customers or the business)
  • Lead time from idea to value delivery (time from conception until value actually reaches customers)
  • Specification rework rate (rework caused by ambiguous or changed requirements and poor coordination between stages)
  • Requirements documentation coverage and frequency of requirement changes during development

​
Improvement initiatives

  • Building a strategic roadmap that clarifies value and priority (prioritization with weighted scoring or RICE scores)
  • Validating value through market and user interviews
  • Managing risk by estimating the loss of not addressing something

​
Level 3: Realized value productivity

Level 3 evaluates concrete contribution to the actual service, such as revenue and KPIs. Raising productivity at this level is the ultimate goal, but the causal link between engineering investment and results is not always clear, which makes it the hardest level to evaluate.

​
Measurement

Track how delivered features led to business results, following the product’s KPIs. Indicators such as the following can be used.
  • Product KPIs (active user counts, conversion rates, and so on)
  • Changes in revenue and customer counts attributable to the product
  • Operating margin and infrastructure cost reduction (contribution on the cost side)
  • User satisfaction

​
Improvement initiatives

Improving Level 3 cannot be completed by engineering alone, and the right initiatives differ depending on the product and the organization’s structure. With that premise, examples include the following.
  • Define the product’s KPI tree and connect each feature or initiative, at the planning stage, to the KPI it contributes to
  • Build mechanisms to measure the adoption and effect of released features, verifying the link between initiatives and business results
  • Create cross-role feedback loops that bring the customer voice gathered by sales and customer success back into development
  • Have engineers participate in planning and problem discovery, validating the necessity and target users of a feature from the development side as well
Every one of these requires involving everyone connected to the product — product managers, designers, QA, sales, and customer success. Deep collaboration across roles is required, so even teams that reach Level 2 through mature agile development often struggle with Level 3 improvement. At every level, both kinds of understanding matter: grasping visualized results qualitatively, and knowing quantitatively how the numbers actually move. Combining quantitative data with the qualitative sense of day-to-day problems lets you see productivity from multiple angles.

​
Why improving developer productivity matters

​
Social background

In Japan, the working population is shrinking due to population decline and aging, and producing results with limited headcount requires working efficiently with the power of technology. Work-style reform that no longer assumes long hours, and the spread of DX (digital transformation) that improves business processes through digitalization, also drive the demand for productivity.

​
Background in engineering

Changes in engineering itself also call for higher productivity.

The spread of remote work

With processes no longer visible, more teams and companies focus on contribution to results, and individuals need to work efficiently.

High-quality products as the baseline

Competition with advanced products from around the world requires delivering usable, capable products faster, in response to user demand.

Standardization of technology

With growing use of OSS and external SaaS, teams need the ability to select and combine many technologies.

Data-driven product improvement

As the saying “measure, don’t guess” suggests, development is expected to combine measured facts and to visualize engineering’s own productivity as it goes.

​
What improvement brings

Improving developer productivity becomes a factor directly tied to organizational growth and success.

​
Cautions when pursuing improvement

​
Do not over-pursue it

Excessive pursuit of developer productivity causes problems such as overwork and quality degradation. It also invites behavior whose goal is protecting the numbers — rubber-stamping reviews to keep a metric from dropping, or developing locally and opening a pull request only at the end — which strays from the point of improving productivity. Proceed while watching the organization’s condition, not blindly.
Metrics are for improving the organization and the team, not for evaluating individuals. When a metric becomes an evaluation target, optimizing the number itself takes priority and the metric stops reflecting reality. This phenomenon is known as Goodhart’s law.

​
Do not build the wrong thing

No matter how efficiently a team develops, building the wrong thing brings the delivered value to zero. More important than productivity improvement is delivering something truly valuable. Consider the following to raise delivered value.

Why, when, and who will use it

Examine the necessity, timing, and target users of a feature from the engineer’s viewpoint too, rather than taking requesters’ or product managers’ information at face value.

Can it be realized without development?

Keep delivered value while minimizing invested resources by combining existing features or using external services and libraries.

Can the design be simpler?

Reduce mixed purposes and branching in features so that maintenance and modification effort does not balloon.

Is staged release possible?

Release the most important part first, get feedback early, and make course corrections or stop decisions quickly.
Engineers are not mere implementers; they should actively think about development that leads to business value. Improving developer productivity is meaningful only when combined with the right direction.

CI/CD

Automating builds and deployments — one of the Level 1 initiatives named here, as a concrete pipeline.

Code Review

Where review time actually goes, and how to spend less of it on what tools can check.

Test Code

Coverage is a Level 1 metric; this is how to make the tests behind the number worth counting.