Hey everyone, welcome to Developer Team. My name is Jonathan Patrell. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. Today's episode is going to be very short, and it's going to be about a very large topic. Actually, it's about all large topics in a way. Today, we're going to talk about the concept from philosophy called hyperobjects. What is a hyperobject? A hyperobject is a concept that is so large that it kind of extends beyond space and time. There's not really any one point that you could point to. The concept, for example, the concept of global warming is a good example of a hyperobject. A hyperobject. This framework comes from a guy named Timothy Morton. Generally speaking, this isn't very specific to engineering, but the concept is useful when thinking about different problems that we might encounter, especially problems that are organization-wide at a company, for example. Now, you'd be hard-pressed to compare. Any problem that you're facing at your company with global warming, that's not the idea that's being presented here. Instead, the idea is to think about the shape of the problem that you're trying to solve. It may be, as far as the problem is concerned with your particular scenario, you can kind of treat it as if it is a hyperobject, even though the philosophical definition of this from a human perspective is that it's not a hyperobject. It's not a hyperobject. It's not a hyperobject. It's not a hyperobject. It's not a hyperobject. It's not a hyperobject. It's not a hyperobject. It's not a hyperobject. It's not a hyperobject. Humanity's perspective is much larger. So what does that mean? Well, let's imagine kind of the opposite, right? The opposite of a hyperobject would be a very clear point-in-time concrete object, right? And so you can think about this kind of like as a spectrum from a very clear point-in-time concrete object all the way to something that doesn't really have clear boundaries. The boundaries are not really obvious. There's a couple other properties that this philosophy identifies about hyperobjects. One of them is that it's very viscous. It's kind of an interesting word to describe a problem that you might be trying to solve. It's viscous. What this means is that it kind of shows up everywhere, right? It's what Morton would say is sticky. The problem is showing up on all of the surfaces that it touches. Right? Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right.! Right. Right. Camp! At At see in an engineering team that you could sort of treat as hyper objects. A couple of simple examples might be something like tech debt. And the reason for this is because tech debt is more or less as a concept, right? And it's a very large concept that a lot of people treat very differently. It doesn't have super clear boundaries on exactly what is or isn't tech debt. But companies very often, every company I've ever worked at has tried to put some kind of boundaries on what work it would consider technical debt. What work does it consider kind of like optional technical improvement versus product work? This is a very common separation. But as you move forward in time, some of those things that previously were considered tech debt either go away entirely because they were taken out by some new design, right? They might evolve into much more important work because of some kind of scaling or a situation change, right? So you can see how the boundaries of what tech debt is in a given situation are not incredibly clear. And so if you're looking at a hyper object problem, right, or a problem that kind of looks like this amorphous shape, there's a couple of things that you can do to get rid of that. One is to get rid of the things that would be considered kind of anti-patterns, bad approaches to trying to solve hyper object problems. One of them might be, you know, trying to fix the problem, right? That sounds attractive. It sounds nice that we might pay down our tech debt backlog. But because of the nature of the problem, it is essentially an unsolvable problem. Instead of solving this with a specific effort, your efforts need to match the shape of the hyper object in its characteristics. So what does that mean? It means that whatever efforts you're using to solve this particular type of problem where the edges are fuzzy, the efforts will also be fuzzy. If tech debt doesn't go away, then the solution to tech debt doesn't go away either. You don't run a one-time tech debt program and then call it done, right? This is not something that lives at a point in time. It is something that instead stretches out, right? It is a conceptual model that can't really be contained. It can't really be, you know, in a very formal sense, it can't be solved. So some other examples of this might be things like user experience, or developer experience, right? Even things like performance management. These are concepts that we try to put frameworks in place. Now, I want to kind of draw a distinction between framework programs, right? In other words, you're going to practice performance management as an engineering manager, right? You may have performance management conversations, you may have calibrations, you may have promotion conversations. You have all of these kind of individual atomic events that happen, but there's not a solution to performance management. There's many different responses to the existence of this problem, right? To the existence of the hyper object that is performance management. So we need to think about this in terms that are less concrete because the problem is not concrete. When we try to create a framework for solving these problems, which can be effective for getting things that we care about, what we're essentially doing is we're trying to determine a part of this problem, or we're trying to maybe take a snapshot in time. That's essentially what we do when we have a performance management conversation. When we set up some kind of expectations for engineers using a, you know, a competency matrix, right? This is a snapshot in time. Could we say that we've solved performance management with a competency matrix? I don't think so, right? In fact, I know that that's not going to happen because our jobs continue evolving. And this is exactly what a hyper object does. The hyper object travels along with time. It doesn't become a solved entity. It doesn't leave, you don't leave it behind, right? You're not going to leave tech debt, you're not going to leave user experience behind. You're not going to leave performance management behind. These are all kind of practices, right? But they're practices that show up as like in the, in the generic shape of a problem. And so because the edges are fuzzy, because it's hard to say, you know, what is the definition of done? When you're trying to operate on a hyper object like performance management, there isn't one. Instead, what we do is we're going to leave performance management behind. And so, you know, what we do is we kind of take snapshots, right? We snapshot in time, we snapshot a particular effect. So instead of saying we're solving performance management, we might say that we're trying to scale the company in order to meet a particular demand. We're not solving performance management, we're operating inside of that problem. We're essentially interacting with the hyper object. And the same way, this is, this is kind of a freeing, you will never be rid of tech debt. You may have less of it for a certain point of point in time, but because tech technical debt is something that interacts with market forces, right? Because it's something that is a larger problem that exists even beyond your company. It exists in other companies. And so you may be responding to other people's technical debt by taking on some of your own. There are, uh, an enormous amount of technical debt that is being taken on by other people. And so number of considerations that you would have to make that are never going to be able to be made in total, right? So you may be able to respond to however the hyperobject is acting, right? If we want to kind of personify technical debt, technical debt is going to continue on its journey. It's going to continue growing or shrinking. It's going to continue responding to other forces, market forces, hiring, you know, even technical forces. So there may be some kind of technical change in the environment that implies that you have less or more or different kinds of technical debt that you need to adopt into your working environment. So what we should do, instead of viewing, you know, these hyperobjects as something to try to be contentious, we should look at them as something that is going to be able to be contained. We should instead focus on what are the outcomes that we care about inside of this problem. We're never going to get to the outside of it. We're never going to contain it. We're never going to finish designing, right? Design is another, it's kind of similar to, you know, user experience. Design is a always happening thing. It's an emergent property of the work that we do. So we're never going to be quite done with it. We're never going to be quite done with that. And it's not, I also want to draw another distinction here that it's, it's not because we are, you know, overly perfectionistic. That's not the same thing as what I'm talking about here. Instead, the concept of being, you know, done with design implies that there is some kind of terminal state. There's some terminal, you know, landing point where no more, uh, problems emerge that are under the umbrella of design. If you were to land at that point, uh, then, you know, this, this hyper object kind of, uh, uh, goes away, right? Another example of a hyper object might be hunger. This is something that will always be responding to different forces, a very dynamic system. Um, you know, and when I talk about hunger, I mean, uh, kind of a worldwide phenomenon. Does it change over time? Absolutely. Right. We have, uh, we have hunger, uh, you know, worldwide hunger, especially as a phenomenon that people experience individually has gone down drastically, but it doesn't mean that the concept is gone. We can't suddenly, you know, stop hunger. Hunger is something that happens as a part of, uh, you know, the, the experience of being human. It changes over time. Uh, the, the kinds of food that we have access to change over time. Uh, we, you know, you could imagine that hunger is actually, um, you know, is, is a larger concept that goes beyond just desire for food. It may actually be a relationship to food, right? So there's all of these ways that these kinds of problems are intractable. They, you can't really put a container on them. You can't really find them in space and time. Uh, no one person can really fit it all in their head. Usually, right. Multiple people have different angles on the same hyper object type problem. And so if we, uh, if we can let go of this, um, you know, kind of core driving idea that we might have a solution to this one day, uh, instead we accept that we never will, right. If we accept that instead we should look at different problems or at least, uh, look at a snapshot of that problem. Um, then we can, more justifiably spend our time on certain initiatives, right. On certain projects that might take out an important chunk of what we would call technical debt, or we do away with the term entirely. And we opt out of interacting with the hyper object. And we instead kind of characterize that, you know, as, as some different category. Uh, there's a lot of kind of semantic meaning, right? That's this language meaning. When we start talking about these philosophical concepts, but it's a useful framework because, uh, the language is how we talk about this together and how we conceptualize the work that we should or shouldn't be doing. Language and semantics are really how we develop things like goals and definition of done. It's how we, uh, you know, derive some kind of requirements for, for, uh, products that we're building. So it is important, um, to, to be able to conceptualize these ideas. This, uh, this framework or, or a way of thinking about, uh, big problems that are intractable. My, my hope is that if you're listening to this and you've encountered this kind of, uh, initiative where you really want to kind of take on the world, uh, you want to take on the entire tech debt backlog, pay it all down, and then try to keep it all down. Uh, hopefully this will help you kind of reset your thinking around these larger problems that are never quite done. Thank you so much for listening to today's episode of developer T. I hope you enjoyed this episode. Uh, we are continuing to record these both audio and video. Now, uh, this is after 10 years of doing this podcast. We finally started doing video. Um, we're going to be rolling out these videos over the next month, two months, three months. Uh, it takes some time to change our processes so that we have a video editing, uh, you know, aspect to what we're doing with production. So thank you for your patience. Thank you so much for listening. If you enjoyed this episode, please do. Well, there's a couple of things you can do. Uh, one, you can leave a review in iTunes. You can like subscribe on YouTube. If you find this on YouTube, uh, you can join the developer T discord community and come and talk about these episodes. That's at developer T.com slash discord. It's totally free. Always will be for people who listen to this show. Thank you so much for listening. And until next time, enjoy your tea.