It’s time to examine the good, the bad, and the very ugly elements of context switching. Even better, we’ll take a look at some strategies for managing it.
You say that getting back to the task spent 23 minutes. But I can't find it in the text that you link for. Moreover, they say that people who had been distracted finished tasks faster than people who hadn't. Could you find the part about 23 minutes and copy it here?
Well written post. IMO, most of us working in IT services would face context switching challenges quite often specifically around production support / incident management situation. It is kind of everyday situation where in engineer has to switch many applications for the root cause analysis. I see the cognitive load on the team when we encounter multiple P1 tickets of critical systems. But I agree that, intentionall breaks during the course of the day would break the monotony or sometime it is recipe for new idea.
This is also how stupid people keep winning debates against smart people. The smart person is busy thinking of something complex, nuanced and important. Then the stupid person throws some dumb accusation at them, causing them to lose their train of thought. A lot of important points don’t get heard, because of this.
I don't know why everybody is considering e-mail replies as a low priority/or shallow work?! Maybe a reply to an e-mail or slack message can save hours to the other part and help him to perform well.
Interruption is bad, yes, we agree with that. But the solution is not as simple as changing status to "Do not disturb" and ignoring the rest of the world around.
I treat interruptions the same way as I enforce boundaries. No matter what the interruption is, I need X minutes to be at a stopping point (aka shelve my work, write notes to come back to) with the current work. Eventually some interruptions come as "I need you in 5 minutes"
You say that getting back to the task spent 23 minutes. But I can't find it in the text that you link for. Moreover, they say that people who had been distracted finished tasks faster than people who hadn't. Could you find the part about 23 minutes and copy it here?
Well written post. IMO, most of us working in IT services would face context switching challenges quite often specifically around production support / incident management situation. It is kind of everyday situation where in engineer has to switch many applications for the root cause analysis. I see the cognitive load on the team when we encounter multiple P1 tickets of critical systems. But I agree that, intentionall breaks during the course of the day would break the monotony or sometime it is recipe for new idea.
I wrote on the same topic a few weeks ago and today stumbled upon this post.
https://ammarahmad977.substack.com/p/context-switching-in-software-development
This is also how stupid people keep winning debates against smart people. The smart person is busy thinking of something complex, nuanced and important. Then the stupid person throws some dumb accusation at them, causing them to lose their train of thought. A lot of important points don’t get heard, because of this.
I don't know why everybody is considering e-mail replies as a low priority/or shallow work?! Maybe a reply to an e-mail or slack message can save hours to the other part and help him to perform well.
Interruption is bad, yes, we agree with that. But the solution is not as simple as changing status to "Do not disturb" and ignoring the rest of the world around.
Great article btw. Thank you Addy!
I treat interruptions the same way as I enforce boundaries. No matter what the interruption is, I need X minutes to be at a stopping point (aka shelve my work, write notes to come back to) with the current work. Eventually some interruptions come as "I need you in 5 minutes"