Discussion Forum > On Grazing vs. Hunting
Thought-provoking.
Isn't lack of flexibility the Achilles' heel of many "hunter" systems? I mean, it sounds attractive to drive one or two tasks to completion... but in the meantime, a long list of other urgent, time-sensitive, or more propitious tasks emerges. This is one area where "grazing" systems shine.
An interesting attempt to combine aspects of both types of systems is Superfocus (Version 3). Column 2 = hunter. Column 1 = grazing.
Isn't lack of flexibility the Achilles' heel of many "hunter" systems? I mean, it sounds attractive to drive one or two tasks to completion... but in the meantime, a long list of other urgent, time-sensitive, or more propitious tasks emerges. This is one area where "grazing" systems shine.
An interesting attempt to combine aspects of both types of systems is Superfocus (Version 3). Column 2 = hunter. Column 1 = grazing.
October 26, 2022 at 3:35 |
Belacqua
Belacqua
This is a good analysis and a good analogy.
On timeblocking and huntering - there are some activities that require a warmup, 20 minutes, an hour, whatever, before reaching the "flow" state. Using a long list, flitting from one task to another - one might not reach the flow state. Some tasks that take an hour or longer might better be done at one time. On the other hand, it is possible to try to do one item until finished when it is more than one is capable physically or mentally - one lacks the stamina or will power. Or one can be tempted to spend more time than necessary, or overthink, or be perfectionistic.
Some of this depends on the type of work, work environment, control over one's work, and personality. So if the tasks are rapidly coming and rapidly going out, such as the work of a coordinator or secretary, or the items are granular, the grazing model might work better. If one has control of one's work and there is a specialization, the hunter model might work better.
On timeblocking and huntering - there are some activities that require a warmup, 20 minutes, an hour, whatever, before reaching the "flow" state. Using a long list, flitting from one task to another - one might not reach the flow state. Some tasks that take an hour or longer might better be done at one time. On the other hand, it is possible to try to do one item until finished when it is more than one is capable physically or mentally - one lacks the stamina or will power. Or one can be tempted to spend more time than necessary, or overthink, or be perfectionistic.
Some of this depends on the type of work, work environment, control over one's work, and personality. So if the tasks are rapidly coming and rapidly going out, such as the work of a coordinator or secretary, or the items are granular, the grazing model might work better. If one has control of one's work and there is a specialization, the hunter model might work better.
October 26, 2022 at 17:47 |
Mark H.
Mark H.
A very thought provoking analogy. Thank you. As I have reflected on what my preference actually is, I personally prefer grazing in general but I can see that I occasionally need to go on focused "hunting trips". I think that is why systems that are a proponent of carving out full days for different types of work are appealing. I see no reason why you couldn't schedule both hunting days and grazing days. How many days you schedule for each type is also a personal preference. For me, I'd probably be most successful with a 80/20 split (favoring grazing). This analogy of yours sort of makes me see now that I don't necessarily need to be 100% dedicated to one or the other. So thanks again for the thought provoking post.
October 27, 2022 at 0:22 |
Brent
Brent
The problem with too much choice ("grazing") is you can start many things and finish only very few. So a lot of time can be spent in starting and not finishing. In some contexts, this is very wasteful. In other contexts, the main thing you need is actually information, not results -- so you need to start the things that are most likely to enable you to learn, whether or not you ever finish them. The starting and not finishing is exactly what you need -- you need to enable fast learning.
The problem with too much focus ("hunting") is you can stick with one task far beyond the point where it is giving you the desired value. It may be better to raise one's head, look around, and realize there's a much better way to realize greater value.
These different approaches are suited to different kinds of environments.
In chaotic and complex environments, you may not have clear idea of cause-and-effect -- your main need is learning and information. This applies to things like emergency response and medical triage. It also applies to product development, software development, and blue-ocean marketing. The "grazing" model is better here. The situation benefits from lots of exploration, learning, trial-and-error. Lots of small experiments. Early commitment can be a huge mistake -- making decisions with a long-lasting impact, when it's too early and you have very little information. "Agile" is a good method for this domain. "Triage" methods work well here because they are designed to quickly discover critical information.
In simpler domains, where cause-and-effect is a lot more clear, the main need is efficient execution. There are fewer unknowns. This is the domain of factory processes; assembly lines; project plans and Gantt charts; "making and meeting commitments".
Most people, I think, tend to develop a career in one of these two domains, and develop expertise in either effective exploration, or efficient execution. Once the advance team figures out the chaos and complexity, they hand it over to the execution team to deliver the actual results. Engineers design the product; technicians build it. Triage specialists identify the wound; surgeons repair it. Architects work with the homeowner to figure out what to build and design the plans; contractors build the house.
But in personal time management, most of us straddle both of these domains, and must move between them fluidly throughout the day. We can leverage the same dynamic that are described above: develop effective ways to do the exploration / triage / development; develop efficient ways to execute / perform / build; and get really clear about when to make the transition one domain to the other.
My own tendency is to gravitate to the chaos; I love to explore and learn. I find huge value in surfing the chaos. It's a special mindset and skillset. But I love the exploration so much, it can be hard for me to settle down and execute. I'd rather give that job to someone else, so I can go sort out the next crazy situation.
But when I need to do the tasks myself, this is what works for me: I need to stop, settle down for a moment, and think clearly and calmly. I write down whatever comes to mind -- what are all the things niggling at me. Then I review this short list. Some of the items stand out as needing to get done ASAP. Others stand out as the next important problems to explore. Some are less clear, a kind of gray zone.
But this gives me a priority:
1-- First execute whatever can be executed, in order of urgency.
2a-- Then do some triage on the gray zone middle items to figure out if they need execution (do it next)
2b-- Or maybe the triage reveals the gray zone item needs exploration (sort it out with the other exploration items)
3-- Then choose the most critical thing to explore, following my intuition, and using an probe-sense-respond and/or act-sense-respond model to figure out where to focus.
That ordering usually works very well for me.
I spend most of my time surfing the chaos -- so a No List model works well for me personally. Serial No-List is especially well suited to the model I just described.
DIT is much more suited to a domain requiring focused execution.
The long-list systems can manage a combination pretty well. For example, FVP responds very well to changing priorities and urgencies, but then once the crisis is past, you can work systemically just getting stuff done.
The problem with too much focus ("hunting") is you can stick with one task far beyond the point where it is giving you the desired value. It may be better to raise one's head, look around, and realize there's a much better way to realize greater value.
These different approaches are suited to different kinds of environments.
In chaotic and complex environments, you may not have clear idea of cause-and-effect -- your main need is learning and information. This applies to things like emergency response and medical triage. It also applies to product development, software development, and blue-ocean marketing. The "grazing" model is better here. The situation benefits from lots of exploration, learning, trial-and-error. Lots of small experiments. Early commitment can be a huge mistake -- making decisions with a long-lasting impact, when it's too early and you have very little information. "Agile" is a good method for this domain. "Triage" methods work well here because they are designed to quickly discover critical information.
In simpler domains, where cause-and-effect is a lot more clear, the main need is efficient execution. There are fewer unknowns. This is the domain of factory processes; assembly lines; project plans and Gantt charts; "making and meeting commitments".
Most people, I think, tend to develop a career in one of these two domains, and develop expertise in either effective exploration, or efficient execution. Once the advance team figures out the chaos and complexity, they hand it over to the execution team to deliver the actual results. Engineers design the product; technicians build it. Triage specialists identify the wound; surgeons repair it. Architects work with the homeowner to figure out what to build and design the plans; contractors build the house.
But in personal time management, most of us straddle both of these domains, and must move between them fluidly throughout the day. We can leverage the same dynamic that are described above: develop effective ways to do the exploration / triage / development; develop efficient ways to execute / perform / build; and get really clear about when to make the transition one domain to the other.
My own tendency is to gravitate to the chaos; I love to explore and learn. I find huge value in surfing the chaos. It's a special mindset and skillset. But I love the exploration so much, it can be hard for me to settle down and execute. I'd rather give that job to someone else, so I can go sort out the next crazy situation.
But when I need to do the tasks myself, this is what works for me: I need to stop, settle down for a moment, and think clearly and calmly. I write down whatever comes to mind -- what are all the things niggling at me. Then I review this short list. Some of the items stand out as needing to get done ASAP. Others stand out as the next important problems to explore. Some are less clear, a kind of gray zone.
But this gives me a priority:
1-- First execute whatever can be executed, in order of urgency.
2a-- Then do some triage on the gray zone middle items to figure out if they need execution (do it next)
2b-- Or maybe the triage reveals the gray zone item needs exploration (sort it out with the other exploration items)
3-- Then choose the most critical thing to explore, following my intuition, and using an probe-sense-respond and/or act-sense-respond model to figure out where to focus.
That ordering usually works very well for me.
I spend most of my time surfing the chaos -- so a No List model works well for me personally. Serial No-List is especially well suited to the model I just described.
DIT is much more suited to a domain requiring focused execution.
The long-list systems can manage a combination pretty well. For example, FVP responds very well to changing priorities and urgencies, but then once the crisis is past, you can work systemically just getting stuff done.
October 28, 2022 at 7:51 |
Seraphim
Seraphim
For example, systems like GTD and most/many of Mark's systems tend to default to things being active, and then only after some amount of work on them (processing, thinking, organizing, or doing), they may "die" or be put to pasture for a while. The AF systems with dismissal are a great example of this, but so are all of the discussions about weeding. In these systems, the default is active and doable.
On the other hand, systems like Personal Kanban, Ivy Lee, Full Focus, and others, are all built around the default state of a given task being inactive, or not doable. Things can go onto a list, but you can't actually *do* those things right off the bat. Instead, they have to somehow find space somewhere in a limited queue or bucket in order to work on that task within the system. In most of these systems, you can't do a little work on something and then put it away. For instance, in most Personal Kanban systems, you aren't supposed to take an item out of your "Doing" column and move it back to the "Ready" column to make room for new work. You are supposed to actually *finish* that work before you can add something new to take its place (or put it in a Waiting For column or some other column around blocked tasks). This is very different than most of Marks present systems, which tend to have no restrictions on the number of items that can be worked simultaneously, at least in theory.
In a sense, both system types are designed to try to get you to focus on things, but they come at it from different views. Some of Mark's earlier systems were more of the "default no" types than newer systems, but Mark's newer systems have all seemed to tend more towards a freedom of choice with a wide range, permitting very large numbers of active tasks in progress at a given time.
I think of these "zero resistance" type of systems as grazing systems, in which you can sort of flit between various things. In practice you might tend to stay in one general area for a while and work that grass, but in principle you could walk all over the place. Other systems, I think of as "hunter" systems, where you identify a specific target, and you either kill (finish) that target or it goes by and you look for something else. You might have to pursue a single target for a while, but in such cases, you either finish that task or not, you don't pursue multiple targets at the same time.
It's interesting that so many "hunting" systems tend to hover in the range of 3 - 7 active things at any given time. A few go down to 1 and a few go higher, but for the most part they hover in that range. The Eat the Frog/Ivy Lee type systems are the most aggressive in that they have you work one task to completion before moving on to anything else. Personal Kanban and the like simply have you working on a limited number where at least one of them has to be finished before new work can be added.
One could also look at Mark's no-list systems in this light, since they have built in limiters for a day, often times. But even in these cases, between the days, you can work on as many different things as you want, since the commitments of a past day do not carry over into the next.
I find myself contemplating if there is any inherent total advantage to one or the other of these methods.
On the one hand, the hunter systems are very focused and have the benefit of completely undermining attempts to "do too much" and in that way serve as a very cold and abrupt solution to an overly long list. It doesn't matter how long your input queue is, you'll only ever have a limited set of active things at a time, and from there and the cycle time/lead time on working through tasks, it becomes abundantly clear just how long or not things will take. You can't "lie" to yourself and think that you're accomplishing more than you are. Of course, this also means you need to directly confront the related psychological realities that emerge from this.
On the other hand, grazer systems have the immediate appeal of feeling much more relaxed. You don't have to immediately confront the reality of not having time to do it all. There's very little pressure in these systems, all things considered. You also don't need to be nearly as clean or clear on things like task size, because how big of a task you are working on doesn't matter, since it doesn't prevent you from doing things elsewhere. You could nibble a little bit on a giant tree and then go eat some small patches of grass without worrying that you haven't eaten the whole tree yet, whereas a hunter system would require you to break down any given task into something small enough to *finish* on your list if you want to be able to continue to add new things at some given cadence.
So, I guess it all comes down to the question, is it better to put it on a list and have everything available to you, only pruning after the fact, or is it better to refuse to start working on something until other things are finished, first?
I recall that there were some discussions and explorations on this topic throughout the years with various systems toying with this idea on this forum and in Mark's books, but I think some of those often struggled with the issue that they sometimes restricted the collection of tasks as well as the doing of tasks. I think we want to be able to freely collect up tasks and ideas and write them down, ready for action, no matter what the system, but it is the limitation on the doing that is the question.
So what do you prefer? Right now, I keep coming back to systems that are of the hunter variety.