Public Access

Community storytelling.

This post was created by a member of the Public Access community. It has not been edited for accuracy or truthfulness and does not reflect the opinions of Engadget or its editors.

Editor's Picks

Image credit:

Why I will probably refuse your meeting request and not answer my phone

Bob Summerwill, @BobSummerwill
07.24.15
Share
Tweet
Share
Save

Why I will probably refuse your meeting request and not answer my phone

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 constrained 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.

20150724_105245

Well guess what! Our personal "work streams" suffer from exactly the same concurrency problems as computers, because these patterns are innate characteristics of coordinated activities, whether they are in a digital form for computer programs or in organizational 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 they are unplanned then they are preempting the other person's priorities and causing a context switch. Flow is broken. The 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 you all of the time then you are not driving your own priorities. You are allowing other people to "override" your priorities with theirs.

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. Why not have an answerphone and call them back when you have some quiet time?

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 the quadrant diagram below. Repeatedly allowing unplanned synchronous tasks into your daily workflow traps you in quadrants Q3 and Q4. You really want to be spending time in Q2 as much as possible.

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 :-)

From https://en.wikipedia.org/wiki/First_Things_First_(book)#/media/File:MerrillCoveyMatrix.png

ear iconeye icontext filevr