Today Marks 9 Years of Developer Tea. Thank you all for your support, and your friendship. I wish you all well on your journey, and may you find clarity, perspective, and purpose. (Don't worry, we aren't going anywhere!)

What characterizes good plans from bad ones? And how can you make your plans better on average? In this episode we discuss how to better organize your intentions and processes to yield better plans.

The "lollapalooza" effect (coined by Charlie Munger) occurs when multiple other effects have a compounded outcome that tends to create an extreme situation. In this episode, we discuss lollapalooza effects and how you might fall victim to them, and more importantly, how you can use them to your advantage.

When you are newly joining a team, you have a huge opportunity to do something that no one on the team has: to find your "weathervane." The pressure pushing against you to adopt the beliefs of the team you are joining. What you do with it is one huge way a team can improve, or otherwise, stay the same.

Most people believe good things will happen by default. Not to be the bearer of bad news, but there's a downside to this endless optimism. You cannot will good things to happen, and when you don't prepare for adverse events, you won't be ready when they inevitably occur.

Your team's process for managing a backlog is probably growing stale because you are running on habit rather than procedure. Break out of procedure and remind yourself why you have a process to begin with: orient yourself to the outcomes!

What is it about our present situation that changes our perspective? In today's episode we talk about the availability bias and why our present reality looms so large in our decisionmaking.

What do you expect of yourself? Are you spending your time in ways that align with those expectations? In this episode, I provide you a simple framework as a starting lens for getting a better idea of how you are spending your time in relation to who cares the most about those investments. You'll walk away with a new lens on how to evaluate your most precious resource: time.

Almost every conversation you have will start with a question. Have you stopped to listen closely? Questions are extremely meaningful and deeply human. Paying close attention to questions is a skill that will put you head and shoulders above the average engineer or manager.

How often does reality match your expectations exactly? Sure, you may guess in the ball park, but usually there are errors in our expectations. In today's episode, I talk about a simple shift in thinking that will help improve your expectations for your work.

In this episode we continue a little mini-series called "Backlog psychology." How do you get better at anything? (Hopefully you said "practice" almost instinctively.) What does good practice look like? Your team has an opportunity to practice every meeting and every day. But if your days look different from one to the next, how will you ever have the opportunity to actually do that practice?

In this episode we continue the mini-series "Backlog psychology." Would you rather have $5 now or $50 next week? The answer to this question, though it seems logically obvious which is better, does not always produce the same response. The required incentive to convince someone to wait tends to follow an exponential curve upward. This is not just true with money, but for any benefit and incentive: monetary, social, emotional, physical, etc. What does this mean for our backlogs? What about our daily habits?

In this episode we kick off a little mini-series called "Backlog psychology." You've heard you should "limit your work in progress" - why? What makes more work in progress more difficult to handle? Cognitive load isn't just about multi-tasking in the moment - it's also about limiting your open tasks.

Your retros may feel like deadends where complaints go to die. If you're running retros and treating it only as an avenue for emotional support rather than continuous improvement, today's episode is for you. Retros are for improving iteratively over time. That can only happen if your outcomes are aligned to that iterative mindset. Two simple adjustments can help drive that improvement.

Count the cost of learning. When you choose a path towards a goal, it's absolutely critical to optimize for the cost of learning. Often, with software, it is easier to learn by a series of smaller steps, even if they start out as random, rather than take on the major risk of a large step possibly going the wrong direction. This isn't always true; sometimes, the cost of learning is *greater* with small steps. Determining which is true in your situation can make or break your plans.

Decisions are made in many ways, but one important type of decisionmaking tool is the "rule." This is something you follow without any cognitive processing. But, we eventually develop rules as a part of habit-building. These are "implicit" rules - they aren't necessarily something you have set as a rule, but they are followed as if they were. These are worth interrogating, and perhaps replacing with more explicit rules.

Are you stuck trying to prioritize your long list of things you need to do? Maybe you're trying to establish a habitual routine or areas of investment in your schedule, budget, or decisionmaking. Figure out what you need to avoid first. This creates the opportunities you need to say yes.

Are you measuring the wrong thing for your short term game? If so, you probably continuously change directions and are never sure if anything you do is working. It's time to rethink your scoreboard.

Your career doesn't have to take off without your approval. Slow down, and make sure you actually have goals you are setting. Control your own destiny by aligning your plan to your actual goal, or vice versa.

Accountability can be complex. When something goes wrong, fingers start flying: *someone* needs to be held responsible. But true accountability starts before anything goes wrong. In this episode, we discuss the Accountability Triangle, a mental model for ensuring that your accountability structures are valid and actually usable.