What constitutes a bad plan? What is a bad plan? This is actually a pretty difficult question to answer because a plan is about decision making and it's about decision making based on some kind of context or foreknowledge. And our evaluation of plans is very difficult to perform because by the time we can evaluate the plan, we tend to evaluate it based on outcomes rather than on the quality of the plan itself. And so a bad plan may have good outcomes. And a good plan may have bad outcomes. Good and bad in all of these cases is dependent on your intentions, what you want to make true in the universe, or more practically, what you're trying to accomplish with that piece of code you're writing. Or maybe the middle ground between those two extremes is what are you trying to do as a business, as a team? What are you trying to do with your product? One of the hallmarks of a bad plan is one that doesn't actually answer that question. What are you trying to do? And in fact, because of this, you see most of the conflict between teams, for example, at a given company who have competing projects because they haven't answered collectively, what are you trying to do? And even though... Even though they haven't answered that question explicitly, they do answer that question implicitly. Sometimes the question is answered by individuals. Sometimes the question is answered at the team level or a couple of people on the team may get together and have an answer to that question. What are we trying to do? Everyone has an answer to that question. But if you don't ask the question explicitly... Then the answers can vary. And when you have variation of motivation that is uncoordinated... Okay, that's a very important combination, right? Variation of motivation that is uncoordinated. Then two different motivations may be competing. The classic example of this is two teams that have different roadmaps. Each team's motivation is to accomplish their roadmap in order to, let's say, get a raise or get a positive. Or get a positive review. Or avoid uncomfortable situations. There is some kind of existential threat, ostensibly, with not delivering on your roadmap. And so if you have two teams who have roadmaps that end up colliding... Especially... This tends to happen when the roadmaps are defined in an advanced position, like three months in advance, let's say. And by the time you get to month two or three, you realize that something has changed that causes there to be competition. And so you're going to have to start leading motivations between the two roadmaps. And instead of alignment on a question like, what are we trying to do? If both teams continue heads down with their existing uncoordinated, varied motivations, then they will pull apart from each other because of the lack of coordination. And so a bad plan tends to be one where you have two teams that are in a bad position. And so you're going to have to start leading motivations between the two roadmaps. The question of what are you trying to do is implied or otherwise left to the individuals. I want to address one thing I mentioned there, the uncoordinated qualifier here. It is absolutely normal for everyone on a team to have different motivations. There's nothing wrong. And in fact, there's everything right with individuals on your team asking, what's in this for me? If you don't have varied motivations, you're going to have to start leading motivations. Then you still do. You're just hiding them. Individuals on your team or groups of individuals will have their own motivations, whether you coordinate them or not. And the uncoordinated part of that is the problem, not the varied part. The simplest example of varied motivations that are coordinated is a bunch of people taking public transport. We all have different places to be. We all have different reasons. We all have different reasons to go to those places, but we travel a common path. We have a coordinated effort to accomplish our varied motivations. So how do we better create good plans? How can we set ourselves up for more success on our plans? We're going to talk about that right after we talk about today's sponsor, Miro. We're nearing the end of the year, and that means most people are doing some kind of planning, whether you're doing individual planning or team planning. And today's sponsor, Miro, can help you with all of the above. And one of the things I want to focus on when we're talking about Miro today is the illusion of perfect memory. The short version of this is that as you leave and come back to an idea, you are, in many ways, a different person. Various aspects of your memory have changed. Various aspects of your thinking process have changed. You've grown. Maybe you've learned something more tangibly, or maybe something has connected more intangibly that you can't quite explain. The great thing about Miro is that it helps capture all of these different inputs from you as if you were a crowd of people. One of the things I love about Miro is just how flexible it can be. If I wanted to, for example, bring a mental model like the six thinking hats from Debono into my thinking process for myself or for my team, I can do exactly that. Now, if Miro was just a blank canvas, then it would still be incredibly useful. But Miro goes well beyond that with the Miro Marketplace, which allows you to connect over a hundred of your favorite collaboration tools, design tools like Sketch or Figma. But there's also extensions to Miro. One that I just found is the Team Topologies extension. Which provides you with some easy to use shapes that align with the Team Topologies kind of encoded design language. If you've read that book, if you haven't, I highly recommend it by the way. Another very cool option, let's say you're working in architecture and you're building with AWS. Well, there's an AWS cost calculator. This lays right on top of your architectural diagram. So you can move boxes around and see how that impacts your total cost per year on AWS. There are so many opportunities, there are so many opportunities here that go beyond just a whiteboard, a digital whiteboard or something like that. Go and check it out. Head over to miro.com slash podcast. That's M-I-R-O dot com slash podcast. And you'll get your first three boards for free. That's miro.com slash podcast. Thanks again to Miro for sponsoring today's episode of Developer Team. . So if a core reason that we end up doing this, is that we're not doing it for the right reasons, or that we're not doing it for the right reasons, or that we may end up with bad plans, is not answering, what is your reason? Why are you doing this? What are you trying to do? And the expression of that, or the symptom of that, is a variety of uncoordinated motivations amongst those who are executing on the plan, then we should be able to improve our plans by asking, what are you doing this for? This might be a minor improvement on plans, if you were just to say, say, what do you want to do? And then wrap a plan around that. But a more sustainable approach is to rethink where your plans come from. Instead of dealing with plans on a one-off basis where you're just kind of functionally asking the question, what do you want to do now? Let's think about a higher order concept and a more abstract concept. What can we do to have a plan maker? What is a good machine or engine for generating good plans? Now, the interesting thing about machines or engines is that they can be expressed or described in a stateless manner. In other words, the plan is stateful. You go from point A to point B, or you're trying to change something from one state to another. An engine is an expression that can adapt. The engine can affect external state. It can carry you where you want to go. If you're thinking about this through the metaphor of a car or any kind of vehicle, the engine can carry you where you want to go, but the engine does not have any concept of where you want to go. The important insight here is that your engine supports whatever plan you choose. So how do you get to where you're going? Well, you have to have some mechanism of steering. You have to have some mechanism of steering. You need to know where do you want to head and steer in that direction. And then the engine helps carry you that direction. So the metaphor is separating these three concepts of steering, the engine, which generates that motion, and then finally the actual intention, the outcome that you're trying to get to. With this framework, we end up seeing that a lot of plans end up being stiff. We end up seeing that a lot of plans end up being stiff. We end up seeing that a lot of plans end up being stiff. Or inflexible. They focus on the actual position rather than the outcome, and they don't consider detours to that position. So let's talk about what is the steering mechanism, what is the engine mechanism. The steering mechanism in this framework is your values, your principles. These are what tell you in a stateless manner, what you want to do. And so what you want to do is you want to do something that you want to do. This can be at the personal level. It can be at the company level. It can even be what you care about in a given context. It doesn't even have to be your values as a general rule. It could be your values at work. And it's useful to define and understand these things at various levels as well. It may be at your team level. It might be a subset of values or an interpretation of the company's values for your team. And this is a set of values that you want to be able to use. And you want to be able to use them in a way that's appropriate for your team. So let's talk about the steering mechanism because you can test your intention. You can test your outcomes from your plans against these values. Are we following our values? Are we headed in the right direction? How do you know what's right by looking at those values and principles? Once again, these are stateless in the sense that they don't have to have any context to be applicable. These are things that are true in all circumstances, or at least in all circumstances. So in other words, if you have team values in anything that the team does, the values would apply. The principles would apply. The engine in this metaphor, the thing that provides you some kind of motion is your process. Now, it's important to understand that your process may be informed in some ways from your values, but largely speaking, your process is agnostic to where you're headed. The process is not just a process. It's a process of how you're going to do things. The process that you adopt is stateless in that way. And so it should be able to produce a plan. You should be able to use your process to produce a plan based on your inputs, right? The inputs here are coming from your values. The process itself is based on your inputs, and it's also responding over time to your inputs. So your process is, you're looking at your values, your values, your values, your values. So your process is a discovery process to understand how is the world different from how we want it to be? How is this software project different from what we want it to be? What kind of customer feedback do we have that we'd like to affect? What kind of performance gaps do we have in this project that we want to improve on? So that's part of your process. You're able to use your values of, we want to be able to improve on these particular metrics, or we want to serve our customers well. You're able to use your values of, we want to be able to improve on these particular metrics, or we want to serve our customers well. You can use that value to inform the process of, let's go and gather customer feedback. The process itself is going to respond to those inputs. And here's how we validate this. If you have good intentions, you have good values, you have good principles, but your process is poor. In other words, you've decided to have those values and intentions, but your process doesn't respect them. It doesn't put them into action. It would be like having, a steering wheel that is totally disconnected from the wheels, or perhaps even worse, is connected in a non-specific way, in some way that you can't really predict what it's going to do if you turn right or left. So the engine needs to receive that input in a way that aligns with the values that generate it. And then the process carries you forward in a direction. That's it. The whole idea of the process to be able to respond to input and carry you forward. If your process doesn't do those two things, if either you're missing the steering wheel altogether, you can't adapt to any kind of input. You can't adapt to pressing the accelerator. If you can't adapt to that situation, or if your engine is so inefficient that it doesn't really matter where you're steering because you can't move forward at any reasonable pace, then your engine, your process needs work. That's how you judge your process. Can we adapt to inputs? Do we have those feedback mechanisms in place? Are we running retros? Are we responding to feedback? And can we move forward? Now, interestingly, this metaphor does extend quite well because we can also talk about what happens when you press on the gas and you hold it down for an extended period of time. Eventually, your engine may overheat. If you have a more advanced engine, for example, it may actually govern the RPM when it recognizes that the temperatures are heating up faster than they should. So if you have a more advanced engine, they can cool down. You may have an advanced cooling system, right? All of these things can actually kind of come back to how do we manage our process on a given team. If we're pressing the gas, we have to expect a trade-off. There's going to be a rise in temperature and eventually there's a breaking point. Does our process have controls or at least warnings? Do we see a warning light whenever we're hitting those breaking points? Ultimately, your plan is going to be affected. By both of these, as you begin to travel in the direction you want to go, which you've decided using your values and you're executing on using your process, you may see feedback in the world that requires you to change your plan. Do you have a flexible enough set of values and a flexible enough process to change your plan? Inflexible plans are once again a core reason for a bad plan. So we're largely fixing the what are you wanting to do with that first part, the values discussion, the principles discussion. This is where we find that aligned motivation concept. This is where we find that public transport. We all are headed in the same direction. Even if we have different outcomes that we care about, we're all headed in the same direction. And the process, that engine, is how we connect our intentions or our values to action. And this is what generates our plan. When we combine our process with our values, when we combine the engine with the steering input, is the only way to actually get where we're trying to go. If either one of those parts are missing, then our plan is simply incomplete. Thanks so much for listening to today's episode of Developer Tea. I'd love to hear your thoughts on this kind of framework of thinking about planning, and why it's so important to have these stateless precursors or generators in advance of your plan. How are you deciding what to do through these kind of filters? I'd love to hear any extensions or adjustments you would make to this framework. You can tell me about those and tell others about those on the Developer Tea Discord community. Head over to developertea.com slash discord to get started totally free today. It's always free. We never are going to charge for that Discord community. And speaking of free, you will get your first three boards on Miro totally free. That's our sponsor today. That's M-I-R-O dot com slash podcast to get your first three boards for free. Thanks so much for listening to this episode. If you enjoyed this discussion, you won't want to miss out on future episodes of this show. Subscribe in whatever podcasting app you're currently using. We are barreling towards the end of this calendar year. And in fact, we're only a few short weeks away from the ninth anniversary of the show. It kind of blows me away that we've been so busy. So if you're interested in this show, please do give us a shout out. We've almost been going for a decade here. Many of you have actually listened for much of that decade. And I really appreciate you sticking around and learning and growing with me as I go through my own career as a software engineer and as an engineering manager and as a director and all the other various things I've done in my career. Thank you for coming with me. I really appreciate each and every person who listens to this show. And I have loved getting your messages over the years. I really appreciate you coming on. I really appreciate you coming on. I really appreciate you coming on. I really appreciate you coming on. I really appreciate you I always love hearing from listeners. One way that you can help this show continue and also get those messages to me because I read every single one of them is to leave a review in whatever podcasting platform you currently are using. This is a huge help to help other people like you who haven't decided to listen to the podcast. Maybe they're looking for something to listen to. Your review might be the thing that pushes them over the edge. So that's a huge help to the show. Thanks so much for listening. Until next time, enjoy your tea. Thanks for listening. Until next time, enjoy your tea.