
Loading summary
A
Hey there, agile adventurer, just a quick question.
B
What if, for the price of a
A
fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.
B
Hello everybody. Welcome to our Wednesday, the big challenge question of the week. And Mukhtar Kadiri is with us this week. Mukhtar, welcome back.
C
Thank you. Thank you, Vasko.
B
So today's Wednesday, of course, and on Wednesdays we famously do the coaching conversation where we explore a topic together. It's typically a challenge that we are facing and then we look at what is going on, what's the context around it, but also what are options that we have to take action and eventually talk about. How could we design an experiment around taking action for that challenge? So let's dive into it. Mukhtar, what topic do you bring to us this week?
C
Okay, so I'm going to choose a topic. So this was a project that I led a program that I, that I was a part of a while back and this was a, an M and a project emergent acquisition. So this company, they were the dominant player in their space in the industry and but they had a gap in the market. So there were two other companies that were fulfilling this gap and then they decided to buy both companies roughly around the same time. Now the thing is that these two companies, so these are all software companies by the way. So these two companies that they bought, company A and company B, there was a lot of overlap with their solution because they were solving the same problems, but there were also differences. So one person's company's a strength was companies B's weakness and vice versa. So they decided, okay, they wanted to dominate the market and then they wanted to sort of just by both companies at the same time. So I've been A part of M and A projects, but this was the first time that I was part of an M and A. That was two companies at the same time. So basically three companies. Right? So now the challenge was we can't have three different platforms, right? We need to have one platform. So there is the technical. So, like, how do we get to that platform? What is it going to be? Now, again, you have to keep in mind the politics involved. You know, you have an M and A. People are nervous about M and as and these company A and company B, like, they are, like, their founders are still with them. Like these are people that they started the companies. And then. So you have these people that are
B
like their life personalities, I'm sure.
C
Exactly. And not only that, like, this is your baby.
B
And they probably hated each other because they were competitors.
C
Right, right, right, right, right. And you found. And not only, like, you also founded these companies. So this is like your. Your baby. Right? So now I'm like, in between, I have to sort of. We have to figure out, you know, a solution and bring all of this and have one platform. Right. So this was, this was the challenge,
B
was the name, the code name for the project was that one platform it could have been, right?
C
Yeah, we can use it. We can use it because it's confidential, let's say.
B
Let's use the one platform project.
C
One platform, yeah. So where do you want to take the conversation?
B
All right, so I immediately see a couple of things that could emerge in this kind of context, right? Like there's these strong personalities, at least in two companies. Maybe even the third, I don't know about the third, which was acquiring the others. Then there's the implicit expectation that the founders want their baby to succeed, which means their product is crap, Right? Like take hours. Take hours. And also potentially the responsibility they feel towards their employees. Right. Like, I want my people to still be employed after the merger, Right. Because synergies and all, and you get redundancies. And then of course, there's the whole problem of technically integrating three platforms to bring it into one. Right. So these are just the immediate things that come to mind. What other things were going on there that you witnessed firsthand, Right?
C
Yeah. So that's really. I think that's really astute of you. So there's a technical angle, there's also, you know, like, the personnel angle, and then there's also processes and systems. Right. Because with this system, there's onboarding, you know, the entire, like, go to market. So there are all these things that need to be so they're like there's three of all of these process. Three onboarding processes. So all of these things need to be merged as well. And there is also a lot of these processes are tied to the software itself. So it's not just a technical solution. You need to. So there's that. And then there are also pressures from the market because this merger made big waves in the industry. Right. So there is now the expectation because the market is waiting, like, when are you going to. Like, okay, this was a daring move. When are you going to deliver? Because otherwise they're going to be the laughing stock. Right. So there are all these other pressures as well. So they're all of these things that are sort of happening at the same time. Yeah.
B
So how do you bring them together? What were the things you guys tried out to kind of try to bring all of those things into one platform?
C
Yeah. So, you know, first of all, it's really about identifying, like, who the key players are. Right. So from company A, there will be, you know, the product side engineering, also from the main company. And from company B. Right. So. So now there's also the politics of who is going to like, even. Even. Okay, so one challenge is also coming up with the team. Right. Because, you know, everybody, like this is supposed to be like the big thing, so everybody wants to be there. And then like, what's the hierarchy going to look like? And then what you find out is that people hesitate to make decisions. Right. Because they don't want to. Like, the people that are supposed to make decisions don't want to make because any decision will make somebody else unhappy. So you're also dealing with this as the pm. Like, you're.
B
So there's an uncertainty of the consequences, plus the certainty of potential conflict.
C
Exactly. Yeah. And the leadership, because like the leadership from the company that's doing the acquiring, they were hesitating to make decision. And on top of that, I mean, like, there are also other things they're figuring out as well. Like, you know, because bringing this company together, like, they're also other things that they're figuring out and also still trying to make sure that the company is making money. So it's not like they were just sitting on their thumbs, but there is that. Because it's also painful to be able to. Because any decision you make will make somebody unhappy. So I know there's this human instinct to not want to delay the decision. So that was going on. And in the midst of all of this, the teams were really unhappy. So we lost many people Many people left, they're like, I can't deal with this know. So morale was low. You know, a lot of people were living. So now one of the things that we did, so we assembled the team and then it's now about, okay, what's going to be the technical solution? Right? So it's going to be, all right, is it either company A will be the dominant platform and then, you know, company B will retire, or company B will be the dominant platform. We retire company A or we create this new platform and then we retire. You know, both companies, you know, so we had all these options. And I would say that one of the mistakes that we made and something that I learned is because sometimes when there's just a lot of chaos, a lot of moving parts, it's difficult to really understand what the problem is. Right? Because it's like, okay, is there really a problem here or are you speaking from a point of self preservation, or is this from politics? It's so difficult to understand what's going on here. But I would say that one thing that I've learned in retrospect, I think I heard this from a tech leader. A lot of times, conflict arise because people don't understand each other.
B
Misunderstanding.
C
Yeah, yeah, they don't understand each other. So the first thing that you need to do is to make sure that they understand each other. Right? So, you know, person from company A, I know you don't. You don't necessarily agree, but you understand what. And I think this is how I see my role as a pm. Like, I'm not necessarily going to make the decision, like, that's not my job, but I need to make sure that you all understand each other. So if you articulate that you understand it and you still disagree, then we escalate. So I think that if I had done that, like, if we agree and then if we understand each other and then we disagree, we escalate. If we're not going to escalate prematurely until we make sure that we all understand each other. So I think, like, that would have helped solve a lot of the pain.
B
So talking to Scrum masters and agile coaches and team leads out there, listening to this podcast right now, how would you go about explaining what that means? Like, how would I know if they understand each other? I mean, they're using the same words. Isn't that enough?
C
Yeah. And this is also tough as well, because, like, a lot of times, you know, it can be a very technical conversation. Right. So. So, yeah, I mean, I'm not going to pretend and say that, yeah, it's, it's easy. But I think, I think that just really trying to. So maybe some of this will come from experience. But when you're in a meeting, you can tell when people are sort of talking past each other, right? So if you're seeing that like that happening a lot, it's either, okay, maybe let's do a workshop. Like forget, we're not going to do a one hour meeting. Let's just full on site, let's just come here. You present, you know, to the other person, the other person. And then when we see that we understand, you know, the other person's perspective that you know, and we still disagree, then we can, we can escalate. But I think, yeah, to answer your question, it's not. Yeah, I don't know if they say one, if there's a, if there's a one single solution. Because like sometimes.
B
So from my experience in coaching, one of the things that very often happens is that we tend to try to force a decision because we have this feeling that we don't have time to argue, right? Like that's not the only reason, but that's one of the triggers, right? Like look, you know, it's five minutes to the end of the meeting, we need a decision. Like we don't have time to argue. I'm going to force the decision, right? So like one thing that works very well for me is in coaching settings is to create the feeling of time abundance, right? Like if you get a feeling that, okay, this discussion will take an hour, reserve half a day. Because you don't want anyone to feel rushed, right? Because rushing immediately creates walls. Immediately. And then the other you already mentioned is to get the reality or the situation presented from all sides. No judgment, just clarifying questions. What do you mean by when that happens? How have you solved it? Like that type of question, like clarifying question. And then the third step for me is always name the disagreement. Because if you don't name the disagreement, all you have is the emotion, right? Like I'm angry at you because you don't agree with me. Well, no, name the disagreement, right? Like I don't agree with you in this particular affirmation. Okay, so what is the statement and what is the disagreeing statement? Right? Like for example, our database should serve results in 5 milliseconds. No, our database should serve results in 1 millisecond. That's a disagreement. You kind of name the disagreement because then it's all trade offs. And, and one of the things that at least in my experience with engineers, everybody accepts that we have trade offs. Everybody accepts. We may not agree on the trade off decision, but we accept there are trade offs. So if we can name what trade off we are trying to navigate, then we can start looking at multiple options. And then I think the final secret tool that I always use is we always find a third solution. Let's imagine there are two people disagreeing. One has one opinion, the other has another opinion. You always find a third solution or a fourth or a fifth, whatever, but one that doesn't come from the original two positions. Right. And the reason for that is co creation. Because when I create with you, I'm committed to it as much as you are, but if I create it alone, then I need to convince you to come to my side or you need to do the same. Right. So that's what I'm thinking. How does that sound to you?
C
Yeah, no, no, I think that tracks the one thing that, you know, just to add a finer point to it, I think there's also the thing of one side articulating the other person's perspective. Right. Because when you do that, like something really important. But it's like, okay, I feel like you're, you're actually hearing me, you know, and so even in that, like that just makes a lot of tension dissipate, you know, but if you now do that and then there's still disagreement, then, you know, that's when, okay, let's, let's escalate this.
B
Yeah, so, so basically still manning the other person's argument. Right? Like I'm going to describe your argument in a way that defends it as real and that's valid. Then I'm going to say, okay, this is valid. And then these are the aspects that I care about. They are not necessarily counter, they're just exposition. I really like that approach because of that thing that you just said, which is critical when there are disagreements, is that everybody needs to feel heard. And that's where the agreement starts, when everybody felt heard.
C
Right, right. And a lot of times, like, you know, it's in a lot of cases, like you are not going to have a compromise. That's why you have this concept of disagreeable commit. Right. And I've seen in healthy culture where it's like, okay, this is not my opinion, but I'm going to commit if this is the decision that has been made. And I think you can get that kind of commitment only after the person has felt hurt, because otherwise the person would just be resentful.
B
And then I would even add the thing you mentioned on Monday, which is this. Define success. Because it isn't the decision that is the end point. The decision is the starting point. We still need to make sure that whatever we do to implement the decision leads to a successful outcome.
C
Sure.
B
Absolutely. Great conversation. Thank you for sharing that with us. Mukta.
C
No, that was. That was fun.
A
All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing Agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books. And if you're into no Estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community.
B
Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.
Host: Vasco Duarte
Guest: Mukhtar Kadiri
Date: May 13, 2026
This episode dives deep into the real-world challenges Mukhtar Kadiri faced as a program leader during a complex merger and acquisition (M&A). The focus is on merging three software companies into a single platform, navigating intense founder politics, leadership indecision, and the fundamental need for mutual understanding before successful technical or organizational integration can occur. The episode is packed with practical insights for Scrum Masters, Agile Coaches, and leaders driving tough cross-company transformations.
[01:52 – 04:44]
[04:08 – 05:17]
[05:17 – 06:12]
[06:21 – 07:25]
[07:40 – 09:20]
[09:20 – 10:05]
[10:05 – 15:37]
[15:37 – 15:55]
| Timestamp | Segment | |-----------|-------------------------------------------------------------| | 01:52 | Merger context and initial challenge | | 04:08 | Founder personalities and the politics of integration | | 05:17 | The multi-dimensional nature of merging companies | | 06:21 | The politics of choosing "key players" & decision paralysis| | 07:40 | Team morale and mounting attrition | | 08:50 | Technical solution options | | 09:20 | The importance of mutual understanding | | 10:05 | How to recognize real understanding in discussions | | 12:15 | The value of unhurried, deep conversations | | 13:05 | Naming the disagreement to depersonalize conflict | | 14:03 | Steel manning and its effect on tension | | 15:37 | Defining success as part of the decision process |
This episode is a masterclass in agile leadership during high-stakes organizational change—vulnerable, practical, and directly relevant to anyone facilitating complex, multi-team initiatives.