Vox

Leitura de 18 min

Don’t Try to Solve Hyperobject Problems Once

Summary

In this episode of Developer Tea, host Jonathan Patrell introduces the philosophical concept of hyperobjects, originally coined by Timothy Morton. A hyperobject is a problem so vast and complex that it extends beyond clear spatial and temporal boundaries, making it impossible to point to a single location or moment. Examples include global warming, tech debt, user experience, developer experience, and performance management. These are not concrete issues with definitive solutions but rather ongoing, evolving phenomena that resist containment.

Jonathan explains key characteristics of hyperobjects: they are viscous (sticky and showing up everywhere), have fuzzy boundaries, and evolve over time. Unlike concrete problems that can be solved once and for all, hyperobjects require a different approach. Attempting to “fix” a hyperobject like tech debt with a one-time initiative is an anti-pattern because the problem itself is dynamic and interacts with market forces, technical changes, and organizational shifts. Instead of seeking a terminal solution, we must accept that these problems are intractable and will persist.

The episode emphasizes shifting our mindset from solving hyperobjects to operating within them. This means focusing on specific outcomes or snapshots in time rather than trying to eliminate the problem entirely. For instance, instead of aiming to “solve performance management,” we might implement frameworks for performance conversations or competency matrices as ongoing practices. Similarly, with tech debt, we should prioritize initiatives that address critical chunks without expecting to ever be “debt-free.”

Jonathan argues that this framework is liberating: it allows us to spend our time more justifiably on projects that matter, without the frustration of chasing an unattainable finish line. By recognizing hyperobjects for what they are—amorphous, ever-present challenges—we can develop more realistic goals, definitions of done, and requirements. This philosophical lens helps teams conceptualize large-scale problems in software development and beyond, fostering more effective and sustainable approaches to complex work.

Recommendations

Concepts

  • Hyperobjects — A philosophical concept referring to problems so vast they extend beyond space and time, with characteristics like viscosity and fuzzy boundaries, applicable to issues like tech debt and performance management.

People

  • Timothy Morton — Philosopher who coined the concept of hyperobjects, mentioned as the originator of this framework for thinking about large, intractable problems.

Topic Timeline

  • 00:00:00 — Introduction to hyperobjects and their relevance to developers — Jonathan introduces the episode’s topic: hyperobjects, a philosophical concept from Timothy Morton. He explains that hyperobjects are problems so large they extend beyond space and time, like global warming. While not specific to engineering, this framework is useful for thinking about organization-wide problems, such as those at a company. The idea is to consider the shape of the problem you’re facing, even if it’s not a true philosophical hyperobject on a global scale.
  • 00:02:05 — Characteristics of hyperobjects: viscosity and fuzzy boundaries — Jonathan contrasts hyperobjects with concrete objects, describing a spectrum from clear, point-in-time problems to those with ambiguous boundaries. He details key properties: hyperobjects are viscous (sticky, appearing everywhere) and lack clear edges. Examples in tech include tech debt, which is treated differently by various people and lacks strict definitions. The boundaries of what constitutes tech debt shift over time due to design changes, scaling, or situational evolution, making it a classic hyperobject.
  • 00:04:19 — Anti-patterns: trying to solve hyperobjects with one-time efforts — Jonathan warns against attempting to ‘fix’ hyperobject problems outright, like paying down a tech debt backlog in a single effort. Because hyperobjects are unsolvable by nature, efforts must match their shape—fuzzy and ongoing. You cannot run a one-time tech debt program and consider it done; instead, solutions must stretch over time. Other examples include user experience, developer experience, and performance management, which are continuous practices rather than solvable entities.
  • 00:07:40 — Hyperobjects evolve with time and cannot be left behind — Jonathan emphasizes that hyperobjects travel along with time and don’t become ‘solved.’ You won’t leave tech debt, user experience, or performance management behind; they are enduring practices. Because the edges are fuzzy, there’s no clear ‘definition of done’ for operating on a hyperobject. Instead, we take snapshots in time—like performance management conversations or competency matrices—which are responses to the hyperobject’s existence, not solutions to it.
  • 00:10:14 — Shifting focus to outcomes within hyperobjects, not containment — Jonathan advises focusing on desired outcomes within hyperobject problems rather than trying to contain or finish them. We’ll never be outside of issues like design or tech debt; they are emergent properties of our work. This isn’t about perfectionism but recognizing that hyperobjects lack terminal states. Even global hunger, while reduced, persists as a concept that evolves with human experience and food access, illustrating the intractable nature of these problems.
  • 00:13:03 — Acceptance and practical application: spending time on initiatives — Jonathan suggests accepting that hyperobjects can’t be solved, which frees us to spend time on specific initiatives that address important chunks of the problem. By letting go of the idea of a final solution, we can more justifiably focus on projects, like reducing technical debt in key areas. Language and semantics are crucial here—they shape how we conceptualize work, set goals, and derive requirements. This framework helps reset thinking around large, never-quite-done problems.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2025-08-17T07:00:00Z
  • Duration: 00:15:46

References

Podcast Info

Transcript

[00:00:00] hey everyone welcome to developer team my name is jonathan patrell my goal on the show is to

[00:00:11] help driven developers like you find clarity perspective and purpose in their careers

[00:00:14] today’s episode is going to be very short uh and it’s going to be about a very large topic

[00:00:21] um actually it’s about all large topics in a way uh today we’re going to talk about the concept

[00:00:28] from philosophy called hyper objects what is a hyper object a hyper object is a concept that

[00:00:38] is so large that it kind of extends beyond space and time there’s there’s not really any one point

[00:00:45] that you could point to uh the concept for example uh the concept of global warming is a good example

[00:00:54] of a hyper object um the

[00:00:58] this uh framework comes from a guy named timothy morton and generally speaking you know this isn’t

[00:01:07] very specific to engineering uh but the concept is useful when thinking about uh different problems

[00:01:14] that we might encounter especially problems that are organization-wide at a company for example

[00:01:21] right now it would be hard you’d be hard-pressed to compare any problem that you’re facing at your

[00:01:28] global warming uh that’s not the the idea that’s being presented here instead uh the idea is to

[00:01:35] think about the shape of the problem that you’re trying to solve and it may be as far as the the

[00:01:43] problem is concerned with your particular scenario you can kind of treat it as if it is a hyper object

[00:01:51] even though uh you know the the philosophical definition of this from a humanity’s perspective

[00:01:58] is much larger so what does that mean well let’s imagine kind of the opposite right the opposite

[00:02:05] of a hyper object would be a very clear uh point in time the concrete object right and so you can

[00:02:12] think about this kind of like as a as a spectrum from a very clear point in time concrete object

[00:02:18] all the way to something that doesn’t really have clear boundaries the boundaries are not really

[00:02:23] obvious there’s a couple other properties

[00:02:28] that this philosophy identifies about uh hyper objects one of them is that it’s very viscous

[00:02:34] uh it’s kind of an interesting word to describe a problem that you might be trying to solve it’s

[00:02:40] viscous what this means is that it kind of shows up everywhere right it’s what they would what

[00:02:46] morton would say is sticky uh the problem is is showing up on all of the surfaces that it touches

[00:02:52] um so what are some problems that you might see

[00:02:58] um so what are some problems that you might see

[00:03:01] as hyper objects a couple of uh simple examples might be uh something like tech debt and the

[00:03:09] reason for this is because tech debt is more or less as a concept right and and it’s a very large

[00:03:15] concept that a lot of people treat very differently it doesn’t have super clear boundaries on exactly

[00:03:21] what is or isn’t tech debt companies very often every company i’ve ever worked at

[00:03:28] tried to put some kind of boundaries on what work it would consider technical debt uh what work does

[00:03:35] it consider kind of like optional technical improvement versus product work this is a very

[00:03:40] common separation but as you move forward in time some of those things that previously were

[00:03:47] considered tech debt either go away entirely because they were taken out uh you know by by

[00:03:55] some new design right they might have been taken out by some new design right they might have been

[00:03:58] evolved into much more important work because of some kind of scaling or you know a situation

[00:04:04] change right so so you can see how the boundaries of what tech debt is in a given situation are not

[00:04:12] incredibly clear and so if you’re looking at a hyper object problem right or a problem that kind

[00:04:19] of looks like this amorphous shape there’s a couple of things that would be considered kind

[00:04:24] of anti-patterns bad uh

[00:04:28] approaches to trying to solve hyper object problems one of them might be uh uh you know

[00:04:34] trying to fix the problem all right that sounds attractive it sounds nice that we might pay down

[00:04:41] our our tech debt backlog but because of the nature of the problem uh it is it is essentially

[00:04:50] an unsolvable problem instead of solving this with a specific effort your efforts need to

[00:04:58] match the shape of the hyper object in its characteristics so what does that mean it means

[00:05:04] that whatever efforts you’re using to solve this particular type of problem where the edges are

[00:05:09] fuzzy the efforts will also be fuzzy the the if if tech debt doesn’t go away then the solution to

[00:05:19] tech debt doesn’t go away either you don’t run a one-time tech debt program and then call it done

[00:05:25] right this is not something that is

[00:05:28] that lives at a point in time it is something that instead stretches out right it is a conceptual

[00:05:36] model uh that that can’t really be contained it can’t really be you know in in the in a very

[00:05:43] formal sense it can’t be solved so some other examples this might be things like user experience

[00:05:52] or developer experience right even things like performance management

[00:05:58] these are these are concepts that we try to put frameworks in place now i want to kind of draw a

[00:06:05] distinction between framework programs right in other words you’re going to practice performance

[00:06:13] management as an engineering manager right you may have performance management conversations you

[00:06:19] may have calibrations you may have promotion conversations you have all of these kind of

[00:06:26] individual atomic events that have to do with performance management and you may have

[00:06:28] performance management conversations that have to do with performance management and you may have

[00:06:28] happen but there’s not a solution to performance management there’s there’s many different

[00:06:34] responses to the existence of this problem right to the existence of the hyper object that is

[00:06:42] performance management so we need to think about this in terms uh that are less concrete because

[00:06:49] the problem is not concrete when we try to create a framework for solving these problems which can

[00:06:55] be effective for getting things that we care about but we can’t do that because we don’t have the

[00:06:58] what we’re essentially doing is we’re trying to determine a part of this problem or we’re trying

[00:07:06] to maybe take a snapshot in time right that’s that’s essentially what we do um when we have

[00:07:12] a performance management conversation when we set up some kind of expectations for engineers using a

[00:07:19] you know a competency matrix right this is a snapshot in time could we say that we’ve solved

[00:07:26] performance management and we’ve solved performance management and we’ve solved performance management

[00:07:28] with a competency matrix i don’t think so right in fact i know that that’s not going to happen

[00:07:34] because our jobs continue evolving and this is exactly what a hyper object does the hyper object

[00:07:40] travels along with time it doesn’t uh become a solved entity it doesn’t leave you don’t leave

[00:07:47] it behind right you’re not going to leave tech debt behind you’re not going to leave user experience

[00:07:52] behind you’re not going to leave performance management behind these are all kind of practices

[00:07:57] right

[00:07:58] but they’re practices that show up as like in the in the generic shape of a problem and so

[00:08:05] because the edges are fuzzy because it’s hard to say you know what is the definition of done

[00:08:10] um when you’re trying to operate on a hyper object like performance management there isn’t one

[00:08:18] instead what we do is we kind of take snapshots right we snapshot in time we snapshot a particular

[00:08:26] effect

[00:08:28] so instead of saying we’re solving performance management we might say that we’re trying to

[00:08:32] scale the company uh in order to meet a particular demand we’re not solving performance management

[00:08:39] we’re operating inside of that problem we’re we’re essentially interacting with the hyper object

[00:08:45] in the same way uh this is this is kind of a freeing idea you will never be rid of tech debt

[00:08:54] you may have less of it for a certain point of

[00:08:58] point in time but because technical debt is something that interacts with market forces

[00:09:04] right because it’s something that is a larger problem that exists even beyond your company

[00:09:09] it exists in other companies and so you may be responding to other people’s technical debt

[00:09:15] by taking on some of your own there are uh an enormous number of considerations

[00:09:21] that you would have to make that are never going to be able to be made uh in in

[00:09:28] in total right so you may be able to uh respond to however the hyper object is acting right if we

[00:09:37] want to kind of personify technical debt technical debt is going to continue on its journey uh it’s

[00:09:43] going to continue growing or shrinking it’s going to continue uh responding to other forces market

[00:09:49] forces uh hiring you know uh even technical uh forces so there may be some kind of technical

[00:09:56] change in the environment

[00:09:58] that implies that you have less or more or different kinds of technical debt that you need to

[00:10:04] adopt into your uh into your working environment so what we should do instead of viewing uh

[00:10:14] you know these hyper objects as something to try to be contained we should instead focus on what

[00:10:21] are the outcomes that we care about inside of this problem we’re never going to get to the outside of

[00:10:26] it we’re never going to contain it we’re never going to get to the outside of it we’re never going to contain it

[00:10:28] we’re never going to finish designing right design is another it’s kind of similar to to you know

[00:10:36] user experience design is a is a always happening thing it’s an emergent property

[00:10:43] of the work that we do so we’re never going to be quite done with that and it’s not i also want

[00:10:50] to draw another distinction here that it’s it’s not because we are you know overly perfectionistic

[00:10:55] that’s not the the same thing that we’re going to be doing we’re going to be doing the same thing

[00:10:58] is what i’m talking about here instead uh the the concept of being come you know done with design

[00:11:05] uh implies that there is some kind of uh terminal state there’s some terminal uh you know landing

[00:11:13] point where no more uh problems emerge that are under the umbrella of design if you were to land

[00:11:24] at that point uh then you know this this hyper

[00:11:28] kind of uh goes away right another example of a hyper object might be hunger this is something

[00:11:36] that will always be responding to different forces a very dynamic system um you know and when i talk

[00:11:43] about hunger i mean uh kind of a worldwide phenomenon does it change over time absolutely

[00:11:49] right we have uh we have hunger uh you know worldwide hunger especially as a phenomenon

[00:11:57] that

[00:11:58] people experience individually has gone down drastically but it doesn’t mean that the concept

[00:12:04] is gone we can’t suddenly you know stop hunger hunger is something that happens as a part of

[00:12:12] uh you know the experience of being human it changes over time uh the time the kinds of food

[00:12:18] that we have access to change over time uh we you know you could imagine that hunger is actually

[00:12:24] uh you know is a larger concept that goes

[00:12:28] beyond just desire for food it may actually be a relationship to food right so there’s all of

[00:12:34] these ways that these kinds of problems are intractable they you can’t really put a container

[00:12:41] on them you can’t really find them in space and time uh no one person can really fit it all in

[00:12:46] their head usually right multiple people have different angles on the same hyper object type

[00:12:52] problem and so if we uh if we can let go of this um

[00:12:58] you know kind of core driving idea that we might have a solution to this one day

[00:13:03] instead we accept that we never will right if we accept that instead we should look at different

[00:13:10] problems or at least uh look at a snapshot of that problem um then we can more justifiably spend our

[00:13:18] time on certain initiatives right on certain projects that might take out an important chunk

[00:13:25] of what we would call technical debt

[00:13:28] we do away with the term entirely and we opt out of interacting with the hyper object and we

[00:13:33] instead kind of characterize that you know as as some different category uh there’s a lot of kind

[00:13:40] of semantic meaning right that’s this language meaning when we start talking about these

[00:13:46] philosophical concepts but it’s a useful framework because uh the language is how we talk about this

[00:13:54] together and how we conceptualize the work that we should or shouldn’t be doing

[00:13:58] language and semantics are really how we develop things like goals and definition of done

[00:14:04] it’s how we uh you know derive some kind of requirements for for uh products that we’re

[00:14:09] building so it is important um to to be able to conceptualize these ideas this uh this framework

[00:14:18] or or a way of thinking about big problems that are intractable my my hope is that if you’re

[00:14:25] listening to this and you’ve encountered this kind of

[00:14:28] uh initiative where you really want to kind of take on the world uh you want to take on the

[00:14:33] entire tech debt backlog pay it all down and then try to keep it all down uh hopefully this will

[00:14:39] help you kind of reset your thinking around these larger problems that are never quite

[00:14:46] done thank you so much for listening to today’s episode of developer t i hope you enjoyed this

[00:14:50] episode uh we are continuing to record these both audio and video now uh this is after i don’t know

[00:14:58] 10 years of doing this podcast we finally started doing video um we’re going to be rolling out these

[00:15:04] videos over the next month two months three months uh it takes some time to change our processes so

[00:15:10] that we have a video editing uh you know aspect to what we’re doing with production so thank you

[00:15:15] for your patience thank you so much for listening if you enjoyed this episode please do well there’s

[00:15:19] a couple things you can do uh one you can leave a review in itunes you can like subscribe on youtube

[00:15:25] if you find this on youtube you can join the

[00:15:28] developer t discord community and come and talk about these episodes that’s at developer t.com

[00:15:32] slash discord it’s totally free always will be for people who listen to this show thank you so

[00:15:38] much for listening and until next time enjoy your tea

Visão de gráfico