“The more I see, the less I know for sure.” ~ John Lennon
WYSIATI is the acronym for de What you see is all there is, a cognitive bias described by Daniel Kahneman in his book Thinking, fast and slow, which explains how irrational we are when making decisions and how little it matters to us.
I already talked about this book in another article, but I remind you that it’s based on the co-existence of these two thinking modes in our mind:
- One, called System 1, functions in a fast and automatic way, without hardly any effort or a feeling of conscious control.
- The other, called System 2, is in charge of doing mental activities that need some effort, always on demand.
Most of the times, the System 1, which functions as a first filter, responds to anything without having to include System 2, the rational part. This is very useful to economize a good part of our activities, but it can be problematic when we make important decisions, because System 1 is often wrong.
WYSIATI refers to the fact that we normally make our judgements and impressions according to the information we have available. In general we don’t spend too much time thinking “well, there are still many things I don’t know”. Simply, we assert what we do know.
The most clear example of this phenomenon takes place when we meet someone. We take less than a second to build up an impression of people. Immediately, we decide whether they are kind and nice or dominant and hostile, and whether we will like them or not. And we do all this based on a very incomplete information, such as their facial features or the way they move.
When we make decisions, our mind only takes into consideration the things it know and, regardless of their quality and quantity, the only thing it tries to do with them is to build a coherent story. That’s enough. The story doesn’t have to be accurate, complete or reliable, it only has to be coherent. It seems incredible, right? A small group of incomplete, non representative information allows us to understand the world (obviously, our way.)
Making decisions this way is easy, comfortable, intuitive, and even worse, it makes us feel confident and competent at work.
At a personal level, it’s very difficult to avoid this kind of behavior because it’s in our DNA. The only thing that we can do is to recognize when the consequences of making a decision are going to be important and try to think slowly in such situations (something that most people didn’t do in the UK’s Brexit referendum.)
That’s why it’s good to let things cool down and not jump to a quick conclusion. When we avoid to respond immediately to something we allow System 2 play its role to build up a better opinion and, probably, inform us that we need more quality information to make a better decision.
In most cases it is wise to avoid the urge to immediately react to new stuff. This idea underlies in the separation between the two first stages of GTD: capture and clarify. Many times I realize that when I capture new tasks or ideas in my system and let it cool a couple of days before processing, I end up applying a much more suitable implementation approach than the one I would apply if I had processed them immediately.
8 comments
Re the last paragraph: That's why it would be great to have the possibility to defer processing of stuff items when necessary in FT. I share your experience and find it very inconvenient that I have to process all stuff items captured with FT. Of course I can apply a workaround, which I often do - but I'd prefer another option, e.g. a button labelled "Reprocess in..." and then a dialogue to set the duration. I strongly believe that this is also in compliance with strict application of GTD rules - being, at least in my understanding, part of what David Allen calls "Tickler" (or should be, if it's not - daring, I know). To avoid certain stuff items to be deferred over and over again, it'd be possible to come up with some kind of "warning" when processing of an item is deferred more than x times, where x in my case would be 1.
Re the last paragraph: That's why it would be great to have the possibility to defer processing of stuff items when necessary in FT. I share your experience and find it very inconvenient that I have to process all stuff items captured with FT. Of course I can apply a workaround, which I often do - but I'd prefer another option, e.g. a button labelled "Reprocess in..." and then a dialogue to set the duration. I strongly believe that this is also in compliance with strict application of GTD rules - being, at least in my understanding, part of what David Allen calls "Tickler" (or should be, if it's not - daring, I know). To avoid certain stuff items to be deferred over and over again, it'd be possible to come up with some kind of "warning" when processing of an item is deferred more than x times, where x in my case would be 1.
Hi Günther,
There's a natural way to do what you want in GTD (and FacileThings) and is the following: When you're processing something that need to get cooled, you have to put it in the Someday/Maybe list. That's all. The Someday/Maybe list is supposed to be the place where things that need to be "reprocessed" in the future live ;)
Thank you!
Hi Günther,
There's a natural way to do what you want in GTD (and FacileThings) and is the following: When you're processing something that need to get cooled, you have to put it in the Someday/Maybe list. That's all. The Someday/Maybe list is supposed to be the place where things that need to be "reprocessed" in the future live ;)
Thank you!
Hi Francisco,
thanks for your reply. While you're basically right, I deem it to be rather inconvient to do it this way. My Someday/Maybe list is very long and I need an efficient way to process stuff that I can't process rightaway* - stuff that will most likely actionable soon, thus being much more "tangible" than stuff I normally move to the Someday/Maybe list. How do you handle this?
I'll try it like this from now on:
1) Add a dedicated tag to stuff that I want to process later and move it to the Someday/Maybe list
2) Add a routine that ensures processing this elements on a regular basis
However, nonetheless I think it would be both more efficient and more convenient to have a dedicated "tickler list" for such items, so that they'd reappear in the inbox after a specific period of time or on a specific date. In addition, "process" in the Someday/Maybe list is not as streamlined as it is when processing the inbox.
Thanks and best regards
Günther
*there's another good reason for this being important: GTD is used in all areas of life and during any given day one collects stuff from all areas of life. While being in office, there has to be the possibility to process only stuff which does belong to this area of responsibility. If not, you regularly lose focus or at least time due to having to deal with stuff that belongs to other areas. In a dynamic work context with many action items being due very shortly after they occur, it is not viable to only process once a day, thus it is no option to collect during the day and to process in the evening or on the next morning.
Hi Francisco,
thanks for your reply. While you're basically right, I deem it to be rather inconvient to do it this way. My Someday/Maybe list is very long and I need an efficient way to process stuff that I can't process rightaway* - stuff that will most likely actionable soon, thus being much more "tangible" than stuff I normally move to the Someday/Maybe list. How do you handle this?
I'll try it like this from now on:
1) Add a dedicated tag to stuff that I want to process later and move it to the Someday/Maybe list
2) Add a routine that ensures processing this elements on a regular basis
However, nonetheless I think it would be both more efficient and more convenient to have a dedicated "tickler list" for such items, so that they'd reappear in the inbox after a specific period of time or on a specific date. In addition, "process" in the Someday/Maybe list is not as streamlined as it is when processing the inbox.
Thanks and best regards
Günther
*there's another good reason for this being important: GTD is used in all areas of life and during any given day one collects stuff from all areas of life. While being in office, there has to be the possibility to process only stuff which does belong to this area of responsibility. If not, you regularly lose focus or at least time due to having to deal with stuff that belongs to other areas. In a dynamic work context with many action items being due very shortly after they occur, it is not viable to only process once a day, thus it is no option to collect during the day and to process in the evening or on the next morning.
Hi Günther,
I think the way you're proposing is the good one. In principle, all stuff must be processed equally; otherwise you're establishing mental priorities before knowing exactly what each things is. What you need for more efficiency is not a way to process "what you want" (that's false efficiency) but probably a better way to review the Someday/Maybe list (and a stronger habit to do that.) We'll try to find a way to make it easier.
Thanks for exposing this case. It's very common and needs a better approach to address it.
Hi Günther,
I think the way you're proposing is the good one. In principle, all stuff must be processed equally; otherwise you're establishing mental priorities before knowing exactly what each things is. What you need for more efficiency is not a way to process "what you want" (that's false efficiency) but probably a better way to review the Someday/Maybe list (and a stronger habit to do that.) We'll try to find a way to make it easier.
Thanks for exposing this case. It's very common and needs a better approach to address it.
Hi Franscisco,
thanks for your reply. Of course everything has to be processed in a timely manner and with sufficiently deep consideration, however some things need an incubation time - if you look on the GTD Workflow Map published by David Allen, you'll see that "INCUBATE" leads to two possibilities: The "Someday/Maybe" list and "Date-specific" triggers. These triggers are what I'm after: If stuff is put back to inbox at the defined trigger time, it is ensured that it is processed with due diligence in the course of the normal processing routine - instead of being shoved to the Someday/Maybe list and requiring an additional routine along with dedicated tags to handle them both properly and efficiently.
When I'm in my current office environment I of course do have specific mental priorities when processing my inbox: It is a big project, very dynamically, leading to much ad hoc work and thus requires more than one processing sessions per day. On each office day there are quite a lot of stuff items which simply don't have to be fully* processed during the scheduled processing work in this specific office context (one in the morning and one after lunch break in my case, at times even more often in case of urgent ad hoc activities with high complexity ) - it is sufficient to process these in the evening session (and there I might come to the conclusion that they even need a longer incubation time, after which it would be best if they reappeared in my inbox).
However, I have a suggestion for a "quick win": Why not simply add the option "Move to Inbox" to items in the Someday/Maybe list? In many cases it would be very beneficial to the "flow" if items of this list could be processed during the regular processing instead of immediately via the item-level option "process".
Thanks again and best regards
Günther
*ad "fully": means that all items are processed to the extent that a qualified decision is possible whether it's okay to postpone processing an item for a few hours - at times full processing is time intensive and also requires a change of focus which might be disruptive.
Hi Franscisco,
thanks for your reply. Of course everything has to be processed in a timely manner and with sufficiently deep consideration, however some things need an incubation time - if you look on the GTD Workflow Map published by David Allen, you'll see that "INCUBATE" leads to two possibilities: The "Someday/Maybe" list and "Date-specific" triggers. These triggers are what I'm after: If stuff is put back to inbox at the defined trigger time, it is ensured that it is processed with due diligence in the course of the normal processing routine - instead of being shoved to the Someday/Maybe list and requiring an additional routine along with dedicated tags to handle them both properly and efficiently.
When I'm in my current office environment I of course do have specific mental priorities when processing my inbox: It is a big project, very dynamically, leading to much ad hoc work and thus requires more than one processing sessions per day. On each office day there are quite a lot of stuff items which simply don't have to be fully* processed during the scheduled processing work in this specific office context (one in the morning and one after lunch break in my case, at times even more often in case of urgent ad hoc activities with high complexity ) - it is sufficient to process these in the evening session (and there I might come to the conclusion that they even need a longer incubation time, after which it would be best if they reappeared in my inbox).
However, I have a suggestion for a "quick win": Why not simply add the option "Move to Inbox" to items in the Someday/Maybe list? In many cases it would be very beneficial to the "flow" if items of this list could be processed during the regular processing instead of immediately via the item-level option "process".
Thanks again and best regards
Günther
*ad "fully": means that all items are processed to the extent that a qualified decision is possible whether it's okay to postpone processing an item for a few hours - at times full processing is time intensive and also requires a change of focus which might be disruptive.
Hi Günther,
In FacileThings, the two ways of "incubating" explained by David Allen (Someday/Maybe and Date-specific triggers) are implemented the same way: the Someday/Maybe list. It allows to set date-specific reminders precisely to cover both options.
Items in the Someday/Maybe list don't need to go back to Inbox, since you can process them there.
I invite you to continue this discussion within the Support system or by email. I think it's going beyond this article's topic ;)
Thank you!
Hi Günther,
In FacileThings, the two ways of "incubating" explained by David Allen (Someday/Maybe and Date-specific triggers) are implemented the same way: the Someday/Maybe list. It allows to set date-specific reminders precisely to cover both options.
Items in the Someday/Maybe list don't need to go back to Inbox, since you can process them there.
I invite you to continue this discussion within the Support system or by email. I think it's going beyond this article's topic ;)
Thank you!
Your article reminded of how mentats operate. They are characters in F. Herbert's fictional novel 'Dune': "You do not withhold information or computation lines from a mentat". They are as good as the information they receive and the same thing applies to our mind.
Your article reminded of how mentats operate. They are characters in F. Herbert's fictional novel 'Dune': "You do not withhold information or computation lines from a mentat". They are as good as the information they receive and the same thing applies to our mind.
Hi Tiago,
I haven't read that novel, but I couldn't agree more with the statement you mention. It's exactly the same idea I'm trying to convey in this article.
Thanks for sharing!
Hi Tiago,
I haven't read that novel, but I couldn't agree more with the statement you mention. It's exactly the same idea I'm trying to convey in this article.
Thanks for sharing!