Developer-Friendly Metrics: Measure the System, Not the Developer

You're Measuring Developers Instead of Their Environment

Software organizations still measure developers by the tangible artifacts they produce instead of measuring if the system enables them to produce it.

Lean manufacturing transformed industry by shifting management attention away from workers and toward the system they work in. Instead of asking people to compensate for missing tools, materials, instructions, or information, Lean redesigned the workplace so everything required to perform the job correctly was available exactly where and when it was needed. Standardized Work defined the best known way to perform a task. 5S ensured that everything had a designated place. Just-in-Time delivered resources precisely when they were needed. Visual Management made missing resources immediately obvious. The objective was simple: eliminate unnecessary searching, waiting, motion, and rework before asking workers to work harder.

Software development has largely taken the opposite path. Organizations continue to judge engineering through what developers produce: features delivered, story points completed, commits, pull requests, lines of code, prompt volume, or other measures of visible activity. More mature organizations adopt Flow Metrics and DORA metrics to measure delivery performance, providing valuable insight into throughput, lead time, work in progress, deployment frequency, and operational stability. These metrics successfully optimize the logistics of software delivery, but they do not answer a more fundamental question: does the engineering system provide developers with everything they need to succeed?

That question matters because software development is fundamentally knowledge work. The most valuable resources are not machines or raw materials but information: what to build, why it matters, how it should work, where the relevant knowledge resides, when it is needed, and who possesses it. Every minute spent searching documentation, reconstructing architectural decisions, interpreting vague requirements, or repeatedly asking colleagues represents the software equivalent of Lean's wastes of motion and waiting. The knowledge exists somewhere in the organization, yet the system fails to deliver it to the developer at the point of work.

AI raises the stakes dramatically. Many organizations celebrate that AI produces more code, more tests, more documentation, and more pull requests. But AI is not fundamentally a source of code; it is a source of knowledge. When developers and AI agents operate without complete context, they simply generate more artifacts around the same unresolved uncertainty. Code becomes cheaper while knowledge remains the true constraint. As a result, metrics that reward software output become progressively less meaningful precisely when organizations rely on them the most.

The companies that measure software production will optimize artifact generation. The companies that measure knowledge will optimize engineering itself.

Healthy Dashboards Can Hide Broken Knowledge Systems

When organizations measure logistics instead of knowledge, they optimize the movement of work while leaving the real constraint untouched.

Flow Metrics and DORA metrics provide valuable visibility into how software moves through the delivery system. They reveal queues, bottlenecks, deployment frequency, lead times, and operational reliability. They answer important questions about how efficiently work flows. What they cannot reveal is whether developers had the knowledge required to make the right decisions while that work was flowing. A team can achieve excellent Flow Metrics while repeatedly rediscovering architectural decisions, searching fragmented documentation, interrupting colleagues for context, or asking AI to reconstruct information that the organization has already paid to discover.

This creates a dangerous management illusion. Leadership sees healthy delivery metrics and assumes the engineering system is healthy. Yet beneath the surface, developers compensate for missing knowledge every day. Architectural rationale disappears into chat threads. Business rules remain trapped in source code. Domain expertise lives inside a handful of experienced engineers. AI agents repeatedly infer missing context instead of receiving it explicitly. The organization continues delivering software, but it does so by consuming additional cognitive effort rather than by improving the system itself. The visible logistics appear efficient while the invisible knowledge supply chain steadily deteriorates.

The greatest organizational cost is not slower delivery but systematic misdiagnosis. Leaders naturally attribute delays, defects, and inconsistent quality to individual developers or teams because those are the entities being measured. The real bottleneck, however, is often the engineering system's inability to preserve, organize, and deliver knowledge where and when it is needed. Developers become the human compensators for organizational inefficiency. The more knowledge the system loses, the more searching, waiting, rediscovery, interruptions, and AI-assisted guesswork developers must perform. Cognitive load rises, the likelihood of achieving Flow declines, and developer frustration increases, not because developers are less capable, but because the system continuously forces them to solve problems that should have been solved once and shared with everyone.

AI amplifies this effect. As code generation becomes inexpensive, the competitive advantage shifts away from producing software faster toward reducing uncertainty faster. Organizations that continue measuring code, features, and delivery logistics alone will optimize artifact production while knowledge continues leaking from the system. Organizations that measure Information Loss Rate, KEDE, and Happiness alongside Flow Metrics will instead optimize the quality of the engineering system itself. They will understand not only how work moves, but why it moves efficiently, or why it does not.

The fastest engineering organizations will not be those that produce the most software. They will be those that lose the least knowledge.

Manage the Flow of Knowledge, Not Just the Flow of Work

The goal is not to replace Flow Metrics, but to complement them with Knowledge-Centric Metrics so leaders can optimize the complete socio-technical system.

Software organizations have three distinct paths available. The first is to continue optimizing logistics. The second is to focus primarily on developer experience. The third, and the one that will matter most in the age of AI, is to optimize the entire engineering system by managing both the movement of work and the flow of knowledge. The choice is not between Flow Metrics and Knowledge-Centric Metrics. The choice is whether leadership wants to optimize only what is visible or also the invisible system that determines engineering performance.

Optimize Logistics

Continue using Flow Metrics and DORA metrics to improve the movement of work through the delivery pipeline.

• Benefit: Improves throughput, lead time, deployment reliability, and operational predictability.
• Risk: Measures whether work moves efficiently, but not whether developers possess the knowledge needed to make correct decisions while performing that work.

This approach remains highly effective in industrial environments because logistics are often the dominant constraint. In software development, however, logistics are only one part of the system. Work cannot flow efficiently when developers repeatedly stop to search for information, reconstruct forgotten decisions, or compensate for missing context. Optimizing the conveyor belt does not help if workers still have to search for the instructions.

Optimize Developer Experience

Invest in making engineering a better place to work through improved tooling, collaboration, workplace culture, surveys, and employee experience initiatives.

• Benefit: Reduces friction, improves retention, and increases engagement.
• Risk: Improves the work environment without necessarily addressing the organizational causes of cognitive overload.

Developer happiness is important, but it should not be confused with comfort. The most productive developers are rarely those experiencing the least challenge. They are the ones experiencing Flow - a balance between challenge and capability that allows deep concentration and continuous progress. Removing friction is valuable only when it removes unnecessary obstacles rather than eliminating the intellectual challenge that makes engineering engaging.

Optimize the Complete Socio-Technical System (Recommended)

Integrate Flow Metrics with Knowledge-Centric Metrics to measure both the visible logistics of software delivery and the invisible knowledge system that enables it.

• Benefit: Provides a complete picture of engineering performance by combining delivery mechanics with knowledge discovery, organizational learning, and developer effectiveness.
• Risk: Requires leaders to examine and improve the engineering system instead of attributing performance primarily to individuals.

Knowledge-Centric Metrics complement rather than replace Flow Metrics by making visible what delivery metrics cannot observe.

• Information Loss Rate measures whether organizational knowledge is preserved, transferred, and made available instead of being lost, fragmented, or trapped inside people, documents, chat systems, or AI conversations.
• Knowledge Discovery Efficiency (KEDE) measures the balance between developer capability and the knowledge required to complete the work. It reveals whether developers are overloaded by missing knowledge or underutilized by insufficient challenge.
• Happiness, understood as the likelihood of achieving Flow, measures whether the engineering system creates the conditions for sustained, high-quality knowledge work. Flow emerges when developers receive enough information, tools, and organizational support to tackle meaningful challenges without becoming overwhelmed.

Together with Flow Metrics, these measures create a balanced management system. Flow Metrics explain how efficiently work moves. Knowledge-Centric Metrics explain why work moves efficiently, or why it does not. One measures logistics. The other measures the quality of the knowledge environment.

The first practical step is to map the organization's knowledge supply chain. Just as Lean maps the movement of materials through a factory, software organizations should map how knowledge is created, validated, stored, shared, consumed, and retained throughout the engineering process. Every place where knowledge is delayed, fragmented, rediscovered, or lost becomes an opportunity for improvement. AI should then be deployed not simply to generate more software, but to strengthen that knowledge supply chain by making organizational knowledge more complete, more accessible, and more reusable.

The future belongs to organizations that optimize both the flow of work and the flow of knowledge. AI makes both possible, but only one creates a lasting competitive advantage.

The Companies That Measure Knowledge Will Win

The metrics you choose determine whether AI strengthens your engineering system or simply accelerates its weaknesses.

Organizations that integrate Flow Metrics with Knowledge-Centric Metrics gain something far more valuable than another dashboard: they gain the ability to distinguish between logistical problems and knowledge problems. When delivery slows, leaders can determine whether work is waiting in a queue or whether developers are waiting for information. When rework increases, they can determine whether the bottleneck lies in the delivery process or in lost architectural knowledge, fragmented requirements, or inaccessible domain expertise. Instead of relying on intuition, surveys, or anecdotal explanations, leadership can systematically identify where the engineering system fails to supply developers with the knowledge they need. Improvement efforts become targeted because the real constraint becomes visible.

The consequences extend well beyond operational efficiency. Measuring the knowledge supply chain fundamentally changes management behavior. Leaders stop asking, "Why are developers slower?" and begin asking, "Why did the system fail to provide the necessary knowledge?" Responsibility shifts from judging individuals to improving the environment in which individuals work. Developers spend less time searching, rediscovering, interrupting colleagues, and reconstructing context, and more time solving meaningful problems. AI also changes role. Instead of acting primarily as a faster code generator, it becomes an amplifier of organizational knowledge, helping developers retrieve, connect, and apply what the organization already knows. Engineering becomes a learning system rather than a production system.

The alternative is becoming increasingly dangerous. Organizations that continue measuring only throughput, delivery speed, and software output will become progressively better at producing artifacts while becoming progressively worse at understanding whether those artifacts solve the right problems. AI makes code inexpensive, making traditional output metrics easier than ever to optimize without creating corresponding business value. Teams will appear productive while repeatedly rediscovering lost knowledge. Leadership will continue rewarding visible activity instead of system quality. The engineering system will silently accumulate cognitive debt, hidden rework, and fragmented organizational memory until these become the dominant constraints on delivery.

Act now: map your organization's knowledge supply chain and complement your existing Flow dashboard with Information Loss Rate, Knowledge Discovery Efficiency (KEDE), and Happiness as Flow State. Use these metrics to improve the engineering system before asking developers to improve themselves.

Do nothing: continue optimizing the movement of work while ignoring the movement of knowledge, and AI will merely help your organization produce the wrong software faster.

The companies that measure code will compete on speed. The companies that measure knowledge will compete on learning - and learning compounds.

Next Step

Run a knowledge-supply-chain assessment and add KEDE, Information Loss Rate, and Happiness to your existing Flow dashboard.