Why did I build KEDEHub?

We Have Been Managing the Visible Part of Software Development

I built KEDEHub because, after years of working inside the dominant models of software delivery, I came to believe that the industry’s core mistake was not poor measurement, but a poor understanding of the nature of the work being measured.

I did not arrive at that conclusion as an outsider. I successfully managed software development using Lean, Agile, Kanban, and Flow thinking. I was deeply involved in the international Kanban community and, in 2015, became a finalist for its Brickell Key Award. That same year, I initiated the first international Agile Lean conference in Bulgaria. Through those years I lectured, spoke at industry conferences, and published eight Bulgarian-language management books covering Lean, Kanban, Goldratt’s Theory of Constraints, and Deming’s management thinking.

Those approaches taught organizations to see queues, lead time, work in progress, throughput, rework, bottlenecks, and delivery flow. DORA and Flow Metrics pushed that visibility further. They remain valuable advances in managing the logistics of software development.

But over time I saw the gap. We could observe how work moved through the system, yet we still could not adequately measure the work that made that movement possible.

Software development is fundamentally knowledge work. A developer starts a task with some prior knowledge but does not possess all the knowledge required to complete it. Requirements contain unknowns. Architecture involves choices. Business rules need clarification. Technical constraints must be discovered. Developers must discover that missing knowledge before they can reliably produce a working solution.

The code, commits, pull requests, tickets, and releases are visible traces left behind by that process. The actual work of knowledge discovery that makes them possible is largely invisible.

The constraint in software development is not typing code or moving tickets. It is discovering the missing knowledge necessary to reach a valid solution.

We became very good at measuring how software work moves while remaining largely blind to the work that makes movement possible.

When You Measure Logistics as Productivity, You Optimize the Wrong System

When you mistake the visible logistics of knowledge work for the work itself, management starts optimizing the wrong things.

If leaders primarily see throughput, lead time, ticket completion, commits, pull requests, and deployment frequency, those measures naturally become the focus of improvement. But more visible activity does not necessarily mean that the team has reduced uncertainty or discovered the knowledge required to produce the right solution. A team can move work faster while increasing rework, confusion, and downstream correction.

An unclear requirement does not disappear because implementation started quickly. It reappears as rework. A missing architectural decision resurfaces during integration. A misunderstood business rule becomes a defect. Poorly transferred context increases cognitive load and forces people to rediscover what the organization should already know.

Developers who stop to clarify assumptions, improve specifications, challenge a design, or gather missing context may appear slower than developers who immediately produce code. Yet the first group is reducing uncertainty before it becomes expensive. The second may simply be pushing unresolved knowledge downstream.

If you cannot observe the quality of the knowledge-discovery process, you cannot confidently tell whether a tool, training program, process change, reorganization, or management intervention improved engineering efficiency. You have measurements of what happened downstream, but weak visibility into why it happened.

If you cannot see the knowledge-discovery system, you cannot know whether you improved it or merely made it move faster.

Make the Invisible Dynamics of Knowledge Work Measurable

The breakthrough was not another engineering metric or to abandon Flow Metrics, DORA, or developer-experience measures. It was to add the missing perspective: measure software development as knowledge work.

Every task requires some amount of knowledge. Developers begin with prior knowledge, but rarely with everything required to complete the task successfully. The difference between what they already know and what the task requires is the Knowledge to Be Discovered. Knowledge work is the cognitive effort needed to close that gap.

Once I started looking at software development this way, the question changed from “How fast is work moving?” to “How efficiently is the organization helping people discover and apply the knowledge required to produce a valid result?”

That is why I built KEDEHub.

KEDEHub is built on a cybernetic model of knowledge work. It quantifies the Knowledge to Be Discovered in bits of information, using the mathematical foundations of Information Theory to turn an otherwise invisible knowledge gap into something measurable and comparable.

Software development is only one application of that model. The same Knowledge-Centric Perspective can be applied wherever people must discover missing knowledge to make decisions, solve problems, and complete work.

KEDEHub operationalizes the perspective through metrics that make parts of this invisible system measurable. Knowledge Discovery Efficiency (KEDE) quantifies the relationship between the knowledge gap and successful completion. Information Loss Rate exposes rework. Other Knowledge-Centric Metrics illuminate collaboration, cognitive load, productivity, and the conditions associated with Flow.

Did the organization create an environment where developers have everything they need to succeed?

By “everything they need,” I mean access to clear requirements, business context, architecture decisions, technical constraints, useful documentation, capable peers, and effective tools such as AI. The point is not to rank developers or turn people into numbers. It is to evaluate the system around them.

Software development is a collective knowledge system. Designers clarify user needs. Product Owners contribute business context. Architects narrow technical choices. QAs expose behavioral gaps. Support teams bring production knowledge. Documentation preserves prior learning. Peers, Stack Overflow, and AI add further knowledge when needed.

KEDE should never be read as, “How good is this developer?” It is better read as, “How effectively does this system help the developer get the knowledge required to succeed?”

Inefficiency in knowledge work is usually a property of the system before it is a property of the individual.

Flow Metrics tell you how work moves. Knowledge-Centric Metrics tell you what is happening inside the knowledge-discovery system that makes that movement possible. Together, they give leaders a better basis for judging whether an intervention actually improved the way software is developed.

You cannot manage knowledge work well unless you can make its invisible dynamics measurable.

Once You Can Measure Knowledge Discovery, You Can Ask Better Questions

Once you can measure knowledge discovery, you can make better decisions about teams, processes, management interventions, and increasingly, AI.

Most organizations still evaluate AI-assisted software development through proxies such as adoption, prompt volume, generated code, commits, pull requests, ticket velocity, or delivery throughput. Those measures can tell you whether AI is being used and whether activity increased. They cannot tell you whether the engineering system became more efficient.

From a Knowledge-Centric Perspective, AI is best understood as a source of knowledge, not a source of code.

If AI helps a developer understand an unfamiliar API, uncover a hidden dependency, compare architectural options, identify an incorrect assumption, or generate a useful test that reveals missing behavior, then AI has reduced the Knowledge to Be Discovered. If AI merely generates more code while underlying uncertainty remains, it has increased output without necessarily improving engineering efficiency.

That is why I believe KEDEHub is uniquely important now. Other tools can measure AI usage, output, or flow. KEDEHub measures whether the knowledge-discovery system itself is changing.

KEDEHub is the only tool that measures the real impact of AI on engineering efficiency because others measure AI usage, output, or flow; KEDEHub measures the change in knowledge-discovery efficiency.

And AI is only one application. The same perspective can help leaders evaluate whether better specifications reduce rework, whether architecture improves decision quality, whether training reduces knowledge gaps, whether collaboration transfers useful knowledge, and whether management changes improve the engineering system.

The organizations that learn to measure knowledge discovery will make better decisions about teams, processes, and AI than those that do not.