Listen to this post: You can download the MP3 file or subscribe in iTunes. You can read the article by Mattias Sander here: Become more productive and motivated. The article originally appeared in the ISTC Communicator (Summer 2016). Sander begins general and describes Lean principles: The idea of Lean is to maximize customer value while minimizing waste, thus creating more value for customers with fewer resources. He explains the main reasons for waste. One of these reasons is “Motion”: Motion is the waste of movement around a product or work-item, for example, reaching too far to grab a tool. These abstract principles about Lean eventually get more specific, focusing on the familiar problem of multi-tasking and context-switching, which turn out to be a sizable drain on efficiency: Task switching could be considered to be Motion. Some estimates say that you lose 40% of your time because of task switching. Here Sander gets into about Kanban as a solution to task switching. The basic idea of Kanban is to limit the number of tasks you’re doing at a given time so that you aren’t constantly switching activities and losing the context you need to be productive. With Kaban, you break up your tasks into 3 basic categories: Backlog Doing Done You allow only a limited number of items (for example, 3) in your “Doing” category. Sander explains: The more we have [in our Doing category], the slower we produce because of the task switching. We can use the Kanban method to reduce our work in progress, and to help us keep track of what we need to produce. I’m constantly bombarded with emails, instant messages, social media notifications, and meetings, not to mention having multiple projects I’m working on, so it’s hard to not get swept into the inefficiency of multi-tasking. Sander’s article resonates with a post I read by Joel Spolsky — [Human Task Switches Considered Harmful][http://www.joelonsoftware.com/articles/fog0000000022.html]. Spolsky talks about the inefficiency that occurs specifically when programmers have to switch tasks: The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve. Spolsky argues that rebuilding the necessary context to do a complex task like programming is what creates the inefficiency. Consequently, Spolsky says programmers should stick to one task only: As it turns out, if you give somebody two things to work on, you should be grateful if they “starve” one task and only work on one, because they’re going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. I currently have two main projects at work, but both could easily occupy my work full-time. In an ideal world, I would simply offload one project onto “someone else.” Since that “someone else” does not exist, I have to figure out how to juggle both projects without the drain in efficiency. Once I get moving in one direction, I find it really hard to put the brakes on and start accelerating in another direction. The time it takes to stop and then restart in the new direction creates the inefficiency, which gets multiplied the more times I stop and start. Assumin