Jun 10, 2022
Continuing our conversation with Alicia Juarrero, we go deeper on enabling constraints, specifically catalysts and feedback loops, emergence, what this means for management and why in complexity you need to start with context. Our guest is Professor Alicia Juarrero, a leading complexity theory philosopher and academic, as well as the founder and president of VectorAnalytica, a technology company that specializes in large scale scientific data capture and real time analysis tools. Alicia's work in complexity theory is widely quoted by thought leaders in the technology space and referenced in many recent complexity-informed approaches for managing highly dynamic systems, as well as in knowledge management.
Hosts are Kristof Van Tomme (CEO & Co-founder, Pronovix), and Marc Burgauer (Principal Consultant and Co-founder at Contextualise).
Also available on Anchor and Google
Transcript
Marc:
So you, you talked about enabling constraints, that you need catalysts and feedback loops and to make, to make them work, et cetera. There's one, it's one of my issues currently. In the IT space enabling constraints has started to appear, especially in some lean agile circles, but it's often misunderstood. So could you explain a little bit, maybe ideally in connection with membranes because that's relevant to API folks, how can we use catalysts and feedback loops to make enabling constraints happen?
Alicia:
I think the catalysts and the feedback loops are the enabling constraints. They themselves are the enabling constraints. And the reason I use the word "constraint" is because a catalyst in biochemistry is conserved. It does not transfer energy. It creates the conditions that allow energy to flow more easily and therefore accelerates a particular reaction. I have to find a paper I wrote decades ago about managers as catalysts. I think that one basis of management from a complexity perspective is precisely to serve as a catalyst, as the agent of conditions that facilitate flow of information and energy and resources in the direction that the board has decided it wants the company to go. It's almost like bulldozing the terrain, you know, you're not pushing the entity, but if you create a slope by providing more resources, then water will naturally flow in that direction if you will. So I think acting as a catalyst... I've learned from Marc and his friends at lean agile that shorter feedback loops is important because the shorter the feedback loop, the more embedded you are in the context. The longer the loop takes to complete, the farther away you are from the output that you want information back on. So shorter feedback loops. One thing we know about, complex systems, and that's back to the stochasts and the Cartesian fish schools, is that the more variety of components... And more variety does not mean more of them numerically. It means literally different types of components. You know, that helps with the flexibility, that helps with the facilitation of the potential for a new emergence. So you can't force a new emergence. You can't push a new emergence. You can create the conditions that make it happen. And that's all I'm calling "enabling constraints": conditions that lower barriers to energy flow in the direction you wanted, or maybe raise barriers to energy flow in the directions you don't want it, or that you think will create an emergent property. You may be wrong, but that's what I think an enabling constraint does. I have a friend who taught for many years at the naval academy, Bob Artiglianni, and he has a beautiful example of Admiral Nelson and how he beat Napoleon at Waterloo. And one of the things was, he created a sense of camaraderie among the officer core by literally having lunch with them often or breaking meals, having dinner. So it got to the point that the feedback loop was so tight between that officer court, they could almost know what the others were thinking. And so that's sort of an information channel that was created that enabled a distributed form of control, which is another characteristic of many complex systems. It enabled that distributed control to be coherent enough, but sloppy enough so that when something unexpected happened in the battlefield at Waterloo... the individual officers on the individual ships could take the initiative and maneuver to find a new path to achieve that coherent purpose that they knew about, that they were all striving for. I don't know if that's a good example, but it's as good as any that I can think of.
Kristof:
I think one of the discussions I've had with Marc, something that he said that really picked my interest was this idea of managers as enabling constraints is fascinating because that means this should be the purpose of a good manager, but the danger with having that in people is that there's often managers that are not necessarily using the power that they're deriving from that position in the system to support the system, but sometimes they'll divert too much energy towards themselves. And so one of the things I'm fascinated with is how organizations... So in the past, the most powerful enabling constraints we had in organizations, or some of the most powerful enabling constraints we had were managers, but maybe there's new forms of enabling constraints that we can create now in organizations, using technology. They don't necessarily want to divert energy towards themselves, although maybe they do.
Alicia:
I'll make a philosophical distinction in political philosophy. There's a distinction between power and authority. Power is raw power. That's almost Newtonian, and that's almost like pushing something, someone. Authority in political philosophy is rightful use of power. So there's a normative, there's a value component to authority. I would say that the manager that is misusing the power probably very quickly loses authority. In other words, people may think they have no choice but to follow him, but they don't respect him, and so on and so forth. I think some of the value of these evaluating feedback in Amazon and so on, the consumer evaluation, is a diversion of authority from the officialdom to perhaps the actual consumers of that product. And if you've got 97,000 who say, 'This is good, give it four stars.' You assume that's kind of hard to finagle as a fake. If you've got four people, then it's the four cousins of the person who selling that product. But if not, then Amazon had better not recommend a product that they have a vested interest in because it's one of their Amazon basics or whatever, if it's an inferior product, because they will quickly be exposed. That assumes however that the channel of information remains open and available. Part of the problem with the algorithms is, that as it iterates, well, more strident ones tend to go to the top rather than the more responsible but less strident. And so the problem starts turning into the stridency of the advocacy. I think companies have always had this problem. There's always a person who sits in the corner that nobody ever pays attention to, but is really someone who really knows the business gets things done and so on. And we've never been quite able to manage that problem. And the flashy self-promoting person tends to get the promotion to begin with. And so that it starts, how did that person get to be the manager to begin with? And it's hard, you know, what kind of feedback loops could be instituted to highlight and emphasize authoritarian voices. And I don't mean authoritarian in the dictatorship, I mean, as in someone who speaks with authority, speaks with gravitas or with "who knows what they're talking about" kind of authority.
Marc:
So that is, that is a core problem that we start to articulate in management. So the way I make the distinction in management is, In general, there's always this talk about leadership, but it ignores the fact that there is leadership. Edgar Shine articulates this–I think in "Humble inquiry", but it could be elsewhere–that leadership is contextual and emerges from a situation. Versus what I, so following also your political philosophy distinction, authority, which is due to the person through the structure of the system. So they have a position, and because they're in this position within the organization, they have authority to make decisions, and popular business advice it's all about the characteristics or the charisma we could say of the leader, and it ignores that actually, executing authority as given through your position is a completely different set of skills. So having charisma and inspiring people to do certain things is one set of skills, actually being able to make the decisions that you are appointed to make because of your position in the network is a completely different set of skills. We don't distinguish the English one for the other way, especially because if you wanna sell yourself as a consultant or courses, et cetera, it's much easier to serve the ego of people and say, 'Hey, you have leadership characteristics and charisma, and we'll teach you.' Or, 'Even if you lack of, we can teach you how to have it, because we all want to be like, influential just by our personality.' And there seems to be very little appetite of actually really doing the hard work of starting to understand what are the skills that are attached to executing authority.
This is also why I'm still deeply skeptical. That technology is yet anywhere suitable to be employed instead of managers. This is something we might get at some point too, but practice theory has taught us that actually any kind of material tool is a form of materialized practice, which means before we can create a material form of management, we actually have to fully understand what these competencies are that an authoritative position attaches. And since we don't, I don't think management can be automated yet. And the danger of automating the leadership thing is that it removes the context. Because that's the other weakness of automation, is that it actually does not, it's not capable of adapting to changes in the context. Automation only works as long as the context remains, stays the same.
Alicia:
Correct. Great. And that's what human beings presumably are good at, noticing patterns that might have changed somewhat. Sometime.
Marc:
Hopefully. So social systems per se are, I believe they have evolved because they have higher adaptability to change as a context. So you would expect that also a healthy social system, which is a workforce with managers, experts, et cetera, so a sign of a healthy workforce is that they notice and are able to reflect on changes in context, whereas an unhealthy workforce is sort of still following some idealized version of the context that some leader, mostly a exec or so has put out and never questions whether that vision or that view of reality is actually still applicable or whether the reality actually has changed.
Alicia:
I think the attraction of that idealized notion, is part of the baggage we have inherited from the scientific enlightenment, that there are ideal prescriptions that apply everywhere at all times, and at all places, and these are eternal verities. And part of that comes from the idea that we think human beings have a nature, 'Oh that's just human nature, so that's an unchanging eternal, essential trait. And so that there's no need to worry about context because nature will always let out.' I think the more we start emphasizing the role of context in literally changing the entities caught up in that context. I think young people are so into ecology that maybe there's some hope that that appreciation of ecological problems, which are all contextual, will translate into an appreciation for context elsewhere in business, in society and family relations, and so on.
Kristof:
You would almost say, I was just thinking that maybe complexity should really be called contextity.
Alicia:
Yeah. I like that. Many variables interacting, becoming interdependent, and that interdependent becomes a context that each of these respond to and is caught up in, it seems to me. I can't teach this without doing this. Yeah. I don't know how to do it otherwise but in this way.
Kristof:
You're weaving your fingers together, for the listeners. I think that we had a question prepared around tools, because in the IT world, we're really in love with tools. And there's this idea, that you get a mission, you need to buy a tool to do X, Y, Z. And the analyst says like, 'Well, this is the category. These are the best tools, you know, go out and buy the best tool, buy the best of breed.' But in a complex, in a "contextity," that doesn't make necessarily sense. What are the things that people should pay attention to, to cater to the interdepencies of systems, where would you get? So if you would send somebody, 'Go buy me a tool to do X, Y, Z,' how would you structure that to make sure that they're not just blindly buying the best tool based on somebody's opinion?
Alicia:
I think before I told them, 'Go buy this tool,' I'd say, 'Show me what you're going to use it for, show me what the conditions are, show me what you can and cannot do with those tools, how much you can afford to pay or not.' In other words, show me the context first, and then you fit the tool to the context, rather than trying to define the context abstractly, which is sort of another kind of idealization. I think fittingness of tool to purpose is probably the more important of the issues involved.
Kristof:
And I think a really important aspect then is also, 'What are the competencies that your team has?'
Alicia:
Yeah, that's true.
Kristof:
And how are they going to be interacting with those? We've seen this sometimes with our customers also that are like, 'Okay, so we've bought an API management solution. Now we need a developer portal.' –This is the thing that we sell.– But then when you start asking, 'Do you have any technical writing happening?' 'No, we don't have any of that.' Really quickly it appears that 'Well, you will not be successful if you don't do these things.' And I think that's really important. Tools are not enough, they're just a start.
Alicia:
We had that problem. You asked me earlier about the technology side of what I do. We knew for example, that in order to stop vector-borne diseases like mosquito borne diseases like dengue or Zika or malaria, and so on, those really get contained locally, because those are the folks who need to find out, 'Oh, we've got a small outbreak here and we can contain it right here, stop it right here.' And it will have prevented from becoming epidemic. But the problem is there's a contradiction because those very local context-dependent conditions, the folks in a little county in rural Texas or Alabama in the United States–or, you know, use the example you wish elsewhere in the world–they don't have the statistical skills to add to the statistical packages to the software, or they don't have mapping skills to add to the mapping to the software. They have to be empowered to be able to use the tool through good design. And I guess that's why people like Jabe would come into the picture. Good design would be what is the lowest level of skill set that would allow this tool to be used? And the way we started thinking about it was, well, most folks, even in rural conditions nowadays can use a smartphone. And so they know how to click and press, so that's about the level, but don't ask for somebody to do the statistical software. The converse of that is those folks don't have the resources to purchase your tool that has all those capabilities. So it's a very difficult balancing act. Because the CDC and NIH and all these folks who deal with the World Health Organization, they're dealing with things at the thirty-thousand foot level, but a lot of their recommendations and a lot of their suggestions have to get implemented at the really, really local level. And those folks can't adapt those tools. And I think I'm trying to give an example that's similar to yours. They can't adapt those tools to be used at this local level. Very difficult for them.
Kristof:
And this connects also to one of the stories that fascinated me, that's your company Factor Analytica. You are in a competition against really well funded companies that had spent lots and lots of money to build amazing machines to basically analyze where a next pandemic would hit, or where there would be problems with factor born diseases. And that's actually in the competition, you came out actually with the system that was not as heavyweight.
Alicia:
And I think, again, this had to do with my exposure to the Cuban situation. One of the folks in that competition was representing a CDC outpost in Iquitos, Peru at the source of the Amazon. Look, there are not that many supercomputers in Iquitos, Peru. Zero. And it does no good to tell them, 'Look, we're gonna run this model that takes two weeks to run, that has all the bells and whistles in the world.' But two weeks later–mosquitoes don't even live for two weeks–so by the time the computer came back, the data sources were not there anymore. And so we understood that this needed, you know, maybe it doesn't have to be as precise as the supercomputer would get it, but it's gotta be good enough to solve the problem for the person on the ground right now. That's what's more important. And it was just a shock to me that anybody at those universities would even try. I mean, because really what they had in mind was 'I'm gonna publish a paper.' Not, 'I'm gonna solve this person's problem.' Here's another example: the state department invited me to go to a tech camp in Bogota, where they were really trying to help empower people with technology and throughout all of Latin America. Well, I took advantage–I was in Bogota–to go visit the, and I'll mention the name, Instituto Santa Fe De Bogota, which is a very, very respectable epidemiological research center in Bogota. And they told me that they had had an experience. And here, I won't give you the name of the same thing. A fancy, very, very powerful, very, respectable and well known university in the United States that had given them this fabulous software tool for them to do what my company Vector Analytica was supposed to do, which is monitor and track the presence of vector's in mosquitoes or ticks or whatever. But you know what, as soon as that software, left on a cell phone out in the jungle, no connectivity, the thing wouldn't work. You know, the American developer never thought that there might be a situation where there was no connectivity. So that's the context dependence and the context awareness that I think complexity forces you to be aware of. And so we said, 'Oh no, no. Ours is great because all you do is you download the map of where you're going while you're still in the office. And then you go out there and you still have all the trails and you still have all the detail, but you can upload data and save it on the phone. And then when you get back, you you can upload it to the cloud servers. No problem.' And they, why would a university... They gave them this–in fact, I don't remember if they gave them the software or they charged them for 'em. Okay. But they might have even charged them for 'em, or they charged the state department, and it's like a brick they had, they could use for nothing. It was, that's an example.
Kristof:
The previous example was an example of complexity and how understanding complexity can also help in business context. Do you have other examples of applying complexity that helped you to run a better business? Because you're not only a philosopher, you're also a business team.
Alicia:
I'm not sure it's that efficient of a business. It started more as a project among a bunch of academics and, and it ended up as a business, but I'll give you an example. And that is, the whole notion of managers as catalysts was a big learning tool there because these are all professionals and they all know what they're doing. And so thinking you can tell people what to do is, was easy to learn. But also, for example, in, since these folks are developers and they're writing software, the idea–and it was being funded initially by family and friends–the idea of spending time and money and resources to document with a documentation of the software. Well, I quickly learned that that is very important and for a whole bunch of reasons, because if that particular developer leaves, and it's a form of maintaining a distributed form of control and transparency that I learned to my chagrin, I should have known that a little bit better. One more example, and that was throughout Latin America, I was told, 'Oh, but you know, we have, we have records of mosquitoes and clinical cases of dengue, for example, going back to the beginning of the 20th century. But they're all... Oh, we finally, with a lot of trouble transferred them into Excel files. Isn't there anything you can do about it?' Well, if you're gonna have a cell phone that can work in the Amazon, you might as well then integrate another data base. And that is all the information you have from those Excel archival data. So you're taking the temporal context into account, and if nothing else, it gives you a Basian prior baseline on which to then look and see whether the new data you're getting is completely different or why or not, it gives you a sense of a historical trajectory in a particular location. So that was useful to us as well.
Kristof:
You said something interesting about, documentation: would you–because you know, documentation in APIs is super important–would you say the documentation is enabling constraint?
Alicia:
Um, no, I think I'd say initially it's a governing or constituent constraint because once it's documented, then those are the constraints that pull the software together, right? It stabilizes, but that said, it enables the next step. In a sense, it enables the next stage. Once you know how much this can give you and get you. I would say that it would show me if this software was built in a way that I could add onto it and grow it, or if it stabilizes it in a way that it really freezes it. And so that's exactly what you don't want, because you don't want to be so stable. That again, it becomes the perfect fitness. And so it has no evolvability, it cannot then handle a new situation. That's why, for example, we tried to do–and we were very pleased when we did our software–but all of a sudden Zika, remember the horrible stories years ago with the children, with the horrible situation, you wanna make sure you can incorporate new fields, new databases, new variables. And for that APIs have been a godsend. Another thing that we were able to use APIs with that we were able to bring into was census data, the entire census data of the United States going back forever is available now with an API, you can just plug into your system. And it's unbelievable how that gives you information about, for example, one thing we learned, we were doing some work for about presence of rats and rodents in Minneapolis, and it was amazing that it correlated very nicely with the age of the physical structure of the area. Meaning if you had very old brick buildings, the mortar between the buildings crumbled, and that's the way the rats were getting into the building. And it was, we only were able to see that once we superimposed the API of the census data with the API of the reports of rodent infestation, that whoops it all of a sudden... See, that's what I mean by those are emergent characteristics. The combination ends up being more than the sum of the two separately, and that was very useful to us.
Marc:
Just to reiterate on this point, that documentation is initially at least a governing constraint. Your experience might be different and more relevant, but my experience in the past was also, as soon as you start introducing documentation to your software, developers also are aware, 'Oh, we've now written down these rules that the software adheres to.' So how they change the software becomes a bit more constrained. So you have the documentation, you don't wanna go and have to change it. So you're making sure that whatever you change it to still adheres to the rules. So it has a real stabilizing effect. But then the interesting point is having actually documented software that is stabilizing then allows higher order systems to start building upon. So this is a core principle of complexity that once you stabilize interaction at a certain level, then that enables in a sense new interactions to happen at a higher order system. That's exactly what you want with APIs.
Kristof:
One of the mindbends for me was that an API actually is really a contract. It's an evolving contract between two parties, that if I'm going to send you a request in this format, you're gonna send me information in this format. And it is also an adaptation dance. The most successful API programs that I've heard of, they are actually listening to their consumers. Like, imagine that. But, actually this is kind of novel. There's a lot of teams that just build stuff. But really good APIs they're basically creating this collaborative design documentation about how they're going to interact with each other. That's basically the whole thing, which is well, super fascinating.
Alicia:
Well, and it applies to the title of your podcast, API resilience. It's not just API stability, resilience, meaning it can evolve. It doesn't just adapt to the current conditions, but it can involve if things change in the future or the conditions, the context changes completely in the future. Absolutely.
Kristof:
The "Dynamics in action" is kind of like this insider secret sauce. I hear more and more, I hear people talking about it and also I just did a course with Ruth Malan, from the Bredemeyer Consulting. I was talking about constraints and like, 'Oh, you, you mean like in Alicia Juarrero's book, "Dynamics in action"?' 'Yeah, actually yes.'
Alicia:
Well, very nice.
Kristof:
Is there something that you wanna highlight still out of that book?
Alicia:
No, I think what I was trying to do was use this notion of complex systems and particular causation in explaining intentional action, which philosophers have used mechanical models to explain forever. And they still, they continue to do that. What I'm trying to do in the next book that I'm calling "Context changes everything", is to expand that notion of constraint to include examples. I used the prairie grassland exhibit. I use lasers, I use the homeostasis. There are examples about, atmospheric dynamics in the Earth that seem to have remained stable for eons even before oxygen. So it cannot be natural selection only because there was no life back then and yet there are certain levels of study. So the question is, are there forms of dynamic equilibrium that cross the abiotic non-living to the biotic living realm and then hopefully to the psychological and sociological cultural aspects that one can find analogies. I'm not saying exactly the same pattern, but similarities in the way enabling constraints put together new coherence, which then became stabilized, which became became then the basis on which novel forms of constraint built the next labor level, such as chemistry from physics and then biology and so on. That's what I'm trying to do. I worry that I might bite off way more than I can chew because my background is philosophy. My knowledge of science is very, very weak.
Kristof:
But for storytelling, you don't necessarily need to have the hard details. I've talked about this with Marc that it feels like the universe is a fractal model. So like whenever you zoom in somewhere and there's the same kind of things just slightly different, but it's the same kind of models that you see interacting and playing out new things.
Alicia:
Maybe especially the same types of constraints, like some constraints that take a system away from equilibrium, like gradients, like fields that take systems away from, from equity-probability. Those are, you know, a gradient makes a state space, everything's not equally probable throughout the space. And then what I call context dependent constraints of which enabling constraints are one variety. And those are the ones that link together and make one conditionally probable on another. So they all of a sudden get linked probabilistically. So given that this has happened, this is more likely to happen. Or given that this is the case, this won't happen at all. Those are context dependent constraints that then start creating a rugged landscape, meaning some things become more probable under in these boundaries, other things become less probable in these boundaries. So I've tried to apply that throughout the cosmos, from the abiotic, through the living, through living things, into the social system. At least to suggest that this is a one way of looking at things.
Kristof:
I've been thinking in this direction, with currency systems. So there's biological currency systems with ADP and ADP. We have currency in our society now. So you see these things coming back, but in different places. Is that also something you're looking at?
Alicia:
I would say that that currency is a channel that facilitates flows of energy stocks, information. And so, we use the word currency metaphorically to talk about channels of information. But we also use it to talk about channels of energy, be it chemical energy or electrical energy, current or biological metabolic energy. I think currencies are forms of enabling constraints, right? They also store value, they store constraints, which is also interesting. I woke up this morning and opened the paper and said, every currency in the world has gone down yesterday except for the US dollar. So then that ha must have something to do with the fed decision yesterday to raise interest rates. So it's contextual, it's not that there's anything magical about the United it's that it's tied to the decision of the federal, so it's conditional upon the situation with the federals at the moment. So absolutely, I think currencies are a beautiful example of flows of energy, channeled flows, a very good example of a governing constraint, the human vascular cure system, the lymph nodes or the blood flow. They do not transfer energy at all. The actual vessels, the veins and the arteries do not transfer, do not push. They're not the hearth, that is a pump that pushes like the cue-stick would push the cue-ball. They are the channels that organize and channel and make it easier for energy to flow–blood, lymph–in an aligned fashion. Otherwise it would dissipate in a very disorganized way throughout the system. Yet sometimes when you get to the alvioli in the lungs, you know, you need that dissipation or the capillaries, the channels themselves are not enough to fill in the state space, the way you need to.
Kristof:
Do you think there's like a vocabulary of model patterns that's universal?
Alicia:
Adrian Bejan thinks that. He thinks that there are patterns of energy flow. And he gives an example like river basins, exactly. In the vasculature system. If you look at lightning strikes, it kind of looks similar, you've got the first down, then it sort of spreads out. And so apparently those patterns maximize energy flow fill in, or exploit the state space better than without the pattern.
Kristof:
But it feels that there's certain constructors for models that nature is reusing and recombining in different ways. And that sets of constraints but always in a different incarnation. For example, the currency system in mitochondria, it's amazing, it's just mind boggling. And I'm wondering if we could define that language of models of complexity or patterns of complexity. If you would be able to have a different vocabulary to do business with also, where we can say, 'I can use, you know, I can use this here and so on.'
Alicia:
I worry sometimes as a philosopher that I will be seen by physicists and hard scientists as 'Oh, you know, at this point, the philosopher went nuts.' I suspect that if there are such patterns, it has to all bottom out in thermodynamics. That they all have to be compatible with and satisfying the second law of thermodynamics at the very least. So whether it is ATP energy flow or electrical or bio, or nutrients or whatever it has, the pattern must facilitate energy flow better than not having that pattern. And some patterns may be better than others if facilitating energy flow. So over time you get even abiotic selection of the more efficient, effective thermodynamic patterns throughout the cosmos, which is why you get spirals of galaxies, which is why you get, you know, that, that sort of thing. I suspect, I have no idea.
Marc:
What you asked for was universal patterns and sort of a pattern library. And I just wanna remind you that this is still actually back to Aristotle-types of philosophy. So I think what we get from Alicia's book is a language in which we can start articulating some of these concepts in a different way. But as her new book title says "Context changes everything": if we want to get to the universal level speak, second law of thermodynamics, the explanatory power in our context will be banal, trivial, not very useful. So if we want to be useful...? So also having seen some of that book, what is really interesting is how the language actually starts to allow us which context can we compare? So absolutely, we can learn from different domains about what might be suitable for new domains that we're exploring, but only in terms of where we're capable of saying, what are the commonalities between these contexts? And what we so totally need to get away from is finding this single answer. You know, like the one law that underlies the physics of the universe, et cetera, because I think that has been the fallacy of physics that it said in the end, we need to find a single law. We might one day find it, but it won't help us with any of our current problems, will not help us inventing new things that are good for everybody.
Alicia:
I call for effective science. Instead of in philosophy and in natural science, if it isn't underwritten by universal laws, it isn't considered science, which is why for so many natural scientists, they consider the social sciences, psychology economics, non sciences, because they're not underwritten by universal laws, but I think it was Herbert Simon who also called for effective laws. And that is laws within this context. And so then the question is 'What kind of laws might apply given this context?' And then the next step is what Marc says would be the comparison between context and what might fall under this general context that we might not think about before. For example, human beings are dissipated structures in the same way that a tornado and a hurricane is a dissipated structure. Who would've put those three entities in the same category. Well, because we found the context in which certain conditions far from equilibrium, context dependent constraints, self-organized boundary conditions... And so if you specify the details–the devil's in the details–of the context, then some very interesting anomalies or novelties might pop up that you hadn't expected before.
Kristof:
And it's the human condition, the need to categorize things, because that's how we think. And, but, or at least I think that's how we think, but...
Marc:
I would, actually like, I disagree.
Marc:
Daniel Kahneman has actually already explained to us that there's two ways we think, at least, although I just think these are extremes of a spectrum of a gradient, but categorization helps us save energy when we're trying to think. But we're quite capable sometimes to think about things without falling into categories.
Kristof:
It's this fascination with, 'I recognize this,' or, you know, you're in a completely different scale of the universe and suddenly like, 'Oh, this is just like this other thing that I saw very, very differently.' It's different. It's not the same. It's really a fractal. It's just, it's contextualized. And, and it's doing slightly different things, but still it's familiar with something else that you've seen at another scale. And, and this is the, this is so wondrous I feel. And I think that's also where there's a lot of inspiration for everybody of us. Like, no matter what domain you're exploring and you're looking for, I believe, and that's what fascinates me in complexity. 'Can I look at a biological system and can I use whatever I've learned there as inspiration to find something new in a business system?' Can I look at physics and well, maybe not physics, but you know what, even physics, even physics.
Alicia:
N. Katherine Hayles who wrote a book on metaphors, compares a metaphor to an old fashioned compass. And I really like that metaphor for a metaphor. She says one leg of the compass is fixed, but the other one is allowed to roam free. And I really like that view of how we think of a metaphor, 'cause a metaphor is not totally unmoored. There is one leg of a metaphor that probably is grounded in something that remains the same. And the other one is allowed to roam free.
Kristof:
Thank you.
Alicia:
This was fun. This was a lot of fun. Thank you very much.
Marc:
Good point on the meta-metaphor.
End of part 2 of the episode we recorded with Professor Alicia Juarrero. You may also wish to listen to part 1.
