The Avocado Toast Fallacy
A few minutes here, a few minutes there, it adds up. Right? Sometimes yes, sometimes no. Whether it’s time or money, we are attracted to the small optimizations as easy ways to make a difference.
When we focus on optimizing business processes, these are often called “low hanging fruit”. These are easy to conceptualize and define, and when the savings adds up over days, weeks, and months, the degree of impact translates to very good numbers. 6 minutes a day means 30 minutes a week. 30 minutes becomes 2 hours in a month. 2 hours a month over 11 months (PTO/Holidays), you saved 22 hours. That’s half a week of additional productivity!
Except, we intuitively know that this is bad math.
The Avocado Toast Fallacy shows up when we assume that small savings will add up over time through repetition to achieve bigger, meaningful savings. In short, the optimizations accumulate.
Quick History of the Avocado Toast Fallacy
Millennials, like myself, will remember the time when avocado toast became an international subject of fiscal responsibility and the affordable housing crisis. It’s also remembered as a lame attempt at bad math.
It started off from an interview by 60 Minutes Australia with the millionaire property developer Tim Gurner’s rather embarrassing claim that if people didn’t buy avocado toast and high-end coffee, there would be more home owners. This line of thinking didn’t start with him, and it won’t go away either. That’s because the underlying logic of it is fairly sound.
Small savings do add up and can make a significant impact in life, just not to the level of a house.
This isn’t a fallacy because the logic is inherently wrong.
It’s a fallacy because we assume it applies when we have measurements that can show incremental savings. We intuitively know it’s wrong when it oversimplifies the conditions around what is being saved and how the savings accumulates.
Traffic Lights and Assembly Lines
We have good intuitions on when a small optimization actually works, and where the math just “seems wrong”. In assembly lines, the hyper optimization of seconds and minutes does pay off, a lot. Tens of millions of dollars are invested in finding and implementing these optimizations because the return on these investments is huge. And there are many processes where this is also the case.
But, most life resembles traffic lights and travel times instead of assembly lines. This goes for most work as well. When we’re late to be somewhere, we often speed to catch up on time. Then we get there in the same time that Google Maps said we would, and Google Maps didn’t factor in our lateness or speeding.
This specific type of lack of improvement is so ubiquitous that we even have a name for it: “Hurry up and wait”.
When is something a Traffic Light, and when is it an Assembly Line?
When looking for areas to optimize, it’s critical to know what situation we are in. Otherwise, predicted time savings don’t add up to actual productivity in an office. We may actually waste time in trying to not waste time. And it’s really annoying to do something that’s “better”, but we clearly see that nothing has changed.
To help diagnose whether we’re committing the fallacy, we’ll need some terms and definitions.
Isolated: Are there other tasks in the process that can be substituted in? Is a range involved for when something is has begun or ended? Are there other processes that can be done in the meantime?
Cumulative: Do the savings continue in any broader tasks or situations? Are there many downstream tasks that depend on this task being completed so that they can be done earlier?
Interruptible: If the task is paused in the middle, can it be picked up right where it was left off? Or does it require a ramp up, like reviewing or going over what’s already been done? Is there context switching that is needed to in order to resume the task?
Measurable: Does the task have a clear beginning and ending? Can you list off objective criteria for when something is done?
Revisiting Traffic Lights v. Assembly Line
With these 4 criteria in hand, let’s look at our two initial examples.
Assembly Line
Isolated? Yes. With the car on the rails, it cannot be moved to another station, or substituted with a different task. Those welds have to happen at a specific point, and other tasks can’t be done in the meantime.
Cumulative? Yes. If the welds are not done, the downstream work cannot be completed. Also, the precision and consistency of the tasks on the assembly line means that no other task will swallow up the time savings.
Interruptible? Yes. If half the welds are finished, you pick up with the next weld. You don’t need to revisit your previous work.
Measurable? Yes, absolutely yes.
Think of assembling the frame of a car. There are a fixed number of welds and a clear time to complete all of them. Installing doors has a “doors” or “no doors” policy.
We know when a part of the process begins and it ends, and we can clearly determine these points in the process.
Traffic Lights and Travel Time
The goal is to get from A to B, let’s say it’s 20 miles. It’s made up of a lot of small steps between traffic lights. We’ll use this as the breakdown of the Goal (like building the car), and the Tasks (getting from traffic light to traffic light). I’ll talk more about how to break things down with examples after this.
Isolated? Deceptively no. This one is a little tricky and it’s because we’re framing the steps too narrowly. While you do have to get from the second light to the third light through these 4 blocks, that’s only if we chose those 4 blocks because they are the shortest distance and along a set path.
There’s many times where we can take a detour through slower roads and longer distances and get somewhere faster. How you define your path for the sequence of tasks is critical. This will show up in the yard planting example.
Cumulative? No. To understand this, think about what a long red light means. While you have to go through some path, it doesn’t matter if you got to the red light 5 seconds before it turns green, or 45 seconds before it turns green. You still have to stop at a red light. For everything downstream, they depended on both you being at that light and that light being green. If the light is red, it erases any gains.
Interruptible? No. When you stop at a light, you pick up where you stopped. But, you have to accelerate, wait for cars ahead of you.
If you didn’t have to stop, you would be going through the intersection at the speed limit. Now, you have to catch up to the speed you were going.
Measurable? Yes. Each set of blocks has a clearly observable starting point and stopping point along with the time to cover the distance.
What’s so unique to Traffic Lights that causes this?
It’s relatively simple: you have to wait for a red light to turn green, and the stop light doesn’t care if you’re stopped.
You only get somewhere faster when you skip a red light you normally would have hit.
This shows up everywhere in work. We call these interruptions (though, not every interruption is a traffic light). If you go over all the times where something took longer, a good proportion will be “because I was interrupted”. And even if we don’t have interruptions for that task, it’s often part of a broader task that was interrupted a lot.
To better understand these 4 questions, I’ll go through examples that we are familiar with to demonstrate where the conditions are not met, and how we might seduce ourselves in optimizing something that will have no impact.
Examples of how Traffic Lights show up
Planting a Garden - Not Isolated
Weekend gardening is a great hobby, and every plant has certain seasons for planting. While the time to plant is far more detailed now, it’s still dependent on the weather of that year. That means you inherently have a range of when you have to start the task or finish the task by.
We might think of this as isolated, I have to plant in order to have flowers. And gardening tasks can’t be swapped in until that is done.
But I have many more things I need to do in my life that I will do on a weekend. If it is unseasonably cold or raining, planting can wait until it’s warmer. There are things I can do inside the house.
When we scale this to a green house or nursery, Isolation begins to go away. You have to have a certain inventory by a certain time. Farmers will work punishing hours because a harvest has a narrow window to be completed in and everything depends on finishing the harvest first.
Along the remaining definitions:
Cumulative: Yes, and no. There are many gardening tasks that require you to plant first and in the near term, like soil conditioning. But, future gardening maintenance, like fall pruning, don’t rely on planting the first week of the season or the last week. It takes place in the fall and there are variables that influence it more than when you plant in spring.
Interruptible: Yes. You don’t have to go back to what you’ve already planted. Those are done. The time it takes to put things away and get things out is usually pretty low for small gardens.
Measurable: Yes. You have either planted, or not. It is easy to create a to-do list and check off the progress you made.
Traveling to an event - Not Cumulative
We try to be polite when going to an event and get there on time. Or, more commonly, a little early “just in case”. We try to have that small cushion for last minute things.
The more extreme example of this is “hurry up and wait”. You can push to get something done early, but then you’re just stuck waiting.
If we’re on time, versus 10 minutes early, it doesn’t matter. That event is going to happen when it is scheduled to happen. This is the main impact of a traffic light. It doesn’t matter when you got to that light, it only matters that it was red. If we look at the task of traveling to the event, so long as we’re there by the time it starts, it doesn’t matter if we saved time in getting there.
Processes that undermine cumulative improvements often show up when we look at the broader context of what we are doing. For instance, traveling to an event is a part of Going to an event. This broader timeline, which the traveling is embedded in, has a fixed ending. And if we don’t travel, then we are not going to an event.
A lot of time savings disappears into these sorts of voids. The starting point of a meeting is fixed in time, and there’s slack in the short time before the meeting beings where you have to pause a task and can’t substitute anything else in place because there’s too little time.
Note: Trying to fix this sort of obstacle, or removing it, is often impossible. If there is a broader task, that forces certain constraints on time, it’s probably immovable for a reason.
Instead, it’s better to look at that time cushion we usually build into a calendared event.
If you are planning an AI project, where the results don’t have to be instantaneous or interactive, like in a chat. Then whatever it is that the AI is doing, it does while the meeting occurs. This targets the Isolation of waiting around where you can’t start anything.
But this has to be simple and not require input or interactivity. If you have to start a process by chatting with AI, giving it directions, and verifying plans, it won’t fit in.
Instead, if it’s a Word plugin that looks over something you wrote, or looks for related documents, this is a background task that can help you get started quicker on a task after the meeting is over. Forming AI around modeling business processes, and being specific and deliberate, is a good use of it.
Writing a report - Not Interruptible
Working in an office often involves a lot of writing. Writing can be a report, summarizing meetings, writing a code module, or debugging code. These tasks require analysis and/or synthesis, it costs a lot of time to resume after you’ve paused it.
If you are summarizing meetings and you stop half way through, you have to go back through what you wrote to make sure that what you write next is accurate and not redundant. If you’re debugging code, you have to remember what you’ve tried, where your thought process was, and get back into a groove.
Isolated? Mostly no. You can see this when a task is waiting on someone to find information, or send you an email. If you have 3 bug fixes, and they’re all the same priority, you can chose to do another one.
Cumulative? Sometimes yes, especially if you’re a project manager. It’s a major part of the job and it’s critical to communication and coordination. A late report around budgeting time, or quarterly review of project progress, can have major impacts. Not being prepared for the next meeting will cause delays. In a sense, if you’re a PM, you’re the traffic cop for when the lights go down.
Interruptible? No. You might have a report template, but what goes into each field will span multiple meeting notes, and then you distill them into what happened and action steps. Context switching is rough because it takes time to get back into the mental state necessary for completing the task.
Measurable? Yes. Generally, bugs have clear beginnings and ending (when it meets acceptance criteria). If you’re summarizing project meetings for a weekly update, you might have a template where it’s filled out or not.
Notes for optimizing: You can’t really change the interruptibility aspect because it’s inherent to the task. It demands focus and thinking. If accuracy is required, then using AI summaries can help start it faster, or speed up the resumption. But, that comes with the trade off of needing to double check the AI’s work.
Accuracy and reliability determines a lot of the interruptibility of a task. Meeting notes are a good example of optimization. They are general in nature and act as a way to jog your memory. But if you are making budget decisions from those summaries, without checking, then that task can’t be interrupted in order to make sure it’s accurate.
Square Footage vs Rooms - Bad Measurement
We’ve arrived at the hardest part, and a cornerstone of science and data science: measuring. Measuring what matters is often not clear. Even if you’re a data scientist and are familiar with a lot of different metrics and how to calculate them, it doesn’t solve the actual problem of measurement.
We often see time savings in minutes, which then accumulate into hours over a year. In many instances, this is because the time savings don’t accumulate because of stop lights.
But there are deeper reasons why it might never add up. This is because the measurement is too granular and acting as a proxy for what you really want to measure.
Think of renting an apartment or buying a house. Square footage is very important. 1000 square feet vs 1200 is a huge difference. It’s about 1 to 2 new rooms. But, it’s a proxy measurement of the utility we’ll get from living there. If you have 10 10x10 rooms, adding 2 feet per room isn’t much of an improvement. It will feel a little bigger, but it doesn’t translate to much.
But, going from 10 rooms to 12 rooms means an extra hobby room, or an office, or game room. How that extra 20 square feet gets added up and used will matter more than just the sum of the additional square feet.
In this scenario, simply comparing the sum of square feet between the two homes is too granular to be fully meaningful. Number of rooms, how much of that square footage is for bathrooms, and other variables often mean much more than that raw number.
This is because the value of a home depends on the functionality of that home for your needs and wants. And, we often use many different metrics when evaluating where to live.
When tallying up an optimization, especially in minutes, we have a measurement. It can look like an improvement. But, it’s being used as a proxy for another measurement: number of tasks completed.
Back to Toast and Assembly Lines
When we encounter claims like the one behind the avocado toast claim, we get irritated and frustrated. It’s reasonable because we want to say back “but there are so many other things involved!” In many ways, the fallacy is really that simple. Cherry picking small, unconnected, things and optimizing them ignores the bigger, broader picture that those things exist in.
When things are on an assembly line, it’s easy to see that the system is made of many small, and importantly, interconnected parts.
When we aren’t on an assembly line and working with human processes, we try to optimize for as many people as possible. This leads to finding the shared problems facing many people. More people share the problem, the more an improvement is compounded. However, this often makes a solution harder and less beneficial.
I think we’re drawn to this because it feels like we’ve found an interconnected part because it is across many different people. But it’s horizontal, spread out, rather than vertical, and in-line with other tasks. Different traffic lights exist for different people, and the gains for some people will get gobbled up by these unique barriers in each person’s work.
Iterating on the solution also struggles because the general solution is now getting tortured into all the edge cases. The complexity of the solution just inherited the complexity that it is was supposed to solve. Moreover, we might see an improvement in the average, but an improved average doesn’t mean that it’s better for everyone. A solution can make things worse for a few people. Sometimes, it can make a process far worse for a few people.
That’s directly impacting retention, employee satisfaction, dismay over new initiatives that promise but don’t deliver. It feels like you’re being treated like you’re on an assembly line because, in many ways, the improvements are assuming the assembly line conditions are met for the benefit.
I’m currently working on a series that will try to address this approach when creating your first data centric project. It will use AI tools, but nothing fancy. Instead of focusing on a common problem, it leverages common data. The unique capabilities of AI, when done right, actually allows for projects to let a person tailor a general solution to their workflow. But that is not a given and requires thoughtful task selection, identification, measurement, and making sure that you don’t commit an Avocado Toast fallacy.
AI doesn’t remove this fallacy, and it very likely won’t catch it. AI just gives us a few new tools and a few new tasks that can be improved. But it is not a solution in and of itself. Many tasks won’t benefit at all from it at all when the task isn’t thoughtfully selected.
Going Forward With This Knowledge
Measurement is fundamental to data literacy. Numbers saturate our lives more than ever. We’re often told to ask “how was it measured?” and “what assumptions did they make?” But that’s of little use unless you understand the measurement itself. Measurement is hard. In science, data, and engineering, what measurement should be used, and how that measurement is interpreted, has decades of study, debate, and passionate argument. And even then, there’s a large amount of subjectivity in choosing a measurement and why.
The source of the subjectivity comes up because measurements are not inherently right or wrong. What measurement is the correct measurement, for the specific circumstances you are measuring, is the source of a lot of error and bad decisions later on. Sadly, what measurement is correct and should be used is primarily learned through experience and exposure to similar problems. We have to read what worked, and very importantly, what didn’t work. People don’t share their failures, so we’re presented with a lot of success for a method or solution. But, those improvements don’t show up in our day to day observations.
What to do when starting off?
Don’t choose just a single metric. Choose several. If you are measuring things in minutes, look at what surrounds the task that can be measured in half hours or hours, or days.
Focus first on tasks where the outcome is what other people consume. If it doesn’t matter if you do it an additional 11th time instead of your current 10 times, then don’t optimize that for time. Optimize that to reduce annoyances and frustration.
If doing it more doesn’t matter, then saving time on it is not productivity that’s being measured. It’s a proxy for productivity by saying “other tasks, where we want to do more of them in the same amount of time, will benefit from having more time.”
Identify your Traffic Lights early on and look closely at any external processes that are breaking one of the 4 conditions: Isolation, Cumulative, Interruptibility, and Measurability. Knowing what your external traffic lights are will figuratively help you find a different path. That path might be more easily optimized and your detour is now a shortcut.
The example of this is surrendering to the immovability of meetings. Instead of looking at tasks leading up to the meeting, look at the tasks immediately following the meeting. If you have to interrupt a task for a meeting, how can you make it easier to resume it? If you need to find related emails or hunt through sharepoint for your work, then AI can be a background service that whirrs away to find the documents while you’re in a meeting. Or, it lets you enter a few sentences within a meeting, and have those documents when you get out.
The first lets you continue an activity while in a meeting. The second lets you start an activity while in a meeting.
Wrapping Up
Measuring things and calculating things to find improvements is not a new thing. Some of the earliest uses and developments of math in history is not Greek proofs, it’s in accounting and taxes. Measurement has been a domain of scientific and mathematical study for a very long time. There’s even a field for it: Metrology.
What’s changed is that we’re now being asked to measure things ourselves, and often without much training or guidance. Sometimes, without even having options between metrics. We’re being asked to do something that has traditionally been a speciality.
Sadly, there is no general formula for what will succeed, or how to measure it. Each circumstance is different and traffic lights differ person to person. As a data scientist, I’ve had to read a lot over the years on just different measurements, their formulas, and when they can be used. Even knowing those doesn’t mean I’m able to immediately select one and apply it without knowing more about the circumstances.
While knowing this fallacy won’t tell you the right thing to optimize, or how to measure it, hopefully it will help you avoid choosing a project or optimization that only looks good on paper.
My advice is to start at what is immoveable, like meetings and work from there.
Think of what buttons you might want to click to help you pick up your interrupted work quicker. A “conceptual save point”. Summaries fit into this.
A “find related projects” that can take time going through Sharepoint to see if others have worked on something similar. This can be run when starting something, and in the middle so that there’s more context for what might be relevant.
If there is internet search or deep research, find and summarize what you might be missing, like alternative metrics.
These AI tasks tend to take a while, and longer run times can drastically improve results. Their output can be a report that you can read through or reference, not a chat interaction. Using something you are currently working on as the input, and the process the AI is performing is mainly mechanical and drudging through papers, makes it easier to create a button or kick off the process with the directions pre-defined.
As always, try. The essence of experimentation is trying. Try the most straightforward, non thinking, approach first, even when you are sure it will fail. Whether it works or fails, write down what you liked, what you didn’t, and what you used. Then, add something, remove something, or change something. Just 1 thing. And repeat. There’s no substitute, and no shortcut, to gaining experience.
