> ## Documentation Index > Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # What is developer productivity? Definition and levels > Explains the definition of developer productivity, the three levels of productivity with measurement and initiatives for each, why improvement matters, and cautions when pursuing it. ## 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. | Kind | Typical items | | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Output | Number of released features and fixes
Lines of code developed
Number of resolved bugs and issues
Value delivered (user satisfaction, contribution to revenue)
Quantity and quality of documentation | | Input | Time spent on development
Human resources invested (number of engineers)
Budget used for development
Cost of infrastructure and tools
Time and budget invested in educating and training the team | 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 | Result being measured | Example viewpoints | | ----------------------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Level 1: Work volume | How efficiently a given amount of work was completed | Whether an efficient development environment is in place
Whether engineers have the needed skills
Whether the service itself has a good structure | | Level 2: Expected value | How much of the expected value was released | Whether the right tasks that serve the product's goal are selected
Whether tasks are prioritized appropriately | | Level 3: Realized value | Concrete contribution to the actual service | How much revenue changed because of the product
How far KPIs were achieved | ### 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. With processes no longer visible, more teams and companies focus on contribution to results, and individuals need to work efficiently. Competition with advanced products from around the world requires delivering usable, capable products faster, in response to user demand. With growing use of OSS and external SaaS, teams need the ability to select and combine many technologies. 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. | What you gain | Summary | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | More results from less investment | Hiring engineers takes time, and new hires need a catch-up period. Making the most of existing resources to raise productivity is key to staying competitive | | Clearer problems through visualization | When productivity is quantified into concrete numbers, the flow of work and its problems become clear, and organizational weaknesses and opportunities can be found and addressed early | | An improvement cycle | Highly productive teams build continuous improvement into daily work, and that cycle produces further productivity gains | | Contribution to the product cycle | As developer productivity improves, the release cycle shortens, enabling faster response to market changes | | A positive effect on recruitment | An organization with little technical debt and visible improvement is an attractive environment where engineers can grow, which also benefits employer branding | ## 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. 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. Keep delivered value while minimizing invested resources by combining existing features or using external services and libraries. Reduce mixed purposes and branching in features so that maintenance and modification effort does not balloon. 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. ## Related pages Automating builds and deployments — one of the Level 1 initiatives named here, as a concrete pipeline. Where review time actually goes, and how to spend less of it on what tools can check. Coverage is a Level 1 metric; this is how to make the tests behind the number worth counting.