When you’re trying to improve the effectiveness of your software engineering organization, a handful of metrics can help you identify specific opportunities. One of those metrics is flow efficiency, the percentage of time a task is active relative to the total time the task is in progress.
It’s a useful metric when diagnosing cycle time issues, but it’s also useful on its own as an indicator of how easy it is for an engineer to finish something once they start it.
When flow efficiency is low, it’s a strong indicator that team members are multitasking, often due to interruptions. It can also happen when dependencies outside the team block progress on the team’s tasks or when tasks are so large that they are difficult to complete within a day or two.
Low flow efficiency is also a leading indicator that some work never gets done, abandoned in favor of something more important in the moment. This kind of waste bloats the cost of delivering any kind of engineering value, because so much work amounts to nothing.
So if you’re observing low flow efficiency in your team or organization, what can you do?
Finish what you start
When a team is trying to juggle too many things at once, the cost of multitasking starts to hit. High-performing teams limit the number of items that can be in progress at any time (often known as a “work in progress (WIP) limit”), sometimes to setting the number to something smaller than the size of the team.
Pair your WIP limit with a commitment to finish a task once it’s in progress. It can be tempting to set work aside when something urgent comes up, but — other than production incidents — stopping work to work on something else is almost always detrimental to flow efficiency.
Minimize delays and dependencies
“Waiting for something to happen” is the cause of a lot of flow inefficiency — whether you’re waiting for a code review from another team, waiting for the build to finish, or waiting for a team to deliver something that your team needs to make progress. At the team level, many of these delays could be prevented or reduced through better collaboration or an investment in improving automation.
Remember: collaboration means more than just having a meeting to design each team’s solution before going your separate ways. Pair with someone from the other team on the work each team needs to do. Define and execute small checkpoints rather than a big-bang integration.
Engineering leaders have another lever to reduce these bottlenecks: the shape of the organization itself. Prefer teams that fully own the code required for most changes the team will make. A system’s architecture, too, will influence how easily teams can work independently without delay.
Reduce your batch size
If a task is defined in a way that it requires hundreds of lines of changes across multiple files in the project, there’s a good chance the task itself is too big. Big tasks take longer than small tasks, and that means they have more opportunity to be set aside before they’re done.
Smaller batches reduce the risk of over-specifying a task upfront before you do any implementation. When you try to fully specify a large task, not only will you get it wrong, but two other things happen: 1, you spent a lot of time, and 2, you’ll spend even more time learning what you got wrong.
Smaller tasks are much more likely to be well-scoped and thus well-defined. A well-defined task limits the amount of back-and-forth time — counted as non-active time — that’s required while the task is in progress. Smaller tasks also tend to lead to higher-quality products over time.
Reduce your defect rate
Nothing disrupts a team’s flow efficiency like a production incident: even if your team’s investment balance leaves time for these things, they come unpredictably and often in packs.
Every improvement mentioned so far here should materially reduce your defect rate. Of course, you can also reduce defect rates by increasing test coverage and embracing continuous integration. No matter how you do it, reducing your defect rate will reduce the time the team has to spend away from its prioritized work.
Priority changes come with a cost
Senior leaders bear a unique responsibility: deciding what the company will (and won’t) work on.
The responsibility isn’t just in the business risk if you don’t get it right: it’s in the switching costs of disrupting everyone’s cascading priorities if you get it wrong. Of course, no plan survives etc., etc., but too-frequent zigs and zags will depress flow efficiency across the organization as teams learn the new rules. Add a reorg to the mix if you want to complicate things further.
Reorgs and changing priorities can be necessary, but good leaders recognize the disruption they create and have realistic expectations of how that disruption will impact delivery — sometimes for weeks or months.
Handle interruptions gracefully
I’ve seen the horror of the exec who requested a deck with certain contents, only to learn later that person-weeks of effort went into producing it — once a week. Similarly, I’ve seen teams drop everything to generate a number for a senior leader, assuming the leader wouldn’t have asked if it wasn’t important.
These kinds of interruptions reduce the flow efficiency of the team, putting tasks that the team had carefully prioritized at risk of being delayed or set aside entirely — almost certainly not what the leader intended. Interrupt-driven work is a reality, but even exec requests need a WIP limit.
If these sorts of requests often fall on your team, set aside a percentage of time for them — typically on a rotation, where the person assigned doesn’t have any other in-progress work. Give leaders a framework for understanding what’s easy and what’s hard, and for explaining the importance of the request. Set expectations with the requesters that blowing the interruption budget will impact other priorities.
Summary
Flow efficiency is one of a handful of software engineering benchmarks for understanding whether your software engineering organization is performing at its best. When flow efficiency is high, work is rarely wasted, and delivery is more predictable. If you feel like there’s room for your org to be more productive, this metric could be a good place to start as you work to build a more effective engineering organization.
