If you are a geek like me, you will have a good understanding of synchronous versus asynchronous operations.
When most computers were only single-threaded with one CPU core there was little need for asynchronous operations. You would have queues and stacks for deferred work, but all operations were essentially gated by the total volume of work to be done. You could use data structures to change the order in which that work happened, but there was no potential for truly parallel work.
In my undergraduate Computer Science course in Leeds, UK, from 1993-1996 one of our text books was Ben-Ari’s Principles of Concurrent and Distributed Programming (1990) which covered the primitives which you need to introduce when you have more than a single thread, or for inter-process communication, or for multiple cores, or for multiple networked computers.
Anybody who has been through such a course will remember The Mutual Exclusion Problem and The Dining Philosophers Problem (both first noted by Edsger W. Dijkstra in 1965. That is 50 years ago), semaphores and mutexes. Our exercises at the time were on Transputers using Occam2. Those technologies are the ancestors of Clojure, Erlang, Rust, Scala and Stackless Python.
Well guess what? Our work “work streams” suffer from exactly the same concurrency problems as computers, because these patterns are the nature of the beast for any coordinated activities, whether that is in digital form for computers or in organization form for team activities within corporations.
Phone calls and meetings are synchronous operations. They force everyone involved to stop and wait for each other. If unplanned they are preempting the other person’s priorities and causing a context switch. Flow is broken. The most important work which the other person was focusing on just got bumped.
Synchronous operations ruin parallelism and overall organization efficiency. They force people into a “waiting” state at a frequency which is really unhealthy. If you allow other people to preempt your priorities all of the time then you are not driving your own priorities. You are allowing other people to “override” you constantly. We see this anti-pattern commonly with phone calls in shops. Somebody is helping you and then the phone rings and they “put you on hold” to answer the call. Well hello! I am right here, ready to buy something. You just bumped me for some random phone call which may or may not be important. That isn’t very nice. In the same way, constantly monitoring e-mail is a similar pattern. You are saying “Responding quickly to anybody who happens to send me an e-mail is more important than anything else I might currently be working on”.
Most people have probably seen this quadrant. Repeated allowing unplanned synchronous tasks into your daily workflow traps you in quadrants Q3 and Q4.
So … if I don’t answer your call, or reject your meeting request, please don’t be offended! Send me an e-mail or IM message (Lync, Twitter, Telegram, Hangouts) and I will get back to you asynchronously. I suggest that you consider doing the same yourself 🙂