Flow is a rich concept in software development that encompasses multiple aspects of how work gets done. While we often discuss flow in terms of individual developer productivity or process efficiency, understanding flow through multiple lenses can help organizations optimize their software delivery.

At the most fundamental level, flow in software development describes how work moves through a system. Don Reinertsen’s book Principles of Product Development Flow emphasizes that the economic impact of flow — or lack thereof — is profound but often poorly understood. When work sits idle, it represents delayed value delivery and tied-up resources. This thinking pushes us beyond simple efficiency metrics toward understanding the true cost of delays and queues in our development process.

Flow efficiency measures the ratio between active work time and total elapsed time. A feature that takes two weeks to deliver but only receives two days of actual development time has a flow efficiency of roughly 20%. The remaining 80% represents waiting time — for reviews, approvals, deployments, or other downstream activities. This metric helps illuminate where work gets stuck in the system.

Beyond metrics

Beyond process measures, flow describes a psychological state of deep concentration where developers can work without interruption. This state enables complex problem-solving and creative work, but it’s fragile — taking about 15 minutes to achieve and easily broken by interruptions. Organizations that fail to protect these flow states often see decreased developer experience and productivity.

A key insight from Reinertsen is that high utilization of resources (like developers) actually reduces flow due to the system-wide slowdown that occurs when you are constantly waiting for things to happen. When engineers are juggling multiple tasks, the cognitive cost of switching between them creates significant waste. This aligns with research on psychological flow states showing that interruptions have an outsized impact on productivity.

Both process and psychological perspectives on flow emphasize the importance of working in small batches. From a process view, smaller batches reduce risk and enable faster feedback cycles. From a psychological view, completing discrete units of work more frequently provides motivation and maintains engagement. The alignment between these perspectives suggests that optimizing batch size is a powerful lever for improving flow.

Recognizing flow problems

Flow problems often manifest first through qualitative signals. Engineers may express frustration about constant interruptions or an inability to make meaningful progress on important work. You might notice that even simple changes take days or weeks to reach production, or that work items frequently get stuck waiting for reviews or approvals. Teams may feel overwhelmed by the number of concurrent projects, yet struggle to complete any of them.

These symptoms warrant investigation into your flow metrics, but measuring flow requires careful consideration. The biggest risk in measuring flow is creating perverse incentives that actually reduce it. For example, measuring individual productivity metrics like lines of code or number of commits can encourage developers to optimize for those metrics rather than valuable outcomes. Similarly, focusing solely on speed metrics without considering quality can lead to technical debt that ultimately reduces flow.

Diagnosing flow issues

Several metrics can help diagnose flow problems:

• Cycle time tells you how long work takes to complete from start to finish. High or inconsistent cycle times often indicate flow problems. When examining cycle time, look particularly at how long work spends in various states. If code regularly waits days for review, that’s a clear flow bottleneck.
• Work in progress (WIP) counts reveal whether teams are trying to handle too many things at once. High WIP typically correlates with reduced flow efficiency as people context switch between tasks. Track WIP at both the team and individual level to identify overload.
• Flow efficiency measures the ratio of active work time to total elapsed time. While 100% flow efficiency isn’t realistic, very low percentages indicate systemic flow problems. When work spends most of its time waiting, that’s a clear opportunity for improvement.
• Queue times for different process stages can highlight where work gets stuck. Pay particular attention to handoffs between teams or waiting times for external dependencies. These coordination points often become flow bottlenecks.

Making improvements

Improvement efforts should focus on reducing both systemic and point-specific flow problems. Start by addressing obvious bottlenecks — if code review is consistently the longest queue, that’s a natural place to begin. Consider whether process changes (like "review others’ code before writing new code") or tooling improvements could help. Generally, following these guidelines will put you in good shape:

• Limit work in progress to reduce context switching and cognitive load
• Break work into smaller batches that can be completed more quickly
• Manage interruptions carefully, creating protected time for deep work
• Reduce dependencies between teams that create waiting periods
• Automate repetitive tasks that interrupt flow
• Measure and optimize queue times in your development process

Track the impact of improvements through your flow metrics, but remember that initial changes might temporarily reduce flow as people adjust to new ways of working. Look for trends over time rather than immediate improvements. Successfully improving flow should result in:

• Decreased and more consistent cycle times
• Higher flow efficiency percentages
• Reduced queue times
• More predictable delivery

Most importantly, improving flow should lead to better outcomes for the business: higher quality work, more sustainable pace, and increased engineer satisfaction. While metrics help validate improvements, don’t lose sight of the qualitative impacts on your team.

Flow problems rarely have single causes or solutions. They typically emerge from the interaction of multiple factors including process design, tooling limitations, and organizational structures. Sustainable improvement requires ongoing attention to all these elements rather than quick fixes to individual metrics.

Remember that improving flow isn’t about maximizing utilization. In fact, high utilization often reduces flow by eliminating the slack needed to handle natural variation in work. Focus instead on making work move smoothly through your system while maintaining sustainable practices.

An economic view of flow

Reinertsen’s work fundamentally changed how we think about product development flow by introducing economic frameworks to process decisions. Rather than pursuing efficiency for its own sake, he emphasizes that every delay and every queue has quantifiable costs that directly impact business value.

The most important insight is that fast feedback loops have immense economic value. When development teams can quickly learn whether their changes work as intended, they reduce the cost of mistakes and increase the chances of building the right thing. This applies at every level: from a developer getting immediate feedback from tests, to teams learning quickly from real users, to organizations discovering whether their product strategies are working.

Reinertsen identifies several key practices that support this rapid feedback:

• Small batch sizes are economically superior because they reduce risk and accelerate learning. While conventional wisdom might suggest that larger batches are more efficient, they actually increase the cost of delays and mistakes. When something goes wrong with a large batch, the cost of fixing it is substantially higher than addressing issues in smaller increments.
• Queue management is another critical economic lever. Long queues of work — whether that’s features waiting to be built, code waiting to be reviewed, or changes waiting to be deployed — represent delayed value delivery. These queues also hide quality problems and increase the cost of course corrections. By actively managing and reducing queues, organizations can significantly improve their economic outcomes.
• Capacity utilization presents an unexpected economic tradeoff. While it might seem efficient to keep everyone busy, high utilization actually increases queue size exponentially. Reinertsen demonstrates that operating at slightly lower utilization — maintaining some slack in the system — often produces better economic results by reducing delays and enabling faster flow.
• Decentralized control is another key principle. When teams can make local decisions about their work without requiring extensive coordination or approval chains, they can respond more quickly to new information. This faster response time has real economic value, particularly in fast-moving markets.
• Variability in product development is inevitable and often valuable — it's where innovation comes from. Rather than trying to eliminate variability entirely, Reinertsen advocates for managing its impact through practices like small batches and fast feedback loops. This allows organizations to harness the benefits of variability while minimizing its costs.

The economic view of flow provides a powerful framework for making process decisions. Instead of relying on intuition or industry best practices, organizations can evaluate changes based on their economic impact. This might mean investing in automation to speed up feedback cycles, accepting some short-term inefficiency to maintain system slack, or reorganizing teams to reduce coordination costs.

Understanding these economic principles helps organizations make better decisions about where to focus their improvement efforts. The highest return often comes from reducing the longest queues, accelerating the slowest feedback loops, and eliminating the most expensive delays. This economic lens helps prioritize improvements that will have the most significant impact on business outcomes.

Final thoughts

Understanding and improving flow in software development requires considering economic, process, and human factors. While the metrics and measurements discussed here provide valuable insights, they should serve as conversation starters rather than performance targets. The most successful organizations use flow data to identify opportunities for improvement while remaining focused on delivering value and maintaining a sustainable engineering culture.

Organizations just beginning their flow journey should start small: identify one clear bottleneck, address it thoughtfully, and learn from the results. This might mean tackling an obvious process problem like long code review queues, or a human factor like excessive meetings breaking up the workday. The key is to make incremental improvements while building the organizational muscle for measuring and improving flow.

Over time, a deep understanding of flow can transform how an engineering organization operates. When teams optimize for smooth work movement while protecting engineers' ability to focus, they create an environment where both the business and the engineers can thrive. The result is not just more efficient delivery, but a more sustainable and satisfying way to build software.

Remember that improving flow is not a destination but an ongoing journey of understanding and refinement. The most effective organizations maintain a constant awareness of their flow metrics while staying attuned to the human experience of building software. This balanced approach leads to sustained improvements in both productivity and satisfaction.

Start improving flow in your engineering organization

Get a live demo with one of our product experts to understand how you can use Swarmia to measure and improve your flow metrics.

Get a demo