Guest: Michele Sollecito, Engineering Manager
In this event, we’ll dive deep into system thinking and how it applies to product engineering. We’ll explore how viewing products as interconnected systems can help engineers build more robust, scalable, and user-friendly solutions. We’ll talk also about teamwork dynamics and how cross-functional collaboration creates emergent properties that individual contributors can’t achieve alone.
Michele’ LinkedIn: https://www.linkedin.com/in/michelesollecito/
Full Transcript
Unknown
Okay. Yeah. Welcome everybody to the second meetup of the Produt Engineering community. Today we have two special guests. So we have Michele Solagito, who is working as an engineering manager for Meta. He has around 15 years of experience between management and zone work and software architecture. And yeah, he has a lot of knowledge about system thinking. So we’re looking forward to hear more about that from him. And then we have Luis Rodriguez, who works as a poet engineer at New Store. All right. So first of all, before getting into it, I’d like to ask to whoever is listening, what is in your opinion system thinking in one sentence? Just write it in the chat. I’ll give you a few seconds. So Martin says thinking model of seeing the whole rather than the parts. Okay. If you come up with something, I’ll write it later. So yeah, that’s probably one of the ways to saying it. And question now to the guests. So have you ever encountered a situation where a small change created like a ripple effect, you know, that kind of creates some big change, a bit like, you know, the famous butterfly effect. When I hear a system thinking, I think about the butterfly effect. Have you ever in your experience that as that ever happened, do you have any any story to share about it? I don’t know, if you want to start. I mean, I mean, first of all, thanks for having me in pleasure seeing you guys again. And I mean, yeah, it is a topic that I really like talking about where I’m an expert on all the different story. And, and yeah, I like Martin’s definition, right? It’s essentially like system thinking to me. It’s a little bit like a lens where it kind of like begs you to look at certain things in a different way. And in terms of like, I don’t know, experiences where it change or small change perhaps like ends up creating rippling effects all over a system. Well, there’s plenty of them, right? In general, in a lot of cases, you see companies, especially large companies, where they end up trying to focus on improving the parts. And then because of this effort is a little bit anti systemic. What tends to happen is that they obtain, you know, perhaps not the outcomes that we’re hoping for. And things get worse, right? So I don’t know, I mean, there’s millions of examples. The classic one is when you focus on measuring productivity, perhaps by counting lines of codes or number of peers. And then like fast forward a year or two and you see that the entire culture of the company change and people behave differently. Because fundamentally you create an incentive for them to do so. This doesn’t introduce better productivity if anything gets things worse, right? I don’t know if maybe Luis you go like counterexample or something. How many hours do we have? I mean, there’s so many. The creation of this perverse incentives. I mean, it can go either way. You can have a small change that has positive effect on this system or systems, because even systems are interconnected. I would just add something to what Martin wrote. Seeing the whole rather than the parts is important, but I think one important differentiation of what makes a system a system is that the parts are interconnected in a meaningful way. So you can look at the whole pile of sand, but it’s just that it’s a pile of sand. It’s not necessarily a system. And each grain of sand is component, but it’s not necessarily something that’s influential across the rest of the system, where making exchange there will not necessarily propagate and so on. It could propagate, you know, you could create an avalanche down a mountain with snow or something like that, but it all depends on the function and the relationships between the elements that are part of the system. And then the afterwards relationships to higher hierarchies of systems that you could have. And this is why this systems and subsystems are all interconnected that you have this butterfly effects that I was talking about, where, for example, you introduce something, a change with the best of intentions, but there are interesting consequences. You mentioned the changing lines of the number of lines of code written, which is a very classic one from the 1980s or something like that. But also things that you still see a lot these days, like individual contributor performance rewards. You want to incentivize people to perform better, but you look at individual performance rather than performance as a team or as part of a wider organization, which creates an incentive for people to put their own interests ahead of the team, which then causes conflicts in the team and introduces problems that could propagate even across the whole organization, which could then become dysfunctional. One that I’ve seen happened a lot, especially with teams that are dealing with very old code bases and they don’t have a lot of confidence maintaining code is a top down mandate to write tests and say you have to reach this code coverage percentage and they give you a number like you have to have 80% of the code covered. And there’s lots of ways for you to reach that number. You could write a test that exercises the code, but doesn’t actually test anything, doesn’t assert anything and boom, you get the 80%, but you’re not actually doing anything and you have a useless test and you haven’t actually improved. In fact, this kind of approach sometimes, especially if it’s forced, if it’s not the team that adopts it, if it’s forced on the team, usually means that the team does not understand the value of tests and because they don’t understand the value of tests and why they’re testing, they don’t necessarily know how to test what matters. Right, and they end up writing the wrong tests, which could make the whole code base worse because now you’re, for example, coupled with, you have the code base coupled with the test structure, you want to refactor the code, but it breaks the test and you don’t refactor. Which then spirals out into the architecture degrading further and further and further. And at the root of all of this was amended, done with the best of intentions to get teams to write tests. So, it happens a lot. I mean, there’s a lot of examples like this. Yeah, like software engineers particularly for examples because as you mentioned, right, fundamentally software systems are well systems and fundamentally machines, right, because there’s different kinds of systems as well. Some machines in particular, you know, they’re made by an animate parts and these parts don’t have the wrong goals. Right. So as an example, cannot create the wrong incentives in a code base, because you know, a code base, the machine doesn’t do anything on its own. Now for developers, developer teams are systems, but they’re different kind of system like social systems where each member has their own goals. Right. And so that’s why by creating their own incentives is you’re forcing them to make a choice between what’s best for themselves and what’s best for the company and typically people, you know, we all know how that choice typically goes. And the last element that creates such, such crazy effects like the one Louis was talking about is why it’s called a social technical system is the interaction between social systems like teams and machine systems like code bases, right. And so that’s why as an example when developers have emotions about the state of the code base, he also ends up making things worse and you know this kind of crazy dynamics. Absolutely. Yes. So I don’t know I don’t know. I don’t know if machines are just machines now because with all the AI agents going on. Maybe that’s going to change a lot, but that still doesn’t mean that machines can’t be unpredictable any. You work at Meta so you know this pretty well. I mean, systems behave very unpredictable at a certain scale that they don’t when you begin designing them. When you are designing for an architecture for 100 users, 1000 users. It’s not a lot of these assumed behavior is not going to hold for a million users or even more than this. So it’s there’s a lot of especially in a very complex system. There’s a lot of unpredictability that could surprise you in this in the systems that you create. The one thing that I’ve noticed, which is very common across companies is that and I want to kind of link to the social aspect of systems is that every so it is kind of like every department lives in its own bubble. And we can see this also on like on social media and when you have conversations with people in the industry. So developers are all about agile and scrum and continuous delivery and TTT. And then you have the designers about design thinking and strategy UX and managers have their own things as well. And it’s like they think they exist in isolation. So all the optimization they do, they do them because they can improve some kind of metrics or something. But it’s always in their own bubble. So in your opinion, what’s what are the main consequences of this kind of mindset and this kind of social system configuration? I mean, I’ll start and then I mean, Luis, I’ll call you in. Right. Well, the main concern is essentially screw ups, right? Where, you know, each department is doing their absolute best and then the the sum of the parts would be great. But you’re looking at the interaction of the parts and that’s not as great. Right. And so as an example, some teams might pride themselves for doing continuous delivery and you say you can’t release to production 50 times a day. We’re all happy. And then you’re like, hey, but if we release a major features in production without giving marketing and product folks the chance to, you know, create the right expectations and audience and marketing campaigns, well, essentially we’ll only find the outcomes that we would have gotten from those changes because we’re not playing in sync. Right. And so I guess that’s it. That’s the fundamental point. Yeah. It’s it’s it’s part of the part of this is this anti systemic way of thinking where you think about these things in isolation, right? You’re improving design, you’re improving engineering, but you make this assumption that they’re not connected, even though rationally, you know that they are and that they have to collaborate and work together. So what this ends up creating. So there’s there’s more practical. Well, they’re all practical, but there’s there’s a couple of major consequences that where this could happen. One is the feedback loops between these entities, between these teams, let’s call it this social systems. Even if they’re within the same team, and I’ve seen this also happen where you have people who work technically inside the same team, but they work in isolation, they don’t interact regularly and the designer does something, throws it over the fence. A day later, the developer gets very frustrated by, you know, the designer’s wild imagination. He says, no, this is impossible to do. It’s impractical. It requires me to reflect or blah, blah, blah. I sent it back and a day later, the designer comes up with a revision. So the feedback loops on disciplines are very, very long and people are not talking together and resolving these things within minutes sometimes. I’ve had the pleasure of working in teams where the designers actually collaborated with and paired with the developers and the engineers. And it was a pleasure to see because they were trying out new ideas with live code and they were working on live things, not a mock-up, not something on Figma. They were actually trying out new ideas and small ideas. I mean, not huge, but it was pretty cool to see suggestions coming from either side about how to improve and how to make that thing happen. And this also has an effect on the team’s cohesion because if you’re in these very long feedback loops, especially if there’s a lot of frustration going on, the resentment grows and you start to blame designers and you start to blame the product manager and you start to blame whoever. Because you’re not working together, you’re not understanding each other’s problems, which are also your problems or should also be your problems, which is why I think a product engineer is a more fitting description for what we should be doing. They’re about the product as a whole, not just about the software part or just the technical part. So it doesn’t necessarily mean that I’m a designer, but it means that I also care about designing, that I also care about having a proper conversation going between all parts. We’re involved in building this product. Yeah, we usually hear related to the new generative AI creating code for us that code is not a bottleneck, right? So can we kind of explain this sentence in system thinking terms? I mean, yeah, let me put it this way. I wouldn’t even, you know, when I hear the word bottleneck, on one hand, yes, I do agree with the statement, and we all read the goal and we understand what it means. On the other hand, I mean software development is not manufacturing. This is an important point. The point is, you know, there’s a lot of focus in the industry on throughput, number of staff, productivity, right? How do you define productivity as an example, right? So because it’s some sort of measure of velocity, there has to be time at the denominator, which is fine. What do you put on the top, right? What is it? Is it like stuff done in the human time? What are we producing? Is it lines of code? If you analyze it for a meal, it kind of cracks down. Now the problem in my mind is not much that, you know, writing software is the bottom, you know, isn’t the bottom. Like, yes, it’s not like fundamentally, if we could speed up writing software by 10 times, we wouldn’t be able to reach 10 times the outcomes in the human time. It’s not even, I mean, it’s laughable, right? It’s annoying trying to argue for it. But the point is, and it is even deeper. The problem is that fundamentally, this stems from an anti-sextemic view of what product development is, right? Because, and this also like explains the problem that Luis was talking about, which is resentment and building up and friction and blaming each other. And also why in some companies design and product and engineering, they collaborate and even like other areas like marketing and sales and whatnot. And in most companies, this doesn’t happen. And I think like, because a lot of companies start by hiring a panel of executives. And so typically, I don’t know, if I were to create my own company, I might hire you Giuseppe and like you’re the executive for product management. And Luis, you’re the executive for sales, right? Now fundamentally, what that message says is, hey Giuseppe, you’re going to be entirely and fully responsible for product. You hire your own people and do whatever you want. And Luis, you’re the same with sales, right? And if product doesn’t go well and sales go well, you’re a good boy and Giuseppe isn’t, and the other way around, right? And fundamentally, this cascades down, right? Because then in turn, you would hire a VP of infrastructure and a VP or whatever. And this goes from the top all the way down to the teams where people tend to report to different hierarchies of management and have different goals and different incentives and so on. About the blame is a little bit the same because if we fundamentally believe that the outcome is the sum of the parts, and that’s the belief behind splitting the responsibility across the executives, then the point is when things don’t go well, I’m like, hey, I’m doing my part. Who’s not doing their part because things are adding up, right? So you don’t see it as, hey, we might all be doing our part well, but we’re doing it in a way that doesn’t really fit together, right? So it’s kind of the same mindset, basically. And so for LLMs, the point being is it doesn’t really matter if you write the code. The goal is not writing the code in the first place. The goal is integrating a new change into a system and then sustaining a steady stream of changes for several years. And that’s the thing where when I look at LLMs, they’re like, oh yeah, can you write me a Tetris game from scratch in a minute? Amazing, but that’s not the job. That’s where I’ve seen a lot of companies begin to struggle. I’ve worked as a consultant for 15 years or so. And a lot of the companies I’ve come across, they start out very well and they reach a point where the complexity builds up so much. Not just in terms of the software, but also the organization becomes so complex that they grind to a halt. The whole thing becomes unsustainable and they accumulate so much. I don’t want to say technical debt, but they accumulate so many problems in the product that they’re not able to improve the product any further except to fix issues. And it’s a lot like that. A lot of the issues have to do with not looking beyond your bubble. You fix your stuff, but there is a systemic problem somewhere in the architecture around you as well. But because it’s not yours, let other people fix it. And the other people are thinking the same thing. So nothing ever improves. And the other team is not looking at anything else. They’re focused on building the lightest chassis so the car is as lightweight as possible. And then you bring the two things together and the car flies off the road because it’s too fast for it somewhat. So you have a huge problem because you’re not looking at the whole interactions that you don’t expect to see because you’re not thinking about how the whole pieces integrate with each other. Yeah, and I guess another important factor to consider is that there are delays in the job we do. So even if you write code like 10 times faster, you’re shipping all these features, but then you’re ignoring the fact that there are people that use the software. That because they’re human, they need time to adapt, to understand, and that takes a lot of time, right? Most of all, for example, in business products. So that delay is exactly what we need to make the product better, to make decisions. So it doesn’t really matter that you just can spit codes super fast if you if you can talk to them that feedback and maybe it’s not even arrive at feedback in a timely matter, right? So like once again, right? And you know, this is like my own very personal kind of opinion. I don’t think that if you’re let me put this way, if you’re a software pro company, right? There’s a lot of people will swear by the importance of speed. I have yet to build it all. I imagine you’re like, you know, notion, right? You start from scratch. You’re on the rat race. You need to go so quickly that the competitors will never catch up with you or slack the same. But then you’re like, for a minute, if you look at those products, and I think that most companies are like that, if you had to rebuild them from scratch. So imagine you do this experiment, right? You look at notion and you want to rebuild it from scratch exactly what it is into a new company. It’s not that much work. Now, the point is, it’s not like they probably didn’t become successful by working 20 times as hard as others. They just understood one or two things well that created some sort of like attractive states for their customers. And that worked right. You know, remember people have emotions. So once again, the whole different story. But the point is, what really matters is doing the job that your customers have for your product in a way that’s optimal for them under their circumstances. This normally isn’t about like building the world. So if suddenly with LLMs, even if and I think the answer is no, but even if we were able to say accelerate software development by 10x. I mean, you’re running to nowhere. The point is you still need to understand those things. That’s the hard part of product development is not we need to just build it all. Yeah, I think something similar happened with the blue sky, right? The team was quite small. They built it quite fast with not much. Yeah, it was very similar story. And so there exactly like blue skies really good example that our matters understanding your audience. Right. How’s your audience different from X? What do they care about? And as an example, the policy around blocking content and people is way more advanced because it carries to an audience is not something that oh, yeah, if we go all LLMs tomorrow, we’re going to have a blue sky. You need to understand stuff. Yeah, yeah, yeah, definitely. I know there are a lot of bottlenecks. I don’t know if customer feedback is necessarily the biggest one. It all depends on how aggressively you seek it out because you could get quite aggressive to get that customer feedback. Sometimes and especially in a company that is a few years going already. I mean, even writing a very minor feature can can take a long while because of all the tech that in the way and that you have to clear all the things that you have to change and prepare for between before you before you release. So that there could be feedback site feedback delays everywhere. It very much depends on on what products are building the audience as well. I mean, sometimes I said you can be quite aggressive to get feedback from customers. It depends also on the customer. I’ve worked on a project where the customers were judges. And it’s not like you’re going to bother a judge to get feedback more often than not to bother you because something wasn’t working like they expected and they would be very angry. Also, you know, just to jump on feedback. I mean, I don’t know if it’s really the not to system thing, but I think it’s an interesting point. I think like a lot of companies abuse this thing and the old user research and whatnot. Because fundamentally feedback is not there to tell you what to do. Right. And I think a lot of companies, they kind of try to use it a little bit like if they were blind and, you know, testing the words. And what you probably want to use it for is to validate your assumptions. Right. So you come up with a model that explains your market, your customers, their need, how your product delivers on the job that they have at their ends. And, you know, and then what happens is you try stuff. And if there’s a mismatch between what you’re seeing and what your model would have predicted, then you gather that as feedback and adapt your model to take that into account. But you see in a lot of companies where there’s also like, I don’t know, almost like some sort of fear of making decisions and trying things because, oh, we just need to ask the users. And then the other problem is you can’t ask the users what they would do because it’s not how people think. And so you say, oh, would you buy this? It’s a really dumb question, but it’s a popular one. Yes, and the famous, doing a demo and asking, did you like it? Yeah, that’s also a classic. Yeah. But yeah, you can you can trust so sometimes you can trust the users, but you have to know what is, you have to understand the problem. You have to understand what you’re trying to do rather than what they want because the users of your platform are also conditioned by what they work with. So the current product, they’re conditioned by what they’ve seen before in the competition. So they don’t necessarily. They’re not your product designers. They’re not your architects. They’re not your you have to go to them to understand their problems, not to look for solutions. You’re the one responsible for the solutions and you’re the one responsible for the decision making. And sometimes you’ll make the wrong call. Sometimes you’ll make a bad decision. You’ll either overshoot or undershoot or completely miss the mark. But this is why it’s important to have these very short, quick feedback cycles because you can try one small thing with minimal risk. And if that works, then you move on and you continue to do that. Otherwise, you go back to the drawing part, but it’s always a very small bet that you do every time. This is how this relates to systems thinking as to do with how you can predict the behavior of the system. Because if you introduce a very small change in the system, the behavior will be slightly more predictable. I’m not saying that you can 100% predict how the system will behave because it’s usually very complex, at least in our land of work. But the bigger the change, the bigger the unpredictability of how the system will react to that change. And this is why you do these small iterations and you test and measure all the time. I was wondering, in your experience, what’s something that either leadership, but also an individual contributor can do to kind of make decisions as a system and not just in the local area? That’s a good question. So I think I’m both optimistic and pessimistic about it, which is funny. I think on the optimistic part of it, which is probably the harder one to defend, is just thinking things, mapping them out, talking to people. That helps a lot. Yes, it is true. Ultimately, the incentives created by structures or other things will determine a lot of it. But fundamentally, it’s a powerful way of looking at things. And so what happens is if you tell people, hey, there’s a chance that this is going to happen because by doing this, that’s how people are going to react and that’s going to cause this, which is going to cause that. And what happens is sometimes people will fall for it. They’ll be like, hey, maybe we shouldn’t do this. And typically it’s not in your power unless you’re very high up. But even then, you’ll be surprised. And I find it’s not in your power to actually change things unilaterally. But typically by involving people and almost educating them a little bit without really mentioning that you’re educating them, things can improve. On the pessimistic side, well, most of the times it really doesn’t. You can try to have some success. Typically, you will find a band of people where you’re going to go to the pub and have a lot of fun talking about this stuff. But then you’re still going to crash by the wrong incentives and structures in place. Just saying. Yeah. So if we keep seeing a system like at least in software development as a social system, that’s where the truth is. So we are a bunch of humans that work together towards building a product. So talking to each other is the bare minimum. So that’s good. Then there are politics as well, which are a very good part of very good, very important part of societies. So like in the real world also in our industry, it’s very similar, I guess. The other thing I want to mention is if you find yourself in a position with any sort of influence or power to be a problem manager or an engineer manager, it doesn’t really matter. Even if you cannot change certain things because they come from the continuing organization, you can still try to dump in some of the wrong incentives. That’s it. Definitely is going to happen. Makes sense. Definitely. I mean, you’re part of the system as well. So it’s a matter of also understanding what kind of impact you can have. Maybe you can’t make a big splash on the overall picture. But I mean, even looking at living organisms as a system, which is made of smaller systems, living beings made of organs made of cells, I mean, it only takes one cell to become cancerous. You can’t kill the whole thing. So just because you’re one cog in the machinery doesn’t necessarily mean that you cannot have an impact, hopefully a more positive one than cancer. Yeah, yeah, that’s a we would have a funny metaphor. I want to be the cancer of this company. Cool, cool. Yeah, so we are I mean, this is the product engineers community. So one of the questions I love to ask is, you know, product engineers are not only concerned about the technology part, but also about the product part. They really like to shape some help making decisions or can even influence them. Even thinking about the user experience and the discovery, which, of course, is a teamwork. But it’s something that product engineers really take at their heart and they really like to contribute with it. What do you think is the impact of such role in our ecosystem, let’s say in the software development system compared to when you have very, very specialized roles that just do one thing and care just about their own skill set? I’m I’m going to start with saying something perhaps will be controversial, which is I think is just the baseline expectation with seniority. Apart from very, very few profiles which can allow themselves to be extremely specialized and perhaps look at all the software like a few work on Linux kernel, maybe. But the point is apart from that, if you come in at a level of experience where you know you’re considered somewhat senior, I would take it as a baseline expectation. Otherwise, you’re counterproductive, de facto, and people who know anything will probably not hire you at all. That’s where I stand. Yeah, definitely. I’ve always been very concerned about stuff like design and user experience, even though I don’t consider myself a designer, but I do care about the topic. And it’s somebody know how products affect people in markets and so on and how we should strive to solve problems rather than build any random solution for problems that haven’t been validated. And it’s having this wider view is really helpful to to get people to care or at least, you know, start to think that it’s possible to care about beyond your little bubble. And because you’re looking out across, you know, all sorts of barriers, front and back and design, engineering, product engineering, etc, etc. You see the gaps between the elements, so to speak, and because you think about you think a lot more about the interactions of these components, you’re able to warn people, say, OK, but we could be doing this better or we’re doing this wrong. Or maybe there’s a different way of doing the same thing in a more efficient way, etc, etc. So this really helps bring people together and start collaborating. Obviously, the more influence you have in the organization, more effective you can be at achieving this. But it also depends, because sometimes, like I mentioned at the beginning, I mean, sometimes you have top down mandates to, you know, write tests and so on that don’t have this artifact. So you could have the big impact, but not necessarily in a positive direction. For sure, you have to be involved. You have to be part of that conversation and not isolate yourself, because that’s also a problem, you know, leadership isolating themselves from the levels below. This is very, very common in a very complex organization where you have multiple layers of management. It’s not that someone at the top needs to know necessarily, you know, what lines of code someone wrote, but they need to care about how teams are performing. Not necessarily how they are performing specifically. I think that should be a team decision. Teams should be able to self-organize and be the best they can be and reach out to other teams and so on. But at least care that, you know, am I having the effect I intended when I introduced this change or this policy or whatever. And sometimes that doesn’t happen. You just, you know, throw stuff down and let people sort themselves out. And if things go sideways, then you fire a whole team and that’s it. Yeah. So I’d like to stop a second to just read a couple of comments from the chat. I think mainly Martin wrote something about, so I once said to spend a month or two to improve coverage to more than 90%. But at the integration test level we had a ton of issues. So yeah, I think this is related to what Luis was telling at the beginning. That’s a classic, right? And then, sorry, my cat is covering the chat. So, you know, the way I look at this is that users feedback is just one input into your own learning loop, because your users are also limited by focusing on small parts rather than whole. This is a very good one actually. So, our users don’t have system thinking. They really, they have all the incentives on their own, you know, little word. So yeah, if we just listen to them and we’re just super optimizing for their own needs, and maybe it’s not the need of all the users or the business, you know, that’s a good point. Yeah, anyone in the audience, any questions for Michaela or Luis? You can also turn on your camera and speak. That’s fine. Or just write in the chat. Don’t be shy. Don’t be shy. We are friends here. Okay, no pressure. No pressure. I wanted to add something. Wait, just a question. Yeah. What do you think is the best way to spread the word about system thinking? And it’s a good one. Well, I mean, these kind of chats probably help. You know, sometimes, because, you know, in all honesty, there are some good books and there are some really, really good YouTube videos. I think like one of the problems with like education in general is that you can always like, I don’t know, help somebody get better, but they need to want it. Right. So today, which is one of the paradoxes about, you know, the information age, there’s information about everything you can ever dream about. Right. You can literally open the internet, Google, buy books, watch videos. And yet, what’s lacking a little bit is the appetite for this thing. Right. So more than talking about the solutions and, you know, what is system is and the properties and whatnot. I think like what really helps is focusing on the problem. Right. So finding examples where the existing doctrine isn’t working and then trying to say, what if there was an explanation that is not being considered here? And then people get curious and then you’re learning this stuff. It’s easy because you can just read it and, you know, watch it. I think that’s possibly the biggest challenge, which is trying to like wake up people to the fact that some of these big narratives, which is, hey, you know, we just need eight players or if anyone worked 60 hours a week, we could dominate our industry. It’s probably a little bit of a nonsense narrative. Yeah. Yeah, it’s hard. I’m more of a hands on kind of guy. So I would say it’s probably I would probably demonstrate system thinking rather than try to push any books or videos. I mean, I do that to demonstrate and show, you know, that, for example, two things that seem unrelated are actually connected and point out that something might have an impact on this other seemingly unrelated. People might listen to me or not. Sometimes they do. Sometimes they don’t. Sometimes nothing happens. Sometimes I get to tell them I told you so. But it’s I think it’s more effective to demonstrate than don’t try to evangelize anything because people tend to push back on that. Yeah, I guess the challenge there is, is that, you know, by definition systems have delays. Right. So if you want to demonstrate something like it’s you need to have a lot of patience because that needs to happen in the future. Maybe it’s not even going to happen. Right. So that’s I think the challenging part. If you make a small change today, when when is that going to happen? And how can you prove that? Well, you said it was right. So you need, of course, needed feedback that it’s it worked. But, you know, you may give up earlier than necessary. Yeah. Okay, there’s another question. Are there any visual resources that help understand system thinking better when working with leaders? Sometimes it’s hard to understand complex systems or ask the right questions to figure out what’s important and what has very little impact. Yeah. That’s an interesting one. So there are some visual visual tools like worldly maps or casualty, you know, change kind of diagrams or others, feedback loops, diagrams, whatever there are. The hard part is that nobody is going to like automagically created for you. Right. And so the problem is, so it depends what visualize means. If visual means say you understand the system or think you understand it and you want to win a visual form for others to try and understand it, then yes. If it means, hey, there’s a system that I wanted to somehow derive a visual way that explains it to me, then probably not. I mean, for some systems, maybe, but in general, probably not. Yeah, so for really complex systems, and you’ll never, for sufficiently complex system, you’ll never understand the full range of behaviors that emerge or emanate from that system or the properties of that system. Sometimes measuring is really complicated. For example, how do you measure quality, which is something that a lot of us care about like, what is, what is quality? Is it the number of bugs? Is it the number of support tickets? Is it the code coverage like we’ve been talking? So you need to understand what, what you’re trying to affect. But even after you understand and know what goes into it, what kind of interrelations and what comes out of it as well. Because sometimes you have something coming out of the system that creates a reinforcing loop, which could go either way. So for example, if you do TDD, for example, which is something that we do at the company, and you do it properly and you know you’re very disciplined about it, it creates a self-reinforcing loop because even, even people in the team were doing it, they begin to see the value of it. People begin to think in that way and the whole thing improves. Even the safety net improves, the thinking about the design of the architecture and the product improves. So it creates a positive feedback, but you have to understand what kinds of effects you expect. It doesn’t necessarily mean that you’re going to get them, but it’s, you might be able to map it out and show it to someone. It’s probably never going to be fully complete and you might miss some stray effects and butterfly that’s going to fly off and cause problems elsewhere. But it’s a model. I mean, models don’t have to be perfect. You’d go crazy trying to have a perfect model. You’d be stuck in designing this diagram forever and ever and ever. Never act on it. And if eventually you’re right, you can say, I told you. So yeah, it’s good for your reputation, right? So Martin writes, it depends on who you tell it to. Yeah. Martin writes, I’ve seen something called Current Reality Tree, which is useful to highlight causes and effects. It needs to be built from someone within the organization, though, who understands workflows inside the company. Okay, I know where I wrote it. Current Reality Tree. Yeah, something to look up. Okay. Nice. Anyone else has questions? Seems like not. Okay, I guess we are at the end of this meetup. I’m sorry that Carlos just joined. It’s okay. Next time. Next time. Maybe you can be our guest. Yeah, nice. Nice. Thank you everyone for joining. Yeah, thank you very much, Michaela and Luis. It was a very interesting conversation. Nice insights. Yeah. And so yeah, this conversation is going to be recorded, so it’s going to be uploaded on YouTube if you want to see it again. I don’t know if you missed anything. Yeah, thank you everyone. Have a good Friday. Good weekend. Have a good weekend. Bye folks. Thank you again. Bye bye.