depending on when you're listening to this episode in the last few weeks charlie munger passed away at the age of 99 and while some of the things that munger did while he was alive would certainly be considered controversial and maybe many people listening to this episode right now have strong feelings about munger's life and in his approach to business i want to focus in on a concept that charlie munger talked about about 28 years ago the concept is the lollapalooza effect until i started researching a little bit about the lollapalooza effect i didn't realize that munger actually coined that term the lollapalooza in short the lollapalooza effect is the combined reinforcement you could call this a multiplicative effect and the idea is that any two forces may combine and especially for lollapalooza effects it's usually more than two forces combining to reinforce each other and so in in today's episode i want to look at two examples of this one is a positive example and one is a negative example both in the frame of planning planning for a project for example all right we're going to talk about lollapalooza that would cause a project planning process to go very late and then we'll talk about a project planning process that ends up going very well both as a result of these combined effects and then we're going to talk a little bit about how to uh organize your work and your team to prefer the latter to try to move more towards Lollapalooza effect and avoid the negative. As it turns out, and Munger would probably say this himself, most of the work and most of the benefit is going to come from just the avoiding the negative part. So let's talk about that negative Lollapalooza effect on a planning process. Let's imagine that you are planning a software project. Maybe you actually are doing this right now. Most people are planning for the beginning of the next calendar year or your next fiscal year. You're trying to get projects aligned and get things rolling on those new initiatives that are coming down in your organization or whatever it is, whatever that frame is that you're planning in. A lot of people are undertaking that at the end of a quarter like this and in December at the end of the year, rolling over to the next year. When we are planning, we know from the work that Danny Kahneman has done, and that's been kind of reinforced and validated by follow-up work, that there's a planning fallacy. This planning fallacy is that we chronically underestimate the time required to complete software development and pretty much any other task. We have optimism based on our past experiences, and we tend to remember the good parts. We tend to remember our past experiences, and we tend to remember the good parts. We tend to remember our past experiences, and we tend to remember our past experiences, and we tend to remember our past experiences, in a positive light. We imagine that we are capable of doing things more quickly than we can do them. Planning fallacy also brings in the idea that we underestimate the difficulties or the interruptions, and we overestimate our capacity and capabilities. We start with a little bit of planning fallacy. It's set out originally in our project, not understanding the full scope of it maybe. As a result of both of those things, we start to establish a timeline for a project that starts out with error. Then we begin to talk about this timeline, and with our team, we're kind of seeking harmony with each other. Let's say an engineering manager or a senior engineer says, I think we can do this in three months. Now we want to seek harmony, especially when they've signed off on the evolution of evolution, and they may have signed off on evolution, and they may have signed off on evolution, and they may have signed off on evolution, and they may have signed off on evolution, and they may have signed off on evolution, and they may have signed off on evolution, one here, right? We have the natural result of this is actually unchallenged acceptance of these optimistic timelines. This is groupthink. We begin to converge on a date that makes sense to everyone. And when we say makes sense to everyone, really what we mean, there's a substitution that's happening there. It doesn't actually make sense to everyone. It just feels the best. It feels the best to not quibble with the date that, let's say, like I said before, a senior engineer might put out on the table. This is compounded with our planning fallacy. And then it compounds again with something that we talked about in a recent episode, the anchoring effect. The anchoring effect, these initial time estimates that we begin our conversation with, that three-month time estimate, it creates an anchor point. That means that any time somebody might say, well, what if it takes us four or five months? Maybe if that had been said before as the first estimate, then it would be accepted. But now that it's being compared, there's a contrast effect happening with that original anchor. And so any new information that comes in is going to be compared against that anchoring effect. You've probably all experienced this when you're having to move timelines out, when inevitably you realize the project is going to be a little bit longer. And so you're going to have to move timelines out is not going to deliver on time. And then somebody asks you, well, what happened to the original timeline? What happened to three months? This is an expression that is derived from the anchoring effect. But of course, the one that many engineers are heavily familiar with is the sunk cost fallacy. As you begin to progress and you begin to fall behind, the team continues to invest more resources. You continue to kind of double down on the plan, believing that abandoning the plan or changing the project plan, doing something different to hit that timeline, that actually would waste the resources that you already spent. This is a fallacy. And the reason it's a fallacy is because those resources are spent whether you abandon the project or not. So that is a sunk cost. That cost is not going to be justified by further poor decisions. Now, it should be recognized that this is distinct from something like finishing that last test in the last class that you had to take to get a degree. The marginal utility of that last test, even if the last test on its own is not all that valuable, the marginal utility is significant because completion is more important than the test itself. So that's a little bit of a caveat that I often hear people talk about whenever I discuss sunk cost fallacy. And it often trips people up and is the source of a lot of confusion or disagreement within a company. You may have a leader who says, well, we just have that last 3% to finish this feature and we want to test it. Even if it doesn't seem like it's valuable, we want to test it. That last 3% is necessary to be able to test that thing. And then the engineers very often come back with, well, we're not even sure if the feature is valuable. So it feels like sunk cost fallacy. In this case, the sunk cost fallacy with relation to planning is about pursuing a plan that you know is not going to deliver on time. And because you continue investing in that plan and because you've already invested in that plan, it feels difficult to change that plan because you've already put time and effort towards it. An example of this might be along the path, maybe early on in the project, you realize that during the decision making, you're going to have to do a lot of discovery portion of the project. You had decided on a technical path. It turns out it's going to be very expensive. You may not have gotten very far along in that technical implementation, but you could abandon it for a simpler solution. The abandonment in this case feels difficult because it feels like you're throwing away the effort that went into the more complex solution, even though the more complex solution doesn't deliver any more absolute value than the simple solution. So we did a little bit of a deep dive on sunk cost fallacy there, but this is how you would end up with a Lollapalooza, negative Lollapalooza effect when it comes to planning. All of these things are kind of self-reinforcing and they show up to support each other in a negative way through that planning process. You start out with a bad date. That bad date gets socialized. It becomes a little bit taboo to mention a date other than that date. The anchoring effect takes hold, and you're going to have to do a lot of work to get that plan going. So you're going to have to contrast that you present to that original date becomes an outlier. And so to maintain harmony, we all continue believing incorrectly that that original date makes the most sense, that we should still plan and invest towards our original ideas, towards our original discovery, and try to hit the date as best as we can. And this ends in catastrophe very often for engineering teams. But what if we looked at it from the perspective of a Lollapalooza project? What are some reinforcing models or effects that we could take advantage of? And look at the positive reinforcement version of this story, maybe a parallel universe version of this story. We'll do exactly that right after we talk about today's sponsor. Once again, I'm excited about today's sponsor Miro because I legitimately am using it on a almost daily basis. I'm going to be using it on a daily basis. I'm going to be using it on a daily basis. I'm going to be using it on a daily basis. I'm going to be using it on a daily basis. basis, certainly on a weekly basis in my everyday job. And it is truly one of the most transformational tools I've used as an engineering leader. If you're looking to level up your game as an engineer, by the way, if you're trying to move from that kind of mid-level associate level engineer to a senior level engineer or even a principal, your staff plus, that kind of thing, then tools like Miro are going to become a part of your toolkit. You absolutely will end up shifting what your tool set is, what your typical common day-to-day tool set is. That doesn't mean you're going to get out of code, but tools like Miro are not trying to replace what you are currently using in your engineering workflow. They augment it. Miro, by the way, integrates with a ton of different things that you probably already use. So Miro is not trying to replace, for example, your JIRA board. It's going to integrate with your JIRA board. So what exactly can Miro do? I can't cover all of that in today's episode. The thing is, Miro is going to be a part of your engineering workflow. I've most effectively used Miro for are collaborating on really complex topics, very often bringing out new information in really quick sessions where there's a lot of collaborative engagement from the team, which brings me to another very important point. If you are an engineering leader, you don't have to worry about training on Miro necessarily. Miro is incredibly approachable, very well organized from a UX standpoint. So people can jump in and start using Miro. If they've ever used any other basic drag and drop interface, the Miro is approachable right away. A couple of simple features that make my life in Miro so much easier. For example, when I'm running a retro, we have engineers that put post-it notes on the board and we organize those post-it notes. We can do voting right there in Miro. We start a voting session. You select the number of objects that you want to vote against. And by the way, it doesn't have to be just stickies. It can be pretty much anything. You can do voting right there in Miro. You can do voting right there in Miro. You can vote on those different objects. It's a timed voting session. Everybody gets the same amount of time. You can set the number of votes. It's a very cool, simple feature that Miro has introduced. And it's one of a hundred of those. But of course, it doesn't end at simple features that make your life easier like voting. There's also these much more powerful things like AI categorization of sentiment within your board. Incredible tools that allow you to get a better handle on all of that complexity in a shared environment. You can get three free boards today. Three free boards. Head over to Miro.com slash podcast. That's M-I-R-O dot com slash podcast. Thanks again to Miro for sponsoring today's episode of Defund Your Team. So how do we change the script? How do we go from that negative Lollapalooza flywheel? Negative compounding, biases, etc. How do we flip that and take advantage of the Lollapalooza effect? These reinforcements actually doing good for us. Let's say you approach things a little bit differently. And instead of the groupthink being a problem, it becomes a helpful solution, specifically using wisdom of crowds. This is a statistical phenomenon where if you have a bunch of independent events, you can do a lot of different things. You can do a lot of different evaluations that are combined together and averaged. They tend to be very close to a correct prediction. This is a model that is fairly well researched and turns out to be most of the time true that if you have these independent things. So again, recognizing there's a slight difference there. We're kind of getting ahead of ourselves with what we do to lead towards these positive Lollapaloozas. But the fact that you have a group is not necessarily on its own a bad thing. You could take the advantages of having a group, in this case using wisdom of the crowds. And in these, you'll notice that there's a focal point or some commonality between the negative Lollapalooza effect and the positive Lollapalooza effect. In this case, it's the fact that you are working in a group. So using that group dynamic as a focal point for your leverage. We go from anchoring, right, using or falling prey to, an anchoring bias. We move from that to taking advantage of the contrast effect. In the first example, we use anchors and we fall prey to the contrast effect. Instead, we use anchors as reference points. We start with dates as reference points. And the language here is very important that you're not using that as an estimate. You're using it as a guess, right, as an initial guess. How close or how far off are, are we? What if we said that it was four months? What if we said that it was five months? Which of these sounds best? Now, this contrast effect takes advantage of another factor in human psychology. That is that we're much better at estimating things relative to each other than without any context, right? If we were estimating something on its own, it's much harder. We can say something, you know, one task in, hopefully as an engineer, you can see and connect to this. You can look at, one task in the backlog, look at another task in the backlog, and pretty quickly you can say which one of those is harder or easier. You may not be able to say exactly how much time or how much effort goes into one or the other, but you can compare this one is harder than that one. And by doing this, you're taking advantage of the contrast effect. You see these focal points. In this case, the contrast effect is the focal point for leverage. If we're going from planning fallacy, where are we going to go to? What is the focal point there? We're going to utilize this process of forecasting, right? We're going to use forecasting as the focal point because we need to forecast in order to do that initial planning or the original kind of timeline guessing, but we're going to do it more than once. We're going to do it on an ongoing basis. This is a continuous planning. Instead of saying planning fallacy sets up an anchor, it sets up this long-term target that we're trying to hit. We instead treat that as a continuous planning. We're going to use this process of forecasting to create an ongoing forecast that gets re-evaluated on an ongoing basis. Again, that focal point is the forecasting. Rather than thinking about it as a planning process that you do once and you're done, the focal point, this shift here, is thinking about planning as a continuous process. Now, finally, with sunk cost fallacy, we're going to use this process of forecasting to create an ongoing forecast that gets re-evaluated on an ongoing basis. The focal point here is evaluating investment. That's what you're doing when you look at the sunk cost fallacy. We're going to lose all of this that we've invested in the past, right? So, there's some positive in that evaluation. You're not doing it without thinking. You're doing it by thinking about the amount that seems to be lost. The fallacy there is that there's nothing you can do about it. That's the part that we miss. So, if we switch on the If we say, well, let's do the same evaluation, but let's do it against investments that we can do something about. That's a future-oriented evaluation. What is the potential value of our future investments? Instead of looking at the lost value, the kind of sealed door behind you and saying, well, I wish that we hadn't done that. Or we have to continue investing because we already invested. Instead of making that fallacy claim, let's instead focus on what we can do something about. Let's evaluate the potential of these investments that we're getting ready to make. Now, if we start evaluating the potential, we might find out that, hey, you know what? Actually, if we do go this direction, the potential value of delivering this solution turns out to be worth it. Or the potential value of delivering half of this solution is equal to the potential. The potential value of delivering all of it. Well, let's just deliver half of it. Let's deliver a smaller scope. By using that focal point, you may, for example, shorten the timeline of your investments. Now, the interesting thing is that all of these can sort of happen at the same time. You could have a negative Lollapalooza that's sort of fighting against the positive Lollapalooza. There's no way to say that all of the effects that are happening at any given point in time. Are going to be in your favor. Because the truth is, all of these effects have no concept of whether they're in your favor or not. They are agnostic to the outcomes that you care about, that you desire. And so that's why it makes sense to evaluate and use them to your advantage. Because there's nothing necessarily different about a positive or a negative effect as far as the world is concerned. As far as systems are concerned. Align those effects to be in your favor. By using those focal points that we talked about for leverage. And again, this is just a model. This is just an example. We're not talking about the only Lollapaloozas that exist in your planning. You have to do some kind of evaluation on your own. What kinds of effects might create a negative Lollapalooza? And how can we find the focal points, the commonalities to switch on those? Thanks so much for listening to today's episode of Developer Tea. And of course, a huge thank you to today's sponsor. Once again. Miro.com. That's M-I-R-O dot com slash podcast. You can get your first three boards for free. M-I-R-O dot com slash podcast. Every year around this time, I am reminded how grateful I am for the audience who listen to this show. I sincerely appreciate many of you who have been listening for years and years. And those of you who are just brand new newcomers. I sincerely appreciate you taking the time to invest in yourself. And of course, allow for this show to be a part of your life. It's a part of that investment. It means the world to me. So thank you so much. If you would like to give back to the show in any way. If you think it's had a positive impact on you. Even in the slightest. I'd like for you to do just a simple back of the napkin math. What level of impact has it had? If it's had five minutes of positive impact. If you were to quantify it that way. Are you two or three percent better in your career as a result of listening to this show? I hope that's the case. I hope you're finding. Those positive impacts. They are able to quantify them in that way. And all I really ask for in return is that you share this show. So that others can have that same kind of impact. There's plenty to share here. And then a review on iTunes. This is the biggest way to help this show continue to succeed. Not just iTunes, any podcasting platform or podcasting app that you use. I try to read every single one of these that comes through on the major platforms. And. If I know about them. The minor ones. I go and read those as well. I drew. I do truly take this as constructive criticism. And I try to listen to the feedback that people provide in those. So if you have feedback for the show, please go and leave a review and share your experience. If this has had a positive impact on you, it helps other people make the decision to invest their own time in listening to this podcast. Thanks so much for listening. And until next time, enjoy your tea.