There are lots of suggestions about how to become more productive. There is a long history of performing detailed analysis of tasks to improve flow and reduce performance time. Frederick Taylor was one of the earliest advocates of "time and motion studies" to improve the performance on factory lines.

A popular task analysis technique is called "hierarchical task analysis" which involves identitying the major steps to completing a job, and then breaking each of the major steps into the component steps required to complete it. For example, the major steps required to "Make Hay" includes:

Cutting the hay
Teddering the hay (optional)
Raking the hay
Baling the hay
Storing the hay

If you want to go deeper, you can break down each of these steps (e.g., cutting the hay) into the lower level steps required to complete that step (e.g., mount mower to tractor, lubricate the mower, adjust tractor arms if necessary to level the mower, check the cutters and repair if necessary, check the belts, load up on tractor fuel, pick an opportune time to start, mow).

You don't need any special tools to do an hierachical task analysis than a pencil and paper. If you have not engaged in hierarchical task analysis before it might be worth identifying some upcoming job you need to perform and use hierarchical task analysis to break it down into its higher level steps, then break down those steps into the lower level steps required to complete the higher level step, and so on.

The HTML language provides ordered an unordered list tags if you want to use a computer and text editor to document the structure of a job using HTA. Some of the tasks listed in your breakdown might have a sequential relationship to the task before and after task in which case you might want to use the ordered list tag. When the tasks are not in an ordered relationship to each other, then you might decide to use the unordered list tag. You can then render your HTA in a web browser. This is a partial HTA for "Making Hay" to illustrate how to mark up your HTA;

<ol>
<li>Cutting the hay

<ul>
<li>Mount mower to tractor
<li>Lubricate the mower
<li>Adjust tractor arms if necessary to level the mower
<li>Check the cutters and repair if necessary
<li>Check the belts
<li>Load up on tractor fuel
<li>Pick an opportune time to start
<li>Mow fields
</ul>

<li>Teddering the hay
<li>Raking the hay
<li>Baling the hay
<li>Storing the hay
</ol>

Todo lists are an often used tool for being productive. Todo lists, however, can hide alot of the complexity involved in performing a task. A simple way to think about a todo list is that you create a list of tasks that you want or need to accomplish and check each of them off when they are done.

Lately I've been frustrated by the fact that before I can engage in doing a task I either have to fix something, find some item, or buy some item involved in completing the task. The various common ways in which your todo list tasks can become more difficult I call "productivity impasses".

As an example, we recently buried a power line to our barn which involved digging a trench to lay the power line in. That created bare soil so I wanted to spread some grass seed over it and water the seeds in. Watering the seeds in involved hooking up a hose to a sprinkler and moving the sprinkler around before and after planting. Not a big job, but I forgot that at the end of last year I had difficulty removing the spray nozzle because I didn't take it off all season and it became cemented to the hose end. I used an angle grinder to remove it and ended up cutting into the hose end. When I attached that hose end to the sprinkler it sprayed out water at the connection point. So I spent some time trying to find a hose end connector needed to fix the hose (I often have a hose end connector lying around in case) but eventually decided to go out to a hardware store and pick up a new hose end connector. I then returned home, fixed the hose, and watered in the grass seed. So to accomplish this task I had to spend time looking for a needed part, buying a needed part, and fixing the hose with that part before I could finally accomplish the task of watering in the grass seed.

This is an example of a find-then-do impasse, a buy-then-do impasse, and a fix-then-do. The need to find, buy, and fix stuff are often not included in the description of a task which might be stated as "water in the grass seed".

Another common impasse is the agree-then-do impasse where the time it takes to agree to do something eats up alot of the time that could be dedicated to getting on with the task. It can often be good to get different perspectives on a job, but it could become dysfunctional if you can't reach agreement in a timely manner.

A learn-then-do impasse occurs where instead of just getting on with doing the task, you have to spend time learning how to do it. For me, this often involves watching a few youtube videos until I get a good sense of how it should be done.

It is not clear whether you can anticipate all the impasses that might impede your performance of a task but knowing that some common types impasses might arise could be helpful in becoming less frustrated in managing your todo lists and better at estimating how long it might take if you factor in potential impasses.

One approach to creating more effective task lists might be to associate each task with a list of properties that might be specified to detect possible impasses. For example, the "Water in the grass seed" task might have this task description and set of properties to fill out or think about.

• Requires:
• Fix:
• Find:
• Buy:
• Learn:
• Agreement Required:

A task might have lots of properties worth analyzing, but the theory here is that examining tasks in terms of common potential impasses might be a good use of time. I am also aware of the "paralysis by analysis" concern and wouldn't get this detailed about most task planning.

A completed Task Properties List (TPL) might look like this:

• Requires: Water Supply, Water Hose, Sprinkler
• Fix: Fix hose end. Get water working again in garden shed.
• Find: Hose end, Water Hose, Sprinkler
• Buy: Hose end
• Learn: No new learning required
• Agreement Required: No

Originally, my task was just to "Plant the grass seed" until the issue of getting hoses to work made "water in the grass seeds" a separate task. The Task Property List for planting the grass seed looked something like this originally:

• Requires: Grass seed, water, tamper
• Fix: Remove large rocks, add river sand to level soil, tamp down soil, tamp seed into soil
• Find: Tamper
• Buy: Grass seed
• Learn: Watch youtube videos on planting grass seed
• Agreement Required: No

The scope of a task is another aspect one might reflect on when analyzing a task. Tasks often have a hierarchical structure with tasks embedded in higher level tasks. The task description should describe a task at the proper level of embedding. If the task is too high level, it might take a long time to complete whereas if you want to complete 5 tasks today, you might have to formulate your task description in way that makes those tasks doable in a day.

A different type of impasse is a fix-then-fix impasse where a fix creates other issues that have to be fixed. The task of "installing a new electrical service to the barn" created the task of reseeding the area that was ripped up to bury the line. Connecting the power line to a new service panel in the barn also created a plumbing issue because the water line ran where the panel was installed. So the task of installing a new electrical service to the barn created the need to fix the soil that was ripped up and to fix a plumbing issue. You could include these fixes as properties of the original task but generally it is better to think of the fix-then-fix type of impasse as generating new separate tasks to distinguish them from the smaller fixes that need to be completed to finish the task at hand.

Conclusion

I don't spend alot of time analyzing tasks in this level of detail. I was spurred to do so after noticing certain patterns in the types of impasses I was running into when trying to accomplish a farm task. I decided to itemize common types of impasses and then to analyze tasks by asking whether one of these impasse types might arise. The tool for doing this I call the Task Properties List that has field labels associated with common impasse types.

Whether this is useful approach or not, I don't know, but it does seem like an interesting way to think about the structure of tasks. I chose the term "impasse" to describe these productivity zappers because there is a literature on impasse driven learning that might be relevent but which also might extend the concept of an impasse in more practical ways then the academic literature tends to do.

Anne Duke published a popular book called Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts (2018). Lately, I've been reflecting on the concept of "thinking in bets" as it seems pertinent to some business decisions I needed to make recently. Julia Galef, who hosts the Rationally Speaking podcast, had an excellent discussion with Anne on some of topics in the book.

The idea for Thinking in Bets was inspired by Anne's previous career as a successful poker player (won over 4 million). Poker playing is a game that involves strategy, uncertainty (i.e., what cards other players have and what cards are left in the deck), and luck (good and bad). Investing can be viewed through the lens of "thinking in bets" because it involves similar elements of strategy, uncertainty and luck.

Thinking in Bets can involve other types of outcomes than winning money. The decision to move to a new city, for example, can be viewed as a bet that the future will be better in that city than in other possible cities.

When making a bet we envision various possible future outcomes, weight their likelihood of happening, and assign some value to them. In situations where there are unavoidable elements of uncertainty and luck, then we might want to frame the decision in terms of betting on a future outcome.

Event Planning Bets

Me and my wife held an outdoor concert event at our (agritourism) farm property the last 2 years and this will be our third annual outdoor concert. Last year's 2nd annual event was a bet that worked out because we were able to host it (250 limit), we created a memorable event and a stronger event brand, and we eked out some profit. You can't expect large profits when your attendance is capped.

This year is another bet that we will be able to achieve a certain gathering size at a particular time of year. We made the bet in march that we would be able to host at least 250 attendees again this year on the third weekend of August and budgeted accordingly so that we might again eke out a profit.

We were easily able to sell out the tickets for this event. We used facebook primarily to generate awareness of the event. We decided to add another event the night before and that sold out quickly as well.

These bets have a good potential upside at this point if we are able to host a larger gathering size. One of the reasons we added a second event was because we could reduce costs on sound and portable toilets and generate more profit per event as a result.

There is still hidden information about the future that could derail our plans (e.g., delta variant), and of course, the weather might not cooperate and create a less than stellar event experience. The unavoidable uncertainty and role of luck, gives the decision to host an event a betting aspect.

Covid has created difficulties in hosting profitable events largely due to crowd size restrictions. It has also opened up an opportunity to create an event brand that is reliably offering high quality entertainment, while most events that traditionally ran at higher cost are no longer happening and are still being cancelled.

The payoff for these bets is really next year if everything goes well this year. If things open up further by August and we can host, say, 500 people, and do that for two days, that would make this event more profitable and set us up for hosting 2000 per event next year. Hosting 2000 people on a farm is not something you would necessarily want to do in your first year. Alot of infrastructure has to be built and tested and venue building is ongoing to reach that stage. Next monday, for example we will be upgrading power to the barn (installing a new service) as the 100 amp subfeed from the farm house is barely sufficient for the power requirements for speakers and other draws on the day of a concert.

Conclusion

In this blog I introduced the concept of thinking in bets. As an example of thinking in bets, I discussed how it seems relevant to the decision making involved in hosting an outdoor concert event. Thinking in bets is a very rich subject and we only skimmed the surface here to create awareness of this approach. Thinking in best has applications to investing and starting a business that are interesting to think about.

Tim O'Reilly's recent blog has some interesting discussion on "the betting economy".