What it measures

Flow Efficiency expresses active work time as a fraction of total elapsed time. If a pull request takes five days from first commit to merge but only six hours of that is hands-on-keyboard work, flow efficiency is roughly five percent. The rest is wait state.

It is a ratio, not a duration. Two changes can have identical cycle times while one was worked continuously and the other sat in a review queue for days. Flow Efficiency separates those cases by isolating the share of time spent waiting versus doing.

Healthy software organizations rarely exceed forty to sixty percent. Most of a change's life is spent idle, so the metric is most useful as a measure of friction in your delivery path rather than of individual effort.

How to measure it

Reconstruct each change's timeline from git and pipeline events: first commit, push, PR opened, first review, approval, merge, deploy. Active periods are intervals with commits or reviewer actions. Wait periods are the gaps: time from PR opened to first review, time blocked on CI, time approved but not merged. Flow Efficiency is the sum of active intervals divided by total elapsed time.

In practice you approximate active time, since you cannot see keystrokes. A common convention treats a commit or review event as a marker and counts the contiguous window around it as active, with long quiet stretches counted as wait. Be explicit about the convention because the absolute number shifts with it.

Aggregate at the change, contributor, or initiative level. The most actionable cut is per stage: how much idle time accrues in review, in CI, and in the approved-but-unmerged gap. That tells you where the queue is, not just that one exists.

What it does not tell you

Flow Efficiency tells you how smoothly work moves, not whether it should have moved at all. A change can flow through your pipeline with zero idle time and still implement the wrong thing, advance no real initiative, or add code that has to be reworked next quarter. The ratio rewards a clean queue, not a correct decision.

It also says nothing about the value or strategic alignment of the work being measured. Fifty percent flow efficiency on a feature nobody asked for is worse than thirty percent on the initiative that unblocks revenue. The metric measures motion through the system, not direction toward an outcome. Optimizing it in isolation can simply make low-value work arrive faster.

This is the gap Execution Intelligence closes. Knowing how efficiently a change flowed is a process signal. Knowing what was actually built, which initiative it serves, and whether that was the right place to spend the team's time is the judgment a CTO needs. Flow Efficiency is one input to that read, not the read itself.

How InteliG uses it

InteliG computes Flow Efficiency directly from real git history and deployment events, with no manual instrumentation, story tagging, or self-reported time. It reconstructs each change's active and waiting intervals from commits, pull requests, reviews, and deploys, so the number reflects what happened rather than what was logged.

Cognis then connects that efficiency back to the initiative the work belongs to, the contributors who did it, and the cost it carried. So instead of a standalone process ratio, you see whether the time was spent moving the work that matters, who carried it, and what it cost to get from intent to production.

Related terms

Cycle Time — Total elapsed time for a change from first commit to production
Lead Time for Changes — A DORA metric: time from code committed to running in production
Execution Intelligence — Reading what is actually being built and why, not just how fast