Vox

Leitura de 15 min

Management Anti-Patterns - False Homogeneity

Summary

In this episode of Developer Tea, host Jonathan Cottrell delves into a common but destructive management anti-pattern: false homogeneity, also described as false equivalence. He argues that this pattern emerges when managers or individuals perceive or communicate that items within a pool—such as tasks, people, or calendar days—are similar or identical on a given dimension when they are actually diverse. This false assumption, often made by default, cripples effective prioritization and focus.

Cottrell illustrates the problem with examples from task management. When a manager declares all backlog tasks as equally important, developers lose the ability to make clear decisions about what to work on first. The implicit message is that order doesn’t matter, which neutralizes the natural heuristic of tackling the most important items first. This leads to paralysis, as individuals fall back on arbitrary criteria like choosing the easiest or hardest task, ignoring critical factors like dependencies, where a seemingly low-priority task might block multiple others.

The anti-pattern also applies to people management, such as assuming two developers are interchangeable. Even with identical skill sets, factors like onboarding time and team chemistry create significant differences in output. Cottrell emphasizes that this mindset builds on a false reality, making planning and effective management nearly impossible.

To combat false homogeneity, Cottrell proposes starting with an assumption of implicit diversity. When evaluating any pool of items—tasks, people, or days—begin by expecting that their characteristics (priority, difficulty, preferences, impact) will differ. This mindset shift forces necessary evaluation and prevents the debilitating compression of unique items into a uniform blob. It is the foundation for establishing true priorities, which is essential for focus.

Ultimately, Cottrell ties the anti-pattern directly to the destruction of focus. When everything is perceived as the same priority, individuals become paralyzed by analysis or make random choices, leading to incoherent outcomes, especially in software development. He concludes that understanding priority and the inherent diversity of our work is fundamental to managing ourselves and our teams effectively.

Topic Timeline

  • 00:00:00 — Introduction to Focus and Management Anti-Patterns — Host Jonathan Cottrell introduces the episode’s theme: a management anti-pattern that destroys focus. He emphasizes that management is not just a formal title but a responsibility everyone has for their own time and priorities. The week will be dedicated to exploring these anti-patterns, relevant for both titled managers and individual contributors.
  • 00:02:48 — Defining the Anti-Pattern: False Homogeneity — Cottrell names the destructive pattern: false equivalence or false homogeneity. This is the act of perceiving or communicating that two or more things are similar or the same on some dimension where they are actually different, and doing this by default. He sets the stage for understanding how this mindset creates problems.
  • 00:03:55 — Example in Task Management: Equal Importance — Using a backlog of tasks as an example, Cottrell explains how declaring all tasks equally important destroys a developer’s ability to prioritize. The unstated implication is that order doesn’t matter, which neutralizes the logical heuristic of doing the most important thing first. This forces developers to use arbitrary or personal criteria, ignoring factors like task dependencies.
  • 00:06:54 — Example in People Management: Interchangeable Developers — The anti-pattern is applied to people management. Cottrell describes the faulty assumption that swapping one developer for another yields equivalent performance. He highlights overlooked factors like onboarding time and team chemistry, which ensure outputs will differ even if skill sets were identical, demonstrating the false reality built on homogeneity.
  • 00:08:13 — The Solution: Assuming Implicit Diversity — Cottrell proposes the refactoring solution: start with an assumption of implicit diversity. When evaluating any pool (tasks, people, days), begin by expecting that characteristics like priority, difficulty, and impact will differ. This mindset prevents compressing unique items together and forces the necessary evaluation to understand where a new task or person fits within a diverse set.
  • 00:10:44 — How False Homogeneity Kills Focus and Cohesion — The host directly connects the anti-pattern to the destruction of focus. When tasks are viewed as the same priority, decision paralysis sets in, or choices are made randomly. For software development, this leads to an incoherent product. Cottrell stresses that focus requires understanding priority, which is tied to human constraints like time, and that recognizing diversity is key to effective management.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2020-01-22T10:00:00Z
  • Duration: 00:13:14

References

Podcast Info

Transcript

[00:00:00] What are you focused on today? I want you to write this down or kind of mentally take note

[00:00:14] of exactly what you’re focused on today. Focus is perhaps the one superpower that is common

[00:00:25] amongst serially successful people. In today’s episode, we’re going to talk about an anti-pattern,

[00:00:35] a management anti-pattern. And in fact, we’re going to do this all week long,

[00:00:39] a management anti-pattern that totally destroys focus. And we’re going to talk about a refactoring

[00:00:47] solution for this anti-pattern. My name is Jonathan Cottrell. You’re listening to Developer T.

[00:00:53] My goal on the show is to help driven developers,

[00:00:55] find clarity, perspective, and purpose in their careers. So this week we are focusing on

[00:01:01] management anti-patterns. And I want to take a step back before you as a non-manager developer,

[00:01:07] before you turn this episode off, I want you to understand something that management is not about

[00:01:13] a title. Management is not about a role on a team. Although there certainly are distinctly

[00:01:22] important roles for management.

[00:01:25] Managers on healthy teams, depending on how your team is structured, management is something that

[00:01:33] we all have to do. And the basic thesis here is that no one else is going to care about your time

[00:01:39] or have as much insight into the time that you spend and to your values, your priorities as you

[00:01:47] are. Even if you were to share everything that you’re feeling and thinking with another person,

[00:01:52] they won’t experience it to the same,

[00:01:55] visceral degree that you will. And so as the person who is most bought in the person who cares

[00:02:03] the most about how your time and how your efforts are managed, how your life and work are managed,

[00:02:11] only you have the opportunity to take the responsibility to become a good manager for

[00:02:20] yourself. So we’re talking about management anti-patterns and that applies to all of us.

[00:02:25] It applies to managers that are kind of formally titled managers, but it also applies to everyone

[00:02:30] else who’s listening to this episode right now. And you can choose what you do with this

[00:02:35] information, but you can kind of implement these ideas both at a team level and at a personal

[00:02:42] management level. So what is the management anti-pattern that kills focus, that destroys

[00:02:48] focus? And actually this turns out to be a very common pattern that managers tend to have. So

[00:02:55] as it turns out, this same pattern, the same mindset doesn’t just kill focus. It also creates

[00:03:03] an inaccurate picture of the world around you. This anti-pattern that we’re talking about is

[00:03:10] the pattern of false equivalence. Another way to describe it is false homogeneity. And you’ll

[00:03:18] recognize this pattern immediately when you hear about it. Now, this is different from a,

[00:03:25] the, you know, the, you know, the, you know, the, you know, the, you know, the, you know,

[00:03:25] the kind of fallacy of false equivalence. Instead, what we’re talking about with this

[00:03:30] anti-pattern is perceiving or communicating two things to be similar or the same on some dimension

[00:03:40] where they’re not actually the same. Moreover, doing this by default. So think about it like

[00:03:48] this. Imagine that you have a backlog of tasks and you and your team are supposed to,

[00:03:55] you know, do this by default. And you’re supposed to do this by default. And you’re supposed to

[00:03:55] do this by default. And you’re supposed to do this by default. And you’re supposed to do this by

[00:03:55] default. And you’re supposed to do this by default. And you’re supposed to do this by default.

[00:03:55] Start working on those tasks and building a product, right? So this anti-pattern would show

[00:04:02] up immediately if I, as a manager said, well, all of these tasks are equally important. All of them

[00:04:10] have the same level of criticality to this project. So what do you do with this information

[00:04:17] as developer? Well, it becomes very difficult to make decisions about what to work on.

[00:04:24] And so you have to choose as a developer what you’re going to work on first and then second

[00:04:32] and third and so on. So how do you choose? The unstated reality when we communicate that things

[00:04:40] are, for example, of equal importance is that the order in which we do things therefore does not

[00:04:48] matter. Because implicitly, if something is more important than another thing,

[00:04:54] on a timeline, it makes sense, it kind of makes logical sense to do the most important things

[00:05:01] first. And indeed, this is a good heuristic that we have kind of built into our brains

[00:05:07] when we’re trying to organize what work we want to do. And here’s the problem. When we see all work

[00:05:14] as equally important, our heuristics for what we should do first now fall back to something that

[00:05:23] is difficult to do first. And that’s the problem. When we see all work as equally important,

[00:05:24] for example, one person might want to work on the easiest thing first because they’re drained,

[00:05:31] they’re tired. Well, another person might want to work on the hardest thing first.

[00:05:35] Additionally, this kind of false equivalence or false homogeneity of these tasks doesn’t take

[00:05:43] into account the possibility of dependencies. A given task may not be very important on its own,

[00:05:51] but if it is a kind of parent dependency,

[00:05:54] multiple other tasks, well, then it kind of inherits the priority of the tasks that are

[00:06:00] dependent on it. Now, I do want to take a step back and recognize that we are simplifying an

[00:06:06] issue that is much more complex. That planning your tasks and figuring out what is the highest

[00:06:12] priority is not as simple as, you know, ordering things based on priority and then inheriting

[00:06:18] thing, inheriting that priority up the chain of dependencies, and then calling it done. That’s

[00:06:23] not the message of the highest priority. It’s not the message of the highest priority. It’s not the

[00:06:24] of this episode. Instead, the message of this episode is that when we communicate as if some

[00:06:30] pool of objects, whether that’s tasks or people or even days on the calendar, when we communicate

[00:06:39] or think or build systems around the false idea that those days or tasks or people are somehow

[00:06:49] equivalent to each other, we build on a false reality.

[00:06:54] This same issue crops up when you try to replace one developer with another. You take an existing

[00:07:03] developer off of a project, and then you hire a new developer, and you assume incorrectly as a

[00:07:09] manager that those two developers will have equivalent performance. What you’re forgetting

[00:07:15] to take into account when you make these assumptions is the time that it takes,

[00:07:19] for example, for that developer to simply onboard into the project itself.

[00:07:24] Even if those two developers had exactly the same skill sets, which is very unlikely to begin

[00:07:29] with, the onboarding time is some switchover. There’s some overhead there. Additionally,

[00:07:36] it’s possible that this new developer doesn’t have the same kind of chemistry

[00:07:40] on the team. And so even at the very highest level, even if you had exactly the same skill set,

[00:07:47] there are two major areas that make these developers’ outputs very likely to be

[00:07:54] different from each other. And additionally, you don’t know the developer that you’ve moved

[00:07:59] on to another project, what their output will be on that project either. So what do we do

[00:08:05] to combat this idea of false homogeneity? How can we get to a place where we recognize that

[00:08:13] every single task that we have to do has a different level of priority? One solution

[00:08:20] starts with your disposition. It starts with your purpose. It starts with your

[00:08:24] assumptions about the world around you. And these are difficult to change, but when you’re

[00:08:29] evaluating a pool, when we’re talking about a pool, we mean two or more subjects that have

[00:08:36] kind of the base unit is the same. Both are tasks, or both are people, or both are some

[00:08:44] base unit. Start with the assumption of implicit diversity. What do we mean by

[00:08:54] implicit diversity? We mean that the output of two people is going to be different. The

[00:08:59] preferences of those two people is going to be different. The priority of two tasks,

[00:09:06] the difficulty of those tasks, all of these kind of attributes, characteristics,

[00:09:12] start with the assumption that those characteristics are diverse, that they’re

[00:09:17] different from each other. They diverge from each other. When you have this mindset,

[00:09:23] instead of compressing the concept of one task and another task together to mean the same thing,

[00:09:32] you can realize that adding a task to a pool of other tasks doesn’t simply mean adding more of

[00:09:40] the same. Instead, it means that evaluation of where that task fits in with the other diverse

[00:09:47] tasks is important. When you add a person to a pool of other people,

[00:09:53] you recognize that the person is not just an extension of the existing culture.

[00:09:59] They may have an effect on the culture. They may have a changing effect on the culture.

[00:10:05] Keep in mind, as we’ve mentioned in recent episodes, that this idea of homogeneity,

[00:10:11] it’s easy for our brains. We don’t want to wrap our minds around how things that are in the same

[00:10:20] classification can be different. We don’t want to wrap our minds around how things that are in the same classification can be different.

[00:10:23] It takes a lot of work to understand the unique characteristics of things that we otherwise can

[00:10:31] compress and put into little compartments. It’s useful. Once again, it’s useful to be able to

[00:10:38] compress ideas and to have kind of pointers and heuristics. But when we’re trying to plan and

[00:10:44] when we’re trying to act as good managers, it can be debilitating to falsely plan for the

[00:10:53] based on the assumption that things have some common characteristics, that they have uniform

[00:11:00] characteristics. Instead, we need to understand how things are different. And the way that this

[00:11:07] kills focus is that when you have everything kind of pooled together as the same, in particular,

[00:11:14] when you have a bunch of tasks that you view as all the same level of priority,

[00:11:19] it’s difficult to know what to do. And you end up

[00:11:23] being paralyzed by trying to analyze what to pick up. It’s also a very bad pattern for software

[00:11:31] development because choosing tasks at random tends to produce software that just doesn’t make

[00:11:38] sense. It’s not cohesive as a product. A much better product strategy is to think about what

[00:11:45] is absolutely essential. We’re going to talk more about prioritization on this show in the future

[00:11:51] because prioritization and

[00:11:53] focus go hand in hand. You can’t focus unless you understand priority. And priority is directly

[00:12:01] tied to these kind of basic restraints that we have as humans. We all have the same restraint

[00:12:09] of time, for example. And so understanding how priority and focus kind of collaborate with each

[00:12:16] other in our lives is very important to operating effectively, to managing effectively.

[00:12:23] Thank you so much for listening to today’s episode of Developer Tea.

[00:12:27] Of course, today’s episode did not have a sponsor, but instead of going and checking

[00:12:31] out our sponsor today, I’d love for you to share this episode with someone that you think can

[00:12:36] benefit from it. Someone who perhaps shares this idea. They want to talk more about identifying

[00:12:43] the diverse characteristics in a pool of commonly classified things, or someone that you think can

[00:12:49] benefit from this. Perhaps a manager or a peer.

[00:12:53] Perhaps a friend of yours, or even simply a friend. Thank you so much for listening. Today’s episode

[00:12:59] can be found at spec.fm. Today’s episode was produced by Sarah Jackson. My name is Jonathan

[00:13:04] Cottrell, and until next time, enjoy your tea.

Visão de gráfico