What are you focused on today? I want you to write this down or kind of mentally take note of exactly what you're focused on today. This is perhaps the one superpower that is common amongst seriously successful people. In today's episode, we're going to talk about an anti-pattern, a management anti-pattern, and in fact, we're going to do this all week long, the management anti-pattern that totally destroys focus. And we're going to talk about a refactoring solution for this anti-pattern. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on the show is to help driven developers find clarity, perspective, and purpose in their careers. So this week we are focusing on management anti-patterns, and I want to take a step back before you as a non-manager developer, before you turn this episode off, and once you understand something, that management is not about a title. Management is not about a role on a team, although there certainly are distinctly important roles for managers on healthy teams, depending on how your team is structured. Management is something that we all have to do. And the basic thesis here is that no one else is going to care about your time or have as much insight into the time that you spend and to your values or priorities as you are. Even if you were to share everything that you're feeling and thinking with another person, they won't experience it to the same visceral degree that you will. And so as the person who is most bought in, the person who cares the most about how your time and how your efforts are managed, how your life and work are managed, only you have the opportunity to take the responsibility to become a good manager for yourself. So we're talking about management anti-patterns, and that applies to managers that are kind of formally titled managers, but it also applies to everyone else who's listening to this episode right now, and you can choose what you do with this information, but you can implement these ideas both at a team level and at a personal management level. So what is the management anti-pattern that kills focus, that destroys focus? And actually this turns out to be a very common pattern that managers tend to follow. And as it turns out, this same pattern, the same mindset doesn't just kill focus, it also creates an inaccurate picture of the world around you. This anti-pattern that we're talking about is the pattern of false equivalents. Another way to describe it is false homogeneity, and you'll recognize this pattern immediately when you hear about it. This is different from the kind of fallacy of false equivalents. Instead, what we're talking about with this anti-pattern is perceiving or communicating two things to be similar or the same on some dimension, whether or not actually the same. Moreover, doing this by default. So think about it like this. Imagine that you have a backlog of tasks. You and your team are supposed to start working on those tasks and building a product. So this anti-pattern would show up immediately if I, as a manager, said, well, all of these tasks are equally important. All of them have the same level of criticality to this project. So what do you do with this information as developer? Well it becomes very difficult to make decisions about what to work on. And so you have to choose as a developer what you're going to work on first and then second and third and so on. So how do you choose? The unstated reality when we communicate that things are, for example, of equal importance that the order in which we do things, therefore, does not matter. Because implicitly, if something is more important than another thing, on a timeline, it makes sense, it kind of makes logical sense to do the most important things first. And indeed, this is a good heuristic that we have kind of built into our brains when we're trying to organize what work we want to do. And here's the problem. When we see all work as equally important, our heuristics for what we should do first, now fall back to something that is difficult to agree on. For example, one person might want to work on the easiest thing first because they're drained, they're tired. Well, another person might want to work on the hardest thing first. Additionally, this kind of false equivalence or false homogeneity of these tasks doesn't take into account the possibility of dependencies. A given task may not be very important on its own, but if it is a kind of parent dependency to multiple other tasks, then it kind of inherits the priority of the tasks that are dependent on it. Now I do want to take a step back and recognize that we are simplifying an issue that is much more complex. That planning your tasks and figuring out what is the highest priority is not as simple as ordering things based on priority and then inheriting that priority up the chain of dependencies and then calling it done. That's not the message of this episode. Instead, the message of this episode is that when we communicate, as if some pool of objects, whether that's tasks or people or even days on the calendar, when we communicate or think or build systems around the false idea that those days or tasks or people are somehow equivalent to each other, we build on a false reality. This same issue crops up when you try to replace one developer with another. You take an existing developer off of a project and then you hire a new developer and you assume, incorrectly as a manager, that those two developers will have equivalent performance. What you're forgetting to take into account when you make these assumptions is the time that it takes, for example, for that developer to simply onboard into the project itself, even if those two developers had exactly the same skill sets, which is very unlikely to begin with, the onboarding time is some switch over. There's some overhead there. Additionally, it's possible that this new developer doesn't have the same kind of chemistry on the team. And so even at the very highest level, even if you had exactly the same skill set, there are two major areas that make these developers outputs very likely to be different from each other. And additionally, you don't know the developer that you've moved on to another project, what their output will be on that project either. So what do we do to combat this idea of false homogeneity? How can we get to a place where we recognize that every single task that we have to do has a different level of priority? One solution starts with your disposition. It starts with your assumptions about the world around you. And these are difficult to change, but when you're evaluating a pool, when we're talking about a pool, we mean two or more subjects that have kind of the base unit is the same, both are tasks or both are people or both are, you know, some base unit. Start with the assumption of implicit diversity. What do we mean by implicit diversity? We mean that the output of two people is going to be different. The preferences of those two people is going to be different. The priority of two tasks, the difficulty of those tasks, all of these kind of attributes, characteristics, start with the assumption that those characteristics are diverse, that they're different from each other. They diverge from each other. When you have this mindset, instead of compressing the concept of one task and another task together to mean the same thing, you can realize that adding a task to a pool of other tasks doesn't simply mean adding more of the same. Instead, it means that evaluation of where that task fits in with the other diverse tasks is important. When you add a person to a pool of other people, you recognize that the person is not just an extension of the existing culture. They may have an effect on the culture. They may have a changing effect on the culture. Keep in mind, as we've mentioned in recent episodes, that this idea of homogeneity, it's easy for our brains. We don't want to wrap our minds around how things that are in the same kind of classification can be different, because it takes a lot of work. It takes a lot of work to understand the unique characteristics of things that we otherwise can compress and put into little compartments. It's useful. Once again, it's useful to be able to compress ideas and to have pointers and heuristics, but when we're trying to plan and when we're trying to act as good managers, it can be debilitating to falsely plan based on the assumption that things have some common characteristics, that they have uniform characteristics. Instead, we need to understand how things are different. The way that this kills focus is that when you have everything pulled together as the same, in particular, when you have a bunch of tasks that you view as all the same level of priority, it's difficult to know what to do and you end up being paralyzed by trying to analyze what to pick up. It's also a very bad pattern for software development, because choosing tasks at random tends to produce software that just doesn't make sense. It's not cohesive as a product. A much better product strategy is to think about what is absolutely essential. We're going to talk more about prioritization on this show in the future, because prioritization and focus go hand in hand. You can't focus unless you understand priority. Priority is directly tied to these basic restraints that we have as humans. We all have the same restraint of time, for example. Understanding how priority and focus collaborate with each other in our lives is very important to operating effectively, to managing effectively. Thank you so much for listening to today's episode of Developer Tea. Of course today's episode did not have a sponsor, but instead of going and checking out our sponsor today, I'd love for you to share this episode with someone that you think can benefit from it. Someone who perhaps shares this idea, they want to talk more about identifying the diverse characteristics and a pool of commonly classified things, or someone that you think can benefit from this, perhaps a manager or a peer of yours, or even simply a friend. Thank you so much for listening. Today's episode can be found at spec.fm. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell, and until next time, enjoy your tea.