If you've ever wondered how APIs change organizations, our communities and our society, look no further, this is the podcast you've been searching for.
How we transform organizations is a complex problem. We need to explain emergence, and create the conditions that makes it much more likely for certain things to happen. Thinking that you can just import somebody else's model is, from a complexity perspective, fraught with difficulties that are hard to anticipate.
Discover together with us how APIs can help organizations to become more deliberate about their inherent complexity. Expect deep conversations with really smart guests, and discussions covering technological, sociological, and philosophical topics in the field of APIs, Platforms, Ecosystems, and complexity in general.
Hosts are Kristof Van Tomme (CEO & Co-founder, Pronovix), and Marc Burgauer (Principal Consultant and Co-founder at Contextualise).
Intro music: Night Owl by Broke For Free, CC-BY
[Kristof] Welcome back to the API Resilience podcast, this is Kristof Van Tomme, CEO of Pronovix and API Resilience co-host, and I'm super excited today because we are finally launching our deliberate complexity series! Behind the scenes I've been working for over half a year together with my new co-host Marc Burgauer, to explore the connections between APIs and complex adaptive systems. Basically Marc brought me up to speed on a number of topics in the complexity world, there was a lot to learn, and there is still a lot to learn... But now we're ready to take our next step. So I would like to invite you, the API community, and our guests, on a deep-dive into complexity science, and to work out how APIs can help organizations to become more deliberate about their inherent complexity. What to expect? Expect deep conversations with really smart guests, and discussions covering technological, sociological, and philosophical topics in the field of APIs, Platforms, Ecosystems, and complexity in general. If you've ever wondered what it really is we do when we do APIs, and if you've wondered how APIs change organizations, our communities and our society, look no further, this is the podcast you've been searching for. I hope you'll enjoy this introductory episode, and that you'll tune in also in the coming weeks to discover together with us how deliberate complexity, social practice theory and a deeper understanding of socio-technical systems can transform our organizations and even the world we live in.
Can you maybe do a quick introduction? Like what's your background? How I, well, I can tell the story about how I found you a little bit later. Maybe can you give a little bit of an introduction of what your profession is and how you're connected to the technology world in complexity?
[Marc] Okay. So I'm currently working most of my time as a lean agile coach. In the other part of the time, I'm trying to develop a business based on social practice theory, which I would expect we will get to at 1.1 episode of the podcast. What does a lean agile coach have to do with complexity? I studied biology and was especially interested in the philosophy of science, that got me really going. And I dug around in this a bit and came across the early proponents of complexity theory, Ilya Prigogine who won the Nobel prize for figuring something out that we call now, autopoiesis, which is how systems actually become self replicating and maintaining. So really was interesting, but for various reasons that never materialized in a job. So I grew up in Switzerland and as a biologist, almost all job prospects meant you have to go and work in a laboratory of a pharmaceutical.
And I didn't fancy that. So while I was sort of waiting around for something good to come along, that I could apply my biology with, I basically got into computers as many of us did, just curiosity in the first place and then, oh, you can make money with this. Okay. Let's do some jobs and just did some computer jobs. And there's another side track I got could with for a few years, maybe also get into it some other place, but essentially I ended up having, having a career programming. Then somewhere in the early mid-nineties I met my wife. She's from Scotland, so then we relocate. We started at a company doing early internet software. So it was roughly so we founded a company in, I think 1997 or 1998. But really started to take off just around the year two, 2000 2001.
And we looked at ways how, how we could grow the company. So what kind of management system, et cetera, we wanted to do. And so one of my complexity pals–I kept in touch with what was happening in the complexity world, kept reading, kept talking to some of people I knew from university– showed me the thing about agile development. And it does actually fit into the complex to thinking in some ways, even though in the guise that you mostly see [agile] proposed today, you wouldn't, you wouldn't think so. So at first it was just like, yeah, that seemed to be the right thing. And it worked for us very well. So we basically ran our company following extreme programming principles which led us to things that we now call product teams and DevOps, et cetera, almost organically just being small and just looking at problems and what would be a possible experiment and how do you solve that?
And like, oh yeah, let's add a sys-op to developer teams. Let's add somebody who understands user interactions to the development team, et cetera. And this worked really quite well, was very surprising. I wasn't aware that there was something like an agile movement. I literally thought, yeah, this is something that some people in the States figured out. It took me about, I don't know, 15 years or so until I actually figured out, 'Oh, there's other people in Scotland who like agile.' But after that,... so as I told Kristof, one of the reasons we stopped the company was the emergence of Drupal. So essentially we did lots of things that suddenly became a commodity based on Drupal. And rather than trying to, you know keep the business going around these kind of things, my wife and I both actually said, 'Well, I want to do other things.'
So I switched and did technical project management for the NHS in Scotland–that's the National Health Service–in a large transformation project, which we would now call a digital transformation. It wasn't called that at the time, but essentially was impacting GPs and pharmacists and lots of it and lots of people, et cetera. And again, I was actually faced with complexity problems. And again, the complexity thinking was sort of helpful, but still didn't come to the forward. So at the end of that, I was basically convinced by a friend of mine to go full-time into agile coaching. And just as a let's go and blow the cobwebs out of my brain. I went to a conference in the States where one of the leading complexity philosophers just happened to do the keynote. Just got chatting with her and that sort of reactivated the whole complexity knowledge that I had and catered for years just as a hobby into a professional setting. So ever since–so that's been five or six years ago–I have actually deliberately tried to understand organizations and how we change organizations primarily from an IT perspective, cause that is a domain in which I still have some competence, but increasingly overall, also for management executives, et cetera, from a complexity perspective, how do we change organizations is a complex problem.
[Kristof] I had no idea that the rabbit hole went this deep. I didn't know that it was complexity that brought you to agile.
[Marc] It made me receptible to agile. So I was brought in by somebody literally saying, 'Hey, look at this site, you start a company. There might be some good ideas for you.'
[Kristof] That's fascinating. Well, my approach to complexity, my first kind of initiation was at university where we had a course about systems thinking and, and well not systems thinking it was about system management and like how to keep things stable. Like how do you keep a bioreactor stable? And it was super, super interesting and way too complicated it, and didn't make much sense to anybody, but still it was this where, 'Oh, there's something really, really exciting and interesting here. I don't fully understand it, but there's some deeper truth,' but then yeah, like along my career, sometimes something would pop up, but it was never the full driver. But it's interesting that for you it was such an an early influence. But when you say complexity, because I think we've got a bunch of guests listening who, who might think when they hear complexity who might think about complexity and software, which is generally something you don't really want. Can you maybe give a short explanation of what you mean when you say complexity from your perspective? What is it actually?
[Marc] Primarily complexity thinking is just a different way of looking at things. We could call it a lens, in a scientific sense. There is already a wide spectrum of opinions about how to understand complexity, but what we mean principally is that if you look at the world through the mechanistic lens of Newton or Galilei, or even Einstein or quantum theory, then it is all about causality: can we determine how things happen by looking at the causes of the things. And there is a linear connection. Quantum mechanics already obliterated that to a certain extent, but talking about probabilities is just a workaround. They're still a primarily mechanistic view that things are causally connected.
The problem with this kind of worldview is that it doesn't explain emergence. It has no way of actually explaining how novelty comes into the world. How do new things happen that weren't there before? So in a simple sense, complexity is an approach to think about how the world works, that tries to explain things such as emergence. We could just look at the history of the universe: novelty happens all the time. We can only explain it backwards, but we can't explain it forward, so to speak. So what I mean by we can explain it backwards is, oh, we, we, we can look at, we can say there's a big bang. And initially there's just energy. And then some, some particles maybe first strings or then particles emerge and then particles build bigger particles.
And then they build atoms and then atoms interact and create molecules and molecules interact. And they start to create organisms and organisms interacts and they start to create ecosystems. And so we see in ratcheting up of a thing that we call complexity. So that's what we mean by complexity. It's like, it becomes more and more complex. And so that's what I mean, so we can look backwards. And so in hindsight, we have an explanation how that might have come about, but that explanation is really poor in actually predicting anything going forward. Our ability to predict is still terribly limited. I mean, go read science fiction and see how many things that science fiction. You, you read it at the time and you think, yeah, that is plausible and that's often an issue. So we just, because we, we imagine it doesn't mean it's possible. Just because, because we don't have to imagine every detail of that future situation of future world.
Complexity thinking turns this whole around and says, there is complexity in the world and there is a propensity in the world for the complexity to increase. What does that say about the world and how do we need to look at the world? We use this perspective, at least this aspect of complexity science, that gives us some insight how we have to act in this world to make things possible. And so one of the things the complexity says is for example, you can't deterministically make emergence happen as in you can't make things happen that have sustainability in the world just by will.
But what you can do is you can create the conditions that makes it much more likely for certain things to happen. If you look at organizations, we're already trying this, a very simple example is teams. If you go back 30 years in organizational thinking, it was all individuals, individuals, the concept of team was actually still vague or fuzzy. Of course, people accepted that sometimes people worked in a project team or so, but largely we still saw the delivery of work as the product of interactions of individuals. And literally we wrote business process diagrams where I say, 'Here, this individual does this. And then this individual does that', and so forth. Then came this idea of teams, not only from software, you can also find it for example, in healthcare and other domains. We suddenly the focus on teams, and we're no longer that interested about what individuals do. And because we're no longer that focused on what individuals do, individuals amongst themselves in the team suddenly get the freedom. You make something more likely to explore other forms of organization. In the first agile teams there was no label, there was no goal. Nor was it 'Here are the tenants of agile that you need to try to implement.' They worked, they understood that they were a team, and they started to say, 'Okay, we are pushing the organizational interactions to the team level that allows us internally to go and try things and do things differently.' And they interpreted the team, not just as the people who wrote the software, but also the people who were using the software. 'Come and sit with me while I'm developing the software so we can bounce ideas backwards and forwards.' And so the very beginnings of agile fits complexity principles, it allows things to happen that otherwise would not happen. And so hence you find better forms of organization. And so by that means, I'm already pointing out that agile for me is just one step. It shouldn't be an end point anyway.
[Kristof] Even though it's not predictive, there are certain patterns that keep coming back from system to system. So like, because as, as you said that you, you can't really predict forward looking, you can kind of explain backward looking why certain, certain new things have emerged, but still there's certain patterns that you can start seeing emerging as we experience it. This is actually useful in the API space: we can actually do something to better understand what we're doing and how we can be more successful with APIs, and how we can get better outcomes instead of just blindly trying things and see what sticks to the wall.
This is where I started looking somewhere, I think it was last summer. Well, no, actually right when we started doing developer portals, I had been reading a book which afterwards turned out to be a little bit contentious but about a different way of looking at how, how biological systems work. And eventually it was Neither Ghost Nor Machine which was from a friend from Terrence Deacon, who, who made like a more readable version of Terrence Deacon's work. And that was incredibly fascinating because for me, it was kind of like this moment where I could knew it, it was kind of like inverting how you see the world, because now suddenly there's this whole lot of stuff that's complete. You can look at it like in two ways and it, and it makes things really interesting. Later I learned from you that there's another author, Alicia Juarrero, who had several of these ideas before Terrence Deacon, that was not referred to in his book. But but that was, that was kind of at the start of our developer portal journey. That I was, I was looking at this, but then I didn't know how to connect these two, but then last summer I started thinking about, okay, how can I connect? How can I really connect complexity into the API space? Because it, I kept seeing, so we, we built developer portals for customers, sometimes external facing sometimes internal facing. And then I, it felt like there was this gap in understanding of what, what is it actually that we're doing? Because people would do like, yeah, we're doing APIs. Okay. Why are you doing API? Well, API first it's, it's like a really good thing to do. Like, you know, and then people would start about AWS and, and stuff like that. But, but when it, it just felt like nobody really truly understood what the transformation was that we are triggering in our organizations. Then this is how I got onto Wardly mapping. And we'll talk about that another time, but that's how I also found you because you had you had a video up that's connected maturity mapping with Wardley mapping and that's ... and then we started talking and yeah, I think that that's kind of like the backgrounds, but I think the interesting thing is there's this tool set of models in complexity-world that it's, it's just thinking patterns that you can look at and like, see like, 'This is another one of those. This is a currency system. This is an ecosystem.' How have you applied this in your life? Besides, you know, the agile work that you did in your company? [Marc] As I said, so my understanding of complexity was nurtured through, through my perspective. So having studied biology and I got into this, so there's a book called The Self-Organizing Universe from Erich Jantsch, which he wrote very early on, I think, in the eighties or so on complexity sciences before it was a very prominent thing. And while he got a bit lost in the speculative part on what we're gonna do with this. The first part of the book is still an excellent entry. Sadly the book's no longer in print. So if you wanna buy it, you will have to find a used book and it could be fairly expensive. I would recommend they come up every now and then cheaper version. So put a Google alert out. And so so how do you apply this? Well, so as I said, you try, so because there is no history or for me, I didn't know there was a history because we could argue that a lot of the history of design starting with Simon Herbert, but I didn't know that at the time–sorry, Herbert Simon–does apply complexity theory already in some ways to organizations, but I wasn't aware of this.
A core tenant of complexity science is that you pay attention to interactions more–not at the exclusion, but more–than you pay attention to the individuals or entities. So you're less interested from a complexity perspective on how much skills and how much competence does have when you are hiring. The idea of higher talent is very reductionistic, it assumes we bring people in, they know all these things and then they're super productive. But how productive they are actually depends far more at how they interact with their coworkers. So complexity science focused on interactions over things. Alicia Jurrera expresses that along the lines of 'meaning exists or emerges from the interactions of things that doesn't exist in the things themselves.'
So agile appealed to me because it promoted collaboration, it promoted interaction. Events where you talk to one another and by having these dialogues or group discussions, you create your view and your understanding of the world that you're just about to build. When you build software, while you build products, so when you create something, you are putting things into the world that weren't there before. To bring things into the world successfully it is important that we talk to another.
So what appealed in agile to me is that it promoted conversations. For example a programmer might say, 'Okay, so this function, this feature that we try to add here to the service, I understand that this, so and so and so on.' Then the product person might say. ' But think about the user: what you ask from the user to do is thinking like a machine. But they're actually coming with an expectation.' - 'Oh, so what is the expectation?' You have these conversations and suddenly everybody has a richer world. The product person maybe have to adjust their view based on what's technically possible. So it's important to hear the developers', the engineers' view of the world as well. You need multiple perspectives. And so that's one of the things that appealed to me.
Another tenant of complexity says you can't make plans long in advance. By acting in the world, you're changing already how the world reacts. As soon as you start something, for example you put the piece of code to an environment, that environment has changed. And the more change you're making, the more things aren't anymore the way they were when you started your journey. You have to constantly readjust, 'Is the plan we're actually following still okay or has something happened that maybe we should reflect on change?' The plan was usually appealing because again, it, it, it adheres to complexity principles.
[Kristof] I think that you said something really interesting that there's multiple ways of looking at things for me, that's, that's one of the hearts. Well, one of the core truths in complexity thinking is that there's no single model. All the models are incorrect to some extent, and still they can be useful. You can look at the world through different lenses and at different levels of interconnectedness. Rather than trying to cut the world into pieces that are in isolation evaluated, you try to put little boundaries around certain parts so that you can look at it. While keeping in mind that there's a much bigger world out there and that nothing ever lives in isolation from the rest of the world. And that because of that, no single model ever can work because it's always much more complex than what we're looking at.
And So it's, and, but there's another aspect to that because so one thing is this multiplicity of looking at the world for me and that's a really important way of, of changing how, how I think, but then another one is this kind of like it's like a toolkit. A toolkit of models of different of different patterns that keep repeating themselves in the natural world and in, and in the socio-technical world that we're building and realizing, or like looking for similarities and then trying to make connections between things that that's also what fascinates me in here.
[Marc] So you started to talk about models. George Box says all models are wrong, but they might be useful. Let's modify this at the temporarily useful, but that's how we think. Keeping complexity in your mind at all time in all aspects is literally impossible. We have to focus our attention onto certain things and models help us do that. And we would, we are considering models successful that we apply and that help us as achieve outcomes that we want. So you could, you could say models are a way of making sense of the world. So how do we explain the world is through models? So models are that regard, not just important, they're just inevitable.
[Kristof] But at the same time, like the complexity viewpoints opens you up, it's kind of like mental power training where you are, it, it just keeps your, your mind flexible or it's kind of like mental stretching or something like, because you you're keeping reminded, oh yes. I might be thinking this way right now, but that's because I have this model and actually there's a much, much broader world out there that I am not seeing at this point, because I'm zoomed in at this level of abstraction or, and I mean, look, I'm looking at the world with this specific model. What other models can I look with and how does that change? How I think. And, and and it's that, that kind of that flexibility and yeah, adaptiveness that I think is, is an incredible gift that you can get from, from complexity viewpoint.
[Marc] So complexity forms a little bit, how you have to articulate your models and how you should not articulate your models. But that in itself, so we already have a tradition of constraints on, on models. Yes. So empiricism is, is I would say by now a well understood way of, of looking at models. You answered the, the guru of empiricism, Popper actually ended up advocating that if you have a model–sorry, he talks about theories, but theories are models. What you should try is actually invalidate your models. And so I think that still holds true complexity or no complexity. If you have a model, then you should actually constantly look to invalidate what is invalidating my model. am I seeing signs and, and the invalidation points you towards what you need to inspect and explore to expand, or even revolutionize the model that you're using.
Complexity theory takes a step, maybe a step further that it also sort of not just says all models are, are wrong and you will be invalidated, but also how should we constrain in which ways we're changing the model and in which ways will let models evolve. You always have the problem of the outside influence that you can't avoid. But we, we have learned nature has learned mechanisms of limiting outside influence. So I'm talking about membranes in that context. So nature invented membranes so that it can create inside conditions, which are more favorable to certain processes than the outside conditions are. And the main protects the inside from the outside equally then sometimes stuff happens on the inside that needs to be externalized to the outside as in, in terms of interaction. So you have organisms that need to eat and they need to replicate. And so they have to interact with the outside world, et cetera, but membranes then become a mediator. And so in that sense, you could also say models are mediators. You look at a model as in, it allows me to mediate, which inside and outside interactions for a while, I'm focusing on. So what's inside the model, how is the model exposed to the environment, et cetera. And so it helps us focus the attention, the, whether that's a successful approach of course depends on how good the model is. If the model is rubbish and we're doing things and it ends in disaster, but good models can be recognized by that they're actually helping mediating some of these influences and interactions.
[Kristof] So, and you just did the, the translation from using the model in a bio. Well, I'm smiling because this model of the membrane, there's at least three places. Now you just added a third, so there's the API that's sitting in between one organization and one team or an organization and the rest of the world, or the ecosystem that it's interacting with. There's the membrane in biology where it's mediating, or it's constraining the information and some of the substances that are flowing from inside of the cell to the rest of the organism or its environment. And now there's also the model as the mental membrane. Interesting.
[Marc] Yes, I have been advocating that we should look at APIs as an organizational membrane, especially well, so it depends where the API sit. So you have internal APIs, but that is encapsulating that part of the organization that is exposing interaction with the rest of the organization through APIs. So they have a membrane, where organization actually interacts with its marketplace through APIs. That's an organization membrane. I said that. So we already went through the hoops that we learned about the user experience part, how important they are, how we position and market and create our products to be successful with customers in the marketplace. And we need to find the equivalent for APIs.
[Kristof] But it's well, this is the whole constraint thing. The world's turned inside out for me then, but I don't want to open this topic up in this first episode because we should have a full episode on that part. Yes. but well, as you said, this I'm wondering because we are as human, we have the ability to switch models and to look at the world with multiple models at the same time.
[Marc] Because models are in inherently reductionistic, they reduce the world to certain interactions that we're are focusing on. You do need multiple models to, to counter that. And so diversity of models Is, especially where we create is very important. But I would argue that even in operational circumstance, you are creative. So it applies everywhere in an organization.
[Kristof] It also gets us to a requisite variety
[Marc] It's another complexity topic. Yes. That we probably should defer for later, because it's too big. But what you're alluding to, we talked about this before, so I'm just gonna turn the corner of this is, is complexity. And you could, you could, you could start with science. So science itself is, is obviously as a, as a fan of practice theory, I look at it as a practice, but science in its theoretical construct. So to speak as how is it different from how we pursued truth by religion or stuff in the past is, is something in it's it's opening up a space in which we can create theories and models. And so as such, you could say science is a metamodel and in equal terms, complexity is a metamodel In itself allows still everything to exist and everything to happen. So how do you apply it to what you want to do is by following certain principles, when you create models for what you try to do. And so I often say metamodel is, is how you need to think about complexity in the same way as meta practice Applies to science. So empiricism is a practice of science.
[Kristof] The thing is though, that as growing up, up in a scientific education as a bioengineer it never passed my mind that there would be multiple models that would be valid at the same time. It felt like we were on a journey of figuring our way out to the single model that explains everything. And, and it was about using empiricism and reductionism to like cut the world into pieces so that we can finally understand how it actually works. And there's like one way that it works. And one day we're gonna figure this all out. And that kind of, so complexity took that away. At the same time, first it was overwhelming. I was hoping that complexity was the model that would explain me how this works and that I would gain a better understanding of how the world works and some predictive power for emergence, at least. And then this realization dawns that actually, no. It took away things rather than adding things, complexity is not about necessarily predicting what is going to happen. It's about predicting what probably wouldn't happen. And that was...
[Marc] First. That's not exactly true. So good complexity science, but which I also give you now a perspective where you could spot bad complexity science. Good complexity science does articulate very concrete things about in what conditions things can emerge. What needs to be true in order for emergence to, to be possible to happen. It is not predictive as in build A, B, C, D, E, and F will emerge. But, and if you say complexity has taken something away, then it was obviously the belief that things are as, as clearly causally connected that they can be understood. There's still, there's still an open argument. At least I hope it's an open. It is now an open argument. Maybe not still is the, a wrong word. There is now an open argument where there is actually something like the objective world. So this is now gonna be just slightly philosophical, but bear with me. So you could start, you could start with the cave metaphor. That we're actually not capable of perceiving The Real World in an objective way. We see is like the shadow that the outside throws as the light comes into the cave entrance onto the world that we're looking at at the back of the cave. so perception is already tainted ums. What we mean by this. And I mean, our, our senses in which we are experienced the world are, are they, they were not built to give us an object, objective impression of the world they're optimized.
So to optimize us towards survival problems, simply speaking. And so the very purpose built, hence their bias to certain things. Like the things that would've given us food and shelter and stuff like that. And so they're ignorant to, or, or nearly ignorant to things that would have not helped us with food and shelter and stuff like that. So how we perceive the world is, is already subjective. And so still, so what science was hoping for a while was yeah, but there must be an objective truth out there. So how can we discover this? And there might still be an objective truth out there. So we don't know that. Or even though there is action, now, some science that hints that something like an objective truth, at least is not discoverable is not observable. Even if it exists even particles are biased.
So nothing in the universe can objectively perceive the truth, so to speak. So as soon as you've accepted that's the reality of things that we never actually going to be able to perceive and observe objective truths. So this is one aspect of complexities science, then you start to realize, 'Okay. So whether we believe our facts are just an app approximation to the truth.' So if we say, let's say second law to thermodynamics, basically that in nature, things go from order to disordered state. And continuously, and that that's an irreversible process. This is seen so many, many scientists who understand these kind of things that that's probably the last law of our current laws of the universe in physics that will fall. But we're pretty sure it will fall one day too. Because anything that we thought was true about the world sooner or later, somebody comes and say, eh, it's not quite like that. So, so for example, you could look at Einstein's formulas, just a correction to Newton's formula, but the implications this, his corrections had was a completely different world. So suddenly Newtonian world was obliterated.
[Kristof] And so you have this in physics and the world of particles. But for me, I came back to complexity because of because of business problems, because I was looking at this. What should an organization do with their API program? How should they structure it to be successful? And then, and what does that actually mean? And, and my hope was that I could find like a single model that would be the truth, 'Just do this one thing and you're gonna be grand.' And basically what complexity taught me was, 'No, it's all contextual. There's a whole bunch of truths out there, but you cannot just say this one model is gonna fix everything.' And that at the same time was like a sense of loss for me, because I was hoping that I was gonna be able to say to customers, 'Well, here's a good practice. Just do this one thing and you're gonna be good.'
[Marc] Hang on. Where your trajectory is going, you can't do the right thing for your customers. But of course you can.
[Kristof] Sure. But, it's more about how do you...
[Marc] So the problem you're playing to is the problem of one size fits all. Yes. And, and we love one size fits all. So, so we have the tendency, or we have the propensity as, as humans that we like recipes, but anybody who, who is cooking and looking up recipes already understands implicitly, or almost always without thinking that you actually have to contextualize the recipe. So somebody gives you a recipe. They will have made some assumptions that you have this kind of oven and this kind of pan and this kind of knife or access to these kind of ingredients. And in your context, not all of these will be true. Hardly ever you do a recipe where you just sit the out and say, yeah, I can do exactly what he says. Or you do exactly what they say. And then let's say you bake cake and you realize, oh, I did it exactly at the temperature they say, but this is overcooked. This is over baked now. So, ah, he might not have a, a, a fan oven. He might have just had a plain oven, the guy who wrote the recipe.
You constantly need to adjust. So that's what complexity science starts to tell you, that context matters more. And so the other issue with the one size fits all. So the first issue is it doesn't work because your context is always different, but the other, the other problem with that is that if you look at something as an API program, then there are actually many variant parts in it that have to correspond to each other in the right way to achieve the right outcome. And surely there can't be one model top down, you can apply that fits everything. So again, you need to think at the context. So each part of your API journey, how you interact with your users, how do you decide how to build the infrastructure? How do you organize the teams that build, maintain, support, and evolve these things, et cetera, need to be constantly reflected in terms of what's the context we are in.
How does the context look like where we're at? What does it allow? What does it not allow? We looked at digital transformation when, when this thing became a term and said, everybody has to become Google or, or everybody has to become, I don't know, Apple. Yes. And of course, almost all organization failed because their context was so different that they had no chance of becoming Google or Apple. First of all, like abundance of cash. So most people work in organizations that constantly cash strap. Be it either because they're not very profitable or because their shareholders have unrealistic expectations about dividends, you know, they say, Hey, the shareholder, the dividends weren't big enough, go apply the cost, cost, cost cutter. And immediately we have, we have austerity in the organization, no chance of becoming Google with all this lush abundance of resources and space and ideas. So picking the right model for your context is probably the most important thing to be successful or not. And thinking that you can just import somebody else's model from a complexity perspective is absolutely absurd. But of course, if you look, if you understand the world in Newtonian ways, then that's what you would expect because come on, it's also elegant and it describes the path of planets for millions of years.
[Kristof] So this insight of one size does not fit all and this understanding that there's different models and how to communicate about that and, how to deal with that. These are some of the things that we are going to be exploring with our guests in the next couple of episodes. And just, you know, figuring out like what, what are the models that people are using at what scales and and giving it like a complexity twist so that we can, we can draw better lessons from it. So without trying to create a single one size fits all model of like, this is the perfect API program, everybody should do it this way, that we can give you like a toolbox of, of different models that you can like start mission meshing together to create the perfect, well, maybe not the perfect, but the adaptive system for your organization.
I'm very happy to have you Marc as my co-host, thank you very much.