Skip to main content

What do you need to go along with a decision? Conversation with Kenny Baas-Schwegler - part 2

Jun 22, 2022

In the 2nd part of our conversation with Kenny Baas-Schwegler (Strategic software delivery consultant and Domain-Driven Design expert, Xebia) we discussed why most organizational changes don’t work, and what are the four ways of Deep Democracy that can help move into a decision making.

It’s always important to ask: “What do you need to go along with this decision?” And it needs to be communicated what decision was made.

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

You were earlier talking, you only used the word once, but in a context you talked about promise, but I just wanted to quickly go fish. Is promise theory something you apply?

Kenny

Not yet. I read the second book. So the one from, I think O’Reilly, we are trying to see how does that fit with the whole bounded context thing, because bounded context is really about responsibilities. And each culture have different wording there. So if I come and say, this is the, a problem that you’re solving, we don’t have problems here. We have challenges. Okay. That doesn’t work. So I go to outcome or I go to responsibility and I’m looking for what, how does promise fit in there? So, me and a couple of colleagues are trying to take promise theory and see how that apply to the Domain-Driven Design space of bounded context. So, I think it can neatly fit, but I’m not so well familiar with the content yet, unfortunately.

Marc

Okay. You mentioned, I know it from Mark Burgess, who initially came up with it. And so what I like about it in terms of, so conflict is some, is a relational issue. And so what I like about promise theory, is how it reframes relational issues in exchanges. So you’re making a promise means you have an intention, you’ll go to best endeavors, but equally know promises wouldn’t need promises if keeping it was guaranteed. Yeah? So it applies that there is a potential failure and by that, it, so to me makes it human. It takes away the mechanistic assumption that, “yeah, these are just gears that need to fit together.” But it also reframes how the conversations are conducted once you start talking about promises. So that’s why I was curious.

Kenny

I’m looking into, so the book I was referring to, he asked the first book, which is with the interconnected part, then he wrote a second book and that one I’ve read, and I’m trying, I’m gonna read the first one as well. The second book is a more, I think a more condensed story on promise theory. And that he, I think he wrote for O’Reilly, alone. I think the first book is together with someone which name I forgot.

Marc

Yeah. I can’t recall it either. I have to admit I started the first book, but, um, I then came across Jeff Sussna’s articulation of promise theory find that far more applicable and digestible. So I’ve stuck with that, never finished the first book. Maybe I’ll have a go at the second book.

Kenny

Yeah. That’s, well, I’m wrote down Jeff, so I’m gonna look up that book. Yeah. But I see how it applies because DDD talks about strategic patterns and what are the bounded… What are the models and teams have in relationship with each other, which is also an interaction. So I just want to see how that model fits into the whole strategic pattern DDD model. So that’s my take on it for now.

Marc

So Jeff Sussna’s book is “Designing delivery”. Just in case.

Kristof

I have a question. So, we originally, we wanted to do this together with Evelyn. And she has a social, I think she has a social background. Like a social science background. Do you also have a social science background?

Kenny

No, but I have a wife with a social science background.

Kristof

Okay.

Kenny

My wife studied anthropology as a bachelor and then conflict studies and human rights. She has two masters in social science and law as well. So, and, I always call her the natural social scientist. So she’s like, sort of, I don’t know, she can go into a room and observe if people are mad or not. I’m like really looking up to it. So everything I talk about social science I’ll actually learn from her and from Evelyn by working with Evelyn. So, I find it fascinating because it helped me a lot with the facilitation and stuff.

Kristof

So how did you get started then, in this field? Did you come from more software background or?

Kenny

Electrical engineering actually.

Kristof

Oh yeah, yeah. That’s right. You said so, yes. That’s right.

Kenny

Which was half software and half hardware. And then I figured out hardware was really so imaginary numbers and everything and calculating things. And I’m like, yeah, I can do this, but I don’t enjoy it. So I went into the software and got into a company, a large insurance company, but I was on the asset management side as a software engineer. And from there, I just got a chance after chance and mentoring and coaching. And that was really important to me from also a social perspective already. Then I think eight years ago I met my wife and then she started to get me interesting. So I started reading a lot of books, from two Dutch anthropologists who do the corporate anthropology. And I just have the best feedback loop ever, because if I go out and I observe things or things happen and I go back, I can discuss it with my wife. And she’s like, “well, from a theory, blah, blah, blah, blah, blah. And from this blah, blah.” So I, that’s my learning part. And I’m really privileged to have my own teacher at home. So, that’s how I rolled in sort of the social part, because I was doing Domain-Driven Design. Cuz I learned that from, from that first organization, like I saw already ambiguity in language. And so I picked up the book, I started learning, I started applying and then event storming came in and I started doing event storming. But for some reason I figured out, “well there’s a lot of social things coming up here.” So, and then meeting my wife, getting into this, starting to look for conferences or places where I can learn more. And then I got to know a lot of people in the community that talk more about this. And then I met Evelyn three years ago talking about cognitive bias. So I said, well, let’s work together. So my company where I worked for our consulting company took a step in the deep and hired her. And another part of the company hired a different organizational, well, behavioral scientist, and now just worked and they’re part of our consultancy now, which I really, well, I really enjoy working together on this stuff.

Kristof

It’s interesting to hear how shared libraries can shape our worlds.

Marc

Oh, you didn’t mean technical, you mean book libraries?

Kristof

Yes, yes. Yes.

Kenny

And this is interesting because I read, I try to read up on, and there’s been conference talks about this as well, so pure social science books. Also I took my wife books from her study and later start reading some of these and that really helped me become a better facilitator and see, okay, how does this help me in my role? Because I don’t want to become an anthropologist, but I want to learn how, what they see and how I can apply it to my field and strengthen my own field in that. And especially working in between teams, it’s that social and technical part. They interact with each other. Now I can see why most organizational change don’t work because they either change maybe only the process. Sometimes they only changed the technical part. Sometimes they and now I know they interact with each other and why it doesn’t work and what the problems are there and then start listening to why it doesn’t work.

Marc

Could we bring this as a usually change is focused on the parts of the system instead of actually the relationship of the parts of the system?

Kenny

Yeah. So it’s not focused on the interactions. Mathias Verraes made a nice post about the inverse Conway’s law that they call it. But, it’s not on top of the back of the mind, but the gist was mostly if you in the past created a really, a design. So you designed your software system really rigid, and you tried to only change your team. Like some people say, “we do, we change our team. So then hopefully the systems will, the software system will change with it,” but it’s an interaction both ways, right? So, it doesn’t necessarily can go well, you sometimes also need to change your software design or architecture with it. You cannot just say, “well, I formalize my teams in a different way. So I’ll formalize.” So DDD software architecture or design will change. You need really good strategies to actually do that, in my opinion, especially when you’re working on big balls of muds, that’s been there for eight years and that’s really, you need to form a strategy of how they create new boundaries or how to, how they work, because they’re still well interacting with each other on a daily basis on the code. And maybe the code will change a bit, but also the organization on top still demands in a certain way, forcing you back in that rigidity of that thing. So it’s not always a good thing to do. And the company I’m in now has a big ball of mud that’s there for six years. So you cannot do it there. It’s really hard to tackle that one, but the ones I’m working on is a monolith that turning into a big ball of mud, and there, it can actually work. Right. But I give them a proper strategy to let them pick between three tactics saying, okay, if you pick up a new user story, because I don’t want to, I don’t want to close the shop. So, I tell them, okay, you’re, you’re moving towards two teams. It’s gonna be chaotic, right. It’s complex. But here’s the strategies you can work with. With dissecting that monolith slash big ball of mud. And every time we can have a trade-off, if you do it, the correct, if you do it the way you’re already building it, or moving towards that new architecture, and let’s check the trade offs at each new section, right? And then you see it working where, where now they’re forming their own boundaries within the same code base, by the way, this is a Ruby-on-rails world where Ruby-on-rails already enforces you to create a big ball of mud. By the way, I figured out, because my background is in Java and C sharp or C++. So it’s already enforcing that to build on top of the model. So now I’m giving them boundaries and now you see them already negotiating, right? Between a code base, when to move something out, when to leave something in, and that interaction I’m focusing really on the interaction instead of, and the boundaries instead of, well, how the process change. I don’t, I don’t really care how they, how they do it. That’s for them to solve. It’s like, I’m starting checking the signals, right? If I hear something in Slack, I see a conversation going, I said: “hold on. Now I need to put these people back together in a room and let them start talking”. And they figure that out for themselves. And now they’re changing the interaction and then it works. But I don’t think this approach will work on that eight year old, big ball of mud because that’s a whole lot harder to tackle. So you need a proper strategy and execute that strategy because else you make it even more worse. I seen that, I see that working inside a lot of organization where the first thing they do is create an event stream. A proper business event out of that big ball of mud, create a new sort of service or bound context, whatever you want to call it. And that’s their start and halfway is stopped it, but they never executed. And we call it the ‘umbilical cord’ and never cut the umbilical cord together properly. So now they’re even in a worse situation and well, the black hole just swallowed another one of your services back in right. And DDD terms. They call it the bubble context, right? The bubble context is like, okay, we’re creating a new bounded context next to it, still using the old system. So old database, and that’s the really cheap investment to create a new, proper domain model. But eventually you want to go to the autonomous bubble. If you leave that open, the bubble will burst and it will become one thing again. And that’s what usually is lacking is if there’s too much focus on delivering features, you need to have a proper person, an architect in between that says, “no, we need to finish this. How are we gonna do it?” Else in three months, you’ll be in a worse situation. So that’s a bit about and that’s a bit about changing the interaction instead of the parts itself.

Kristof

It’s the interesting, what I’m hearing is that you’re, you help teams that are like, it’s not a team necessarily, it’s somewhere, like, as you said, it’s in between scopes. But it sounds like most of the time you’re in between the team and then the immediate layer above, or like you’re dealing with, like, one part of, or one distinct part of the system, like a big ball of mud or a monolith or something like that. Do you have experience helping organizations like building a platform as in, Jabe Bloom’s scope economy, like an economy of scope and really structuring the whole domain model. Do you have experience doing something like that?

Kenny

A bit. But not in the long run yet, a colleague of mine is more working on that. I like to tend to sit in between business and, so the users and the IT, so really where do Domain-Driven Design? Well, Domain-Driven Design is on a large skill systems as well. But I really like to still work with the code in the team and see, okay, the impact we’re making on a more strategic domain oriented scope. How does that affect the software and try to sit in between, so to see the signals and push that back to the, to the engineering manager scope or. To that level of work as Elliot Jacques says, right? I don’t generally sit on the higher levels of scope where you, well, where, what Jabe Bloom also says you do more of the really strategic Wardley mapping. I don’t have exact experiences. I talk that and I try to be the, how do you say it? The one, translating it towards the… Well…

Marc

Conduit.

Kenny

Yeah. So I’m more the facilitator in between, because I like to be in that situation and see the signals inside the team. As I said tomorrow, the reason I got into this point is that because I was a developer, I love to put code in, but I always got annoyed by that higher levels of scope, sort of say, higher level of work, sorry, higher level of work, where it impacts me as a coder and I got frustrated. Why are you doing it? It’s okay, I’ll handle that. Right. That’s why I’m still in between. And I love still doing code. However, unfortunately, I don’t do a lot of code anymore, but as I said, tomorrow I’ll do some Ruby on rails pairing where I won’t code, because I’m much too slow compared to these people that can just, but if you give me Java, C sharp, I can still, but I cannot keep up with Java 14 and dontnet 5, I don’t know. But I still love to see what is this decision impacting the code on that lower level and vice versa. I love that feedback loop and try to make that feedback loop faster, right. Because that’s what I think is usually lacking. There’s a decision being made strategically and how’s that feedback loop coming back on the team. And I can make that, I can translate that because I know of both worlds sort of say, and that’s my sweet spot. So long answer to a short question. No, I don’t have that. But I love to do what, well, Susanne Kaiser is doing with Wardley mapping towards, moving towards using team topology and DDD and combining that and a lot of in the DDD community is doing that. We’re doing some Wardley mapping. And how does, how can you drill down towards the teams and towards the bounded context of teams are working on and how can we forms categorize sub domains on it? I do like that content. I think it’s very valuable. I think that’s where we are moving where, and that’s what my colleague João Rosa is doing. Sitting with C-level, doing Wardley mapping, doing more team topology with the engineering managers. And then, how does that impact the teams and how do you need to change the teams based on that? I’m very interested in that, but you know, there’s all these nice books as well, right. And then you need to pick one, you need to focus on one.

Kristof

Oh, it’s fascinating.

Marc

So you earlier actually pointed out a conflict that I also experience a lot. So on one hand, you, you’re coming in an organization due to your technical expertise as an architect, but equally we have, I said, what you actually have to change is relationships, not things as in, yeah, we can tell them a bit, bit about things, but as soon as believe that will evolve anyway. So that’s, that’s not the sustainable change, the changes if we’re reframing the relationship. And then you point out actually really nicely that what you’re actually doing is facilitation. But, so the conflict that I often experience when I facilitate is also, so we have an expertise, yours is architecture. How do you balance them? So as an architect, you obviously have opinions. You see what the current architecture is. You will probably understand why some of the constraints that the current architecture exerts on the team is, is held holding them back, what need, what could be moved to enable them. But as a facilitator, you obviously need to focus on relationships. So almost take a stand back from the architecture itself and say, so how’s the sociotechnical system as a whole. How is it maybe not working as well as it could? And what, what can I do as a facilitate to start making these relationship better? So how do you handle these conflicts and how…

Kenny

The conflict between, I have an opinion and I need to stay neutral, right?

Marc

Yes, exactly.

Kenny

That’s the conflict. Yeah, I try to balance it, to see what the need is. So I, and a perfect example, one time in a different organization is from, and my colleague João Rosa was, were the interim CTO. I was like, okay, from there, the it was like, we need to hire more people. And then we looked at the current tools or frameworks being used, and they’re like, well this, we cannot use this. We need to go more market fit. Right. So Kenny handle that, please. Okay. So I go to the teams, and then we said, okay, we need a new front end framework and looking at the market, there’s two. There’s Vue VS and there’s React, which we can market or recruit better on. Right. So that’s, that’s concerning nice strategy. And then I go to the team, which was more of a media team, a few people. And I just ask them the question: “These are the two frameworks. What do you need from me? “And say, yeah, I, I need to get experience with it. Okay. Let’s, is there a feature we could start working on? Yeah. This one. Okay. Build that small feature out in both frameworks and see how they feel. Okay. And then the guy returned and the two other developers were like, yeah, I’m not really, the few other said, well, he can decide, well, that puts that person into a rough situation. Right. Because all of a sudden he gets the pressure of deciding which one of the two for the future of the company. But at least I give them the chance. And as a facilitator, I notice… Because I couldn’t care because I wasn’t… In that case, I have my opinion which was better, in this case: React. And his opinion was more Vue. So that already conflicted. But I said, I won’t vote because first of all, I’m a consultant. I can’t vote for this, because it’s you that need to do it. But I saw his hesitation. And then I said, “I can imagine that it’s hard for you to take a decision.” And then I paused… and then he said, “yes, I don’t want to be the guy who choose for a framework. That all people in the future will, will hate on me.” And that’s a proper emotion, right? It’s like, I would have the same thing. And you hear these stories a lot where people jump in and jump to conclusion, “oh, who figured this stuff out? It’s an idiot.” And it’s like, no. Okay. So I created ADRs for that and I say, okay, what are the trade-offs? And then I could, then he showed to the rest of the group his solution, said, “now we’re gonna take a vote.” And this is a deep democratic vote. Right. I say, it will be a vote. It will be a majority. And then actually the other people voted for React while he was for Vue. And he was the only one voting for Vue. So it was like, well, 10 against one. And I said, okay. And then there’s from deep democracy, we say, there’s one important question to ask you. Right. It, it, we made the decision. It will be React, but what did he need to go along with React? And he said, well, yeah, I’m more, I’ve more worked with Vue, so I need some training. Okay. Then we’ll make sure you get training for React. And that’s a way of sometimes getting back and saying, okay, I will take the lead now for you. You’re fine. And I will make sure that there will be a decision from the group and that the group is there. So I created an ADR and say, “these people, all these 12 people were there, these people voted, this was the voting, and this is what, and that was the ADR setting there.” So from now on it’s the group decision instead of one person’s decision. And that’s how I dealt with that conflict in a way. But it’s a balancing act. And I had this discussion with a colleague today. How do you do that as leadership? So deep democracy sounds like it’s all democratic, right? But no, some decision you cannot make a democratic decision with 100 people. It’s hard. Maybe you can, but it’s hard. So deep democracy has four ways of moving into a decision making. It’s like the fully democratic, ‘This is the problem. Let’s figure it out.’ Second one is, ‘We have a problem, I already thought about it, I think this is a good idea.’ And then there’s a third and the fourth one. The third one is like the proposition, ‘I’ve worked this out, this proposition, because this has high priority.’ And you give good rational thoughts. And then you say, ‘This is it. If you cannot give me a solid reason why not to do this, then we’re gonna do this.’ And then you have the command, ‘We’re just gonna do it.’ But in each case, it’s always important to ask, ‘What do you need to go along with this decision?’ But also be clear on which one of these ones you pick, in my opinion, right? So I’ve seen a lot of leaders coming in with me. One time someone did that. And he said, “Well, Kenny, what do you think?” And I was like, ‘Okay, he wants my opinion, right?’ In the end, I figure out he already made his decision. So I’m like, ‘Well, don’t do this to me. If you make a decision, tell me you make a decision because you are, you can make this decision.’ You, this person was my hierarchical higher ranked person, ‘Make that decision. But ask me what I need.’ It’s really disrespectful if you already know what you’re gonna do and then ask people, ‘Oh, but what do you think?’ No, you make the decision, clearly communicate that decision. And that’s for architects. I still think if, as an architect, in between the teams and trying to fit the systems together, you still sometimes need to make decisions for the team because, and, and I think this was from Ruth Malan. She said, right, “you cannot expect the parts, the autonomous parts to make decision that eventually lead up by them fitting together just by being the consultant. So sometimes you need to make rough decisions because it can be decisions. That be, that is not so nice for one of these parts. That’s are, these are the hard decisions, but you want to make the system fit together. And then you can still make that decision, but also manage from what do you need to go along?” First of all, you need to very carefully explain it, right? So probe, “what do you think if this happens?” So then you can catch the net and they can come up with a really nice proposal that people can say, “okay. Yeah, this sucks, but I can agree,” but also let that, let that be, in my opinion, usually then people say, “yeah, I’m really pissed off about this.” Okay. Just be pissed off. That’s fine. Right. Be pissed off if that’s what you need, shout, be angry, be sad. And I won’t fix that problem. Right. It’s their feeling. And that’s the psychological safety and then ask, okay, right. But what do you need? I know this is sad. And that’s how I deal with it. So sometimes really taking that architectural decision, because sometimes people also want leaders or want to be managed. So I love it sometimes when, when some people just say, “Kenny, we’re going on holiday. This is where we’re going. And I know you love this and this and this, let’s just do it.” I’m like, “okay, fine.” And that’s what I see, a shift now going to it needs to be the groups deciding, but sometimes, it’s so it’s such a guilty pleasure to just not need to decide and just follow along with the path and someone decided it for me. It’s fine. So that’s, that’s how I balance the two.

Marc

So what contrasting you to what you described there? Because to me, this sounds more like a catalyst, rather than, you know, what we classically understand as leader in organizational leadership and organization, which is a term, by the way, that…

Kenny

Ambiguous.

Marc

I find terribly muddy and absolutely not helpful anymore. So I usually…

Kenny

No. Truth.

Marc

Leadership articulations have become so commonplace that they really. To have no meaning anymore. But, um, so that’s why I’m looking for other things. so catalyst becomes an enabling constraint according well, according to Alicia Juarrero. By helping closing feedback loops. Yeah. So, so first of all, you are part of the system. So you are one of the parts, but you are not same as the other parts. As a catalyst. What you’re actually trying to make happen is a sort of system system interaction. So you have described how you catalyze decision making, but equally, immediately, how you listen to the feedback and through that moderate the catalyzing. And, so a system becomes stable in that sense or new system interaction become stable in that sense, when the system starts to reproduce the catalyzing, and even that is what you described. So I think it’s not leadership or imposing solution. It is literally you probe, as you said… This is like a catalyst being introduced to a system, sort of yeah. What’s happening now that I’m here. Yeah. Oh, some new interactions are happening. What’s the feedback? Or if the feedback loop closes so that this starts to be repeated, then also the people that you do this with, they will learn, oh, this is what happened. And even when you leave, they can continue doing this. “Yeah. Okay. Let’s try. Okay. We don’t know which of these two solutions we wanna pick. Well, let’s go into a small thing with most solutions. See how we feel and then have a deci-” that’s something that people can immediately pick up and run with. Yeah. I really liked it. How you described it, because it’s, this is really, I think how, how we deal with complexity.

Kenny

And I really like the word catalyst. Yeah. Because I once saw an entire Twitter thread about leadership with a friend of mine, Trond and no, it’s, “I’m against leadership.” And then I found out he was meaning the hierarchical manager as leadership. And then I like, “okay. Yeah. Then I agree with you.” And it’s becoming totally ambiguous. And the way I just described it is the catalyst. Someone with leadership skills, but not per se being the one, one that’s hierarchical higher than them.

Marc

Yeah. Which is also why I wish we would start distinguishing between acts of leadership. So I like Edgar Schein’s definition because he basically says this is emergent. Yeah. It’s just, somebody happens to do something that enables other people to follow. And he says, real leaders emerge so that you can’t anticipate where they come from who’s that gonna be in the active leadership versus people in authority who have been tasked with executing authority in the sense of you, the box stops here, or, this is, this is something we expect you to do. So we’re throwing everything in this leadership, but, okay. So this is also just my opinion. The reason, this is not getting clarified is because there’s a lot of money to be made in leadership coaching. And leadership advice. So, you know, you have whole conferences where all they’re talking about is allegedly leadership. And if you look at the program, you can see the big ball of mud. I said, no, they don’t know what they’re talking about. They’re mixing metaphors all the time. But it gives you these. So people like being seen as talking about leadership, because it attracts that higher level of pay and add stats status within organization.

Kenny

And that’s, what’s in one of my customers I’m helping as well. I’m helping the team, but I want to eventually that they do it themselves. So I started talking with their engineering managers and with the architects. Okay. We need to make sure the teams are start doing architecture. They come from a place where they have tech leads, but that gives instant ranking. And people started looking at them like, okay, but you’re the architect take a decision. Okay. That’s not what I want. So what I did was doing the same here coming in. And then I, so some of these members, or some of team members starting asking me, “but who took the decision?” And say, “you did” “me?” “No, you as a team took the decision, right?” “Yeah. Yeah. But, well, it wasn’t nobody.” No. And I said, “that’s the beauty because you all did it.” And then we, I started talking about the way I see and the way we want to set up architecture in the teams. And now they’re all like, “oh, that’s what I want.” And uh, but now three people want it. And they’re like, but there can only be one. Right? I said, “no, please not, no, you, you can all three start doing architecture. And I would rather love that than only one person, because then we’re back to the single thing.” And that’s, what’s going on there. And now they’re all in a state that they’re taking that part there, where, where it’s also flexing to the left, right. Where the PO came up and say, “well, they took a decision functionally that I don’t agree with.” I said, “yeah, fine for now. It’s in, an autonomy boundary because it’s in the system so we can change it later on if it doesn’t work. But let them roll for now because I like it, that they took their own decision for the product. That’s what I want. And now they will get feedback from you and you say, well, this doesn’t work fine.” That’s great. But at least now I see them changing what you’re saying, cataclysm themselves in the system. And I haven’t, I haven’t heard that work, but I know of her work. I love the constraints as an innovation talk she gave. Thanks for that. This is also my, my metaphor I always use as a consultant. I always, when I go in, I always say, “okay, what does it take for me that you will kick me out? What does this take?” Because I don’t want to be fixed or stuck in your system. I want to get out. I want to make well, to change the phrasing. I want to be that catalyst. And then just not, then that the system will change and I can leave the system, but the system will continue working as you want it to be. That’s the first thing I say, because I don’t want to end up here being three, four years and well, then I might as well just join you. I’m a consultant. I want to help the change that you want me to help and then move out. I don’t want to be stuck inside the system and get swallowed there, or I move, but that, then I’m not a consultant anymore. I’m not sure if that matches with the catalyst thing yet. I need to look it up a bit more.

Marc

Okay. So natural systems. So where you create these new interactions with catalysts, then the system starts to reproduce the catalyst itself by itself. Yeah. So, it becomes a product of this, of the new interaction. But if we want to use it as a metaphor, then I still think what you’re saying is holding. So they have to figure out how to make these interactions sustainably happen once you leave. Yeah. So, if you would need to be there, this was like a system that would constantly have to feed the catalyst from the outside. Okay. So we’re going now deep. So auto please is the, is the underlying principle here that would require that the system produces the catalysts itself. And so that’s what you see in nature is yeah. So initially it’s there from the outside, but then it’s reproduced by the system.

Kenny

But I see that happening. Where they, where, where they will do the same interacting and mi- sort of like mimicking them in a way, but different. So become the catalyst themselves is that’s what you mean. Right? So they’re, they’re now doing the same thing, right. Reproducing what I’m doing in a way.

Marc

So it’s, for example, it’s a tech lead or an architect actually, instead of demanding a solution. So here’s the problem I decide actually learns from you how to facilitate the team and uses their expertise to help the team coming up with an opinion, which it also ties into it’s a complex problem. So the more people look at it, the better, the solution that we’re gonna find.

Kenny

Yeah. Yeah. And that’s what you see. I just give them practices as well. Right? To use on the different situation. So they’re saying, well, we gonna have three solutions. Well, just do a Pro-Con fix list. Now let’s keep it simple for now. And if you don’t, usually you get to one of the, one of the three, okay, this is the one, if you don’t just try both of them because it’s too complex. Okay. Do it. And so, without going back to the previous goes, without talking about complexity, I’m trying to help them deal with it in a way, without really saying what complexity is, sort of say, but just saying, we need to experiment, right? The experiment word. Unknown unknowables or unknown unknowns, sorry, not unknowables.

Marc

I even stopped explaining Cynefin. So if people come to me, once you work with them and start describing problems where I say, “okay, now you have now discovered complexity. You just don’t have lingo for it.” Then I might start showing that. But, I, for a while I did early in any agile or lean training, I would do Cynefin and just never saw it take traction, because you need to have experience of complexity and start to understand, so have the phenomenon in front of you that you can’t otherwise, you know, get your grips with, before people actually are receptive for this kind of language. And so, hence I’m totally with you. Let’s give them some practice. And that’s the whole approach of maturity mapping and the practice theory lenses. Let’s give them something that they’re act- that’s very actionable and relatively easy for them to adapt, rather than confusing them with a lot of theory.

Kenny

And that’s what, and that’s what you see back in the, Domain-Driven Design community as well. Right? You have the blue book, which is a large pill. I have it here and people say, “it’s odd, it’s theoretical, theoretical.” But if you go to the conference, we do hands on continuously in the training you do hands on because it’s pragmatic, you get practices. And that’s a good thing about, for instance, DDD I love is that it’s not a bounded framework. Like for instance, scrum it accept different methods or practices or patterns. The problem there is that people come in and they see, “okay, well now what, so we give a bit of guidance,” but it’s practice. We don’t tell you how to do it. It’s like, these are the set of practices, principles, and you need, let’s be pragmatic about it, and I’ll give you that. And from that point change, by giving them the practice.

Kristof

I’m listening to a sales book, it’s The Challenger Sale. And the way that they describe it is that, you have to, this is like a new sales methodology. Well, it’s not that new, it’s from 2008, 2009, but that they say that, the best sales people they saw were challenging customers. And we’re kind of like bringing them to some, some new sort of in insight. And they said that the one thing that you really should not do is show them a new insights, show them the problem, and then not have a solution, because then basically you’ve brought ‘em to the desert. And, um, and I think, yeah, probably that’s, what’s happens when you start talking about complexity is that you, you bring them, they don’t have an immediate resolution. So they feel like you’ve dropped them in the desert and yeah. And that’s not a, that’s not a fun thing.

Kenny

Yeah. ‘I’ve been through the desert on the horse with no name’ then. Sorry. I like, I like to quote some music stuff. And I think, so in the training I’m using, training from the back of the room and they actually say the same thing. Right? You want them to explore it themselves. And like yesterday I gave a training as well, and it gets sometimes it’s, I feel a bit guilty because they’re doing like this thing, and I’m just hanging around there for 10-15 minutes while they start discussing their own ideas. But, and that’s nice because during the teach back, they give, they started discussing amongst them how it is. And that’s what you want. Now you triggered them. Now they can resolve it for themselves. And you’re just sometimes giving them that guidance and the methods, or the practices, practices to help deal with their situation.

Kristof

That’s, that’s not exactly what they’re recommending in the sales book. But I think it’s still a little bit more about, okay, so how am I gonna make you buy my stuff? But…

Kenny

Yeah, of course, of course.

Kristof

Thank you very much for joining us and for doing this together with us, was a fascinating discussion. I took one of Ruth Malan’s courses, on recommendation of Marc. So I, the world of complexity-aware architects has started to open for me. But there’s still so much to learn. There’s, there’s a lot of, a lot of methodologies that you were talking about that I’ve heard references to, but I haven’t actually seen them in action yet. So, there’s so much to learn, really, really interesting things.

Kenny

Yeah. And I love, if there’s one person to follow on Twitter, it’s Ruth Malan because she’s just giving you an RSS stream of all the new stuff that’s coming in. And she’s so knowledgeable. So I learned a lot from her so far.

Kristof

Thank you very much for joining us and for doing this together with us, was a fascinating discussion. I took one of Ruth Malan’s courses, on recommendation of Marc. So I, the world of complexity-aware architects has started to open for me. But there’s still so much to learn. There’s, there’s a lot of, a lot of methodologies that you were talking about that I’ve heard references to, but I haven’t actually seen them in action yet. So, there’s so much to learn, really, really interesting things.

Kenny

Yeah. And I love, if there’s one person to follow on Twitter, it’s Ruth Malan because she’s just giving you an RSS stream of all the new stuff that’s coming in. And she’s so knowledgeable. So I learned a lot from her so far.

Kristof

Thank you very much, Kenny. It was an absolute pleasure.

Kenny

Yeah. Thank you for inviting me. I really enjoyed the conversation.

Newsletter

Articles on devportals, DX and API docs, event recaps, webinars, and more. Sign up to be up to date with the latest trends and best practices.

 

Subscribe