How Long Does It Really Take to Read a Book?
How measuring your Flow Efficiency can improve your overall workflow
In the Tuesday Tidbits, we discuss all things Leadership and Continual Improvement. With this installment, I wanted to start discussing how to use metrics as a way to ask questions that lead to improvement.
Got Books?
If I asked you how long it takes you to read a book, what would you say? When I asked my wife this question, she told me, “Three hours.” I was highly impressed. I asked her if, as a result, she read a book every day, to which she said, “Well, not really. I don’t always have three straight hours to read a book. But if I start and have no interruptions, I could read a book every day.” In total, it takes my wife two days to read a book in three hours. That feels like a brain teaser, but that’s how most of us work every single day.
I’ve asked that same question of other people, and they normally answer that it takes them a week or two to read a book. If I press them to understand what time was spent actively reading during that two-week period, their measurement converts from weeks to hours. They use the same reasoning my wife did around why. Things get in the way and, while they are technically still “reading” that book, they weren’t reading it every single minute for the entire week it took to finish.
So how can you calculate how much time a thing actually takes versus how long it takes with all the delays and distractions? That, my friends, is where Flow Efficiency comes in.
Flow Efficiency Explained
As you can see in the book example, getting to the calculation is fairly straightforward. If I took my wife’s time of three hours to read the book over two days, I would divide 3 (Active Time) by 48 (Total Time) and multiply that times 100%, which is right at 6%. That means her Flow Efficiency for book reading would be 6%. Here is that equation one more time:
That’s it. Now you all should be able to calculate your book reading efficiency. Super helpful, right? Okay, maybe not. In that case, let’s look at a real life example in the digital products world.
Mark And The T-Rex Squad
Mark, a software development leader, approached me about how to use metrics to help his team, the T-Rex Squad, improve their flow of work. I immediately did a happy dance, as I love geeking out on both continual improvement and how metrics help us do that. As luck would have it, we had access to a tool that collected data from their digital job board.
Looking at the tool’s Flow Efficiency chart for their team, we could see that work spent a lot of time in the “waiting to be code reviewed” status. Essentially, once the someone finished writing code, a different team member would review the code. Something was causing a delay in performing the action of reviewing code.
Because Mark saw that metric - simply because he saw it - he wanted to improve it. Because they wanted to improve it, they asked great questions. One of these questions was, “What’s one thing we could do to reduce the wait time for code review?” Previously, they were using the digital job board as a way to note something was ready for review, but this felt a bit passive. The team wanted to try being more intentional. Which brings us to the experiment.
The Experiment
As an experiment, they decided to ask an available developer to review code. You read that right. They took off their headphones and talked to other people instead of simply sending an email. As Mark put it, “The team was no longer satisfied marking the work ready. They would now go find someone and sit at their desk while they waited.” They still respected boundaries by not context switching each other or interrupting focus time, but now they were intentionally communicating with each other in real time.
And something magical happened.
In the end, they saw a 10% improvement Flow Efficiency. Seeing the metric caused them to ask a great question, run an experiment, and reduce delay. But it had other improvements as well. Communication improved. The team was now talking to each other more and building relationship they wouldn’t have built otherwise. The workflow improved as the team understood how to start improving the way they reviewed code. The team also gained confidence in their ability to review a metric, ask the right questions, and run experiments for improvement. With that, they started the process all over again. That’s what we call the cycle of improvement.
The Recap
The best way to get ravenous about removing delay in your workflow is to measure it. Here are the steps to start your own cycle of improvement:
Measure the time you actually spend doing a task (Active Time)
Measure the total time your task was in progress (Total Time)
Divide Active Time/Total Time and multiply by 100% to calculate your Flow Efficiency
Ask the question “What’s one thing I could change that may improve that metric?”
Implement that change
Rinse and Repeat
My hope is this will give you all the ability to start removing the delay in your workflow and get those solutions into the hands of the people that need them. It helped Mark and the T-Rexers. It helped me go from two weeks per book to one week per book. I’m confident it will help you too.
Until next time, keep on learning, keep on growing.
Mark Armstrong (the T-Rex guy) has a blog, Eradicate Lazy, where he talks more about his own journey. I encourage you to take a look!