When the Smartest Person on the Team Becomes the Biggest Bottleneck — And Explodes in a Meeting | Mukhtar Kadiri

Summary

---

Podcast Summary

Episode Overview

Podcast: Scrum Master Toolbox Podcast
Host: Vasco Duarte
Guest: Mukhtar Kadiri (Technical Project Manager, Scrum Master)
Episode Title: When the Smartest Person on the Team Becomes the Biggest Bottleneck — And Explodes in a Meeting
Release Date: May 12, 2026
Theme:
This episode dives into the dynamics of high-performing but dysfunctional Agile teams, specifically exploring what happens when a team’s “smartest” member becomes a bottleneck and how leadership and effective communication can shift destructive patterns into productive momentum. Mukhtar Kadiri shares a real-world story from his experience in the healthcare software industry, discussing human factors, team structure, the value of one-on-ones, and how trust is built (or broken) within Agile teams.

---

Key Discussion Points & Insights

1. The Books That Inspired Mukhtar’s Project Management Career

• [01:21 – 03:02]
  • Mukhtar explains his organic entry into project management, highlighting the importance of hands-on experience before formal learning.
  • Book Recommendations:
    • PMBOK (for PMP preparation): Helped “crystallize” prior experience into formal knowledge.
    • HBR Project Management Handbook by Antonio Nieto:
      “I really like that there was substance to it…it gave different ways of handling some common challenges.” (03:02, C)

2. Case Study: Dysfunction in a High-tech Healthcare Team

• [03:32 – 07:35]

  • Context:

    • Project in a healthcare software organization, implementing new technology.
    • The team (with product manager, multiple engineers, head of engineering/architect) was missing deadlines, marked by chaos and finger-pointing.
    • Mukhtar was brought in as a technical project manager to “figure things out.”

  • Diagnosis Phase:

    • Conducted one-on-ones with stakeholders to gather perspectives.
    • Identified a toxic culture of blame between engineering and product management.
    • Initiated regular team structures and rituals (“Let’s meet every week…let’s have rituals.”) as a first stabilizing step.

  • Key Moment:

    • In a team meeting, the head of engineering (the team’s perceived “smartest person”) bursts out in frustration, yelling publicly.
    • “It was a bit shocking because this was happening not in a one on one, but in public.” (05:21, C)
    • Mukhtar realized: This centralized reliance was a core issue—making the “smartest” person a bottleneck.

  • Resolution Approach:

    • Held a one-on-one with the head of engineering to understand and defuse the situation.
    • Learned that this leader felt overwhelming pressure: “He was just frustrated that the team was too reliant on him…just too much on me.” (paraphrased)
    • Encouraged him to acknowledge that “yelling is not going to help.”
    • Once this leader changed approach and stopped exploding in meetings, team morale immediately improved and momentum increased.

  • Insight:

    • “A lot of times the problem is not necessarily technical… the problem was really a human problem.” (07:13, C)
    • Removing human obstacles (trust, unspoken grievances) allowed project flow to resume.

3. When Technical Problems Are Actually People Problems

• [07:35 – 09:07]
  • Host Vasco highlights a favorite principle:
    • “No matter how much how it may look at first, it’s always a people problem.” (07:40, B)
  • Even breakdowns in delivery or team ‘implosions’ are rarely rooted in technical complexity, but in unresolved or unspeakable interpersonal issues.

4. Surfacing “Forbidden” Topics & Building Trust through One-on-Ones

• [09:07 – 11:11]
  • “That’s why I’m a huge fan of one-on-ones.” (09:07, C)
  • Mukhtar’s strategy:
    • Recurring, short one-on-ones with as many people as possible.
    • These conversations act as a “pressure valve” for frustrations, preventing public explosions.
      • “Your one-on-one is a pressure valve that releases all so it doesn’t come and people don’t explode in the meetings because like that sometimes can be irreparable.” (09:44, C)
    • Building trust, particularly in technical teams skeptical of ‘project management bureaucracy’:
      • “One-on-ones really help with building that relationship…you’re accelerating that process.” (10:40, C)
    • Regular check-ins function as both early warning and relationship-building.

5. Notable Quotes & Insights

• “Yelling is not going to help…That little thing was able to create momentum where the team was now self-sufficient.” (06:00, C)
• “Once the group feels a certain way, that’s an uphill battle to reverse…deal with things in a one-on-one.” (10:01, C)
• “One-on-one is a very, very useful approach to navigating all kinds of issues.” (11:11, B)

---

Memorable Moments & Attributed Quotes

| Timestamp | Speaker | Quote/Insight | |-----------|---------|---------------| | 03:02 | Mukhtar | “HBR Project Management Handbook…gave different ways of just handling some common challenges.” | | 05:21 | Mukhtar | “The head of engineering just burst out. He started yelling in a meeting… it was a bit shocking.” | | 07:13 | Mukhtar | “The problem was really a human problem… figuring out the human dynamics just sort of removed the obstacles.” | | 07:40 | Vasco | “No matter how much how it may look at first, it’s always a people problem.” | | 09:44 | Mukhtar | “Your one-on-one is a pressure valve that releases all so it doesn’t come and people don’t explode in the meetings.” | | 10:40 | Mukhtar | “One-on-ones really help with building that relationship…you’re accelerating that process.” |

---

Important Segments & Timestamps

• [01:21] Book recommendation & PMP experience
• [03:32] Team context & conflict diagnosis
• [05:21] The bottleneck explodes in a meeting
• [06:45] Human problems vs technical issues
• [07:40] “It’s always a people problem.”
• [09:07] Using one-on-ones to surface and defuse issues
• [10:40] Building trust and early warnings through 1:1s

---

Takeaways for Agile Practitioners

• Human dynamics often underlie technical challenges in teams.
• Establishing routines and structure can stabilize chaos, but surfacing unspoken issues is crucial.
• Direct, private communication (like one-on-ones) is a powerful tool for both diagnosis and trust-building.
• The “smartest” person isn’t the solution if they’re also the bottleneck; distributed ownership is key.
• Bottlenecks driven by over-reliance can turn competent individuals into points of failure and team morale breakers.
• Prevent breakdowns by creating “pressure valve” systems—open, safe spaces for venting and honest discussion.

---

This episode is a powerful reminder that successful agile teams rely first and foremost on honest, empathetic communication—because every technical problem is, at its core, a people problem.

Transcript

[A]

Hey there, agile adventurer, just a quick question. What if, for the price of 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 sleep, lob clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasco, your Scrum Master Toolbox podcast. No, this is not a drill. It's the 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 Team Tuesday. This week we have with us Mukhtar Kadiri. Hey, Mukhtar. Welcome back.

[C]

Thank you, thank you for having me.

[B]

So Tuesday is Team Tuesday, of course, here on the podcast. But before we dive into the team story, share with us, what's the book that most inspired you in your career as a Scrum Master?

[C]

Yeah, so for me, in my project management career, I would say because I sort of stumbled into project management, I didn't really start by reading, right. So I started by just, I didn't, I was leading projects before I knew, you know, I was managing projects. So a lot of my knowledge came from hands on practical experience and just learning from mistakes. But then when I studied for the pmp, a lot of things that I knew became crystallized for me.

[B]

Right.

[C]

You know, like, you know, there were frameworks and methodologies, you know, associated with things that I sort of knew. So that was really helpful. Like, so I think I took my PMP maybe after seven years, you know, of leading projects. So prepare for the PMP was, was very helpful. And the book that really helped me then was the retail book, right? But later on I started to read more, you know, about Project manager. And one that really stands out to me is the HBR Harvard Business Review Project Management Handbook by Antonio Nieto. So why I really like that book is that I think a lot of project management books, like, I can read them and it's almost like I'm not really learning anything new. But this, I really like that there was substance to it, you know, so I really like that. And I really liked the breadth and also it also gave maybe different ways of just handling some common challenges in the project management world. So that would be my recommendation.

[B]

Absolutely. And we'll put the link to all of those in the show, notes for people to go and check them out. Thank you for sharing that, Mukhtar. And of course now we turn our attention to the teams and how sometimes they become their own worst enemies. So we want you to tell us the story of a team, the context, so that we know what kind of project are they participating in, how big is the team, and then what? Walk us through how maybe some patterns or behaviors developed over time and became self destructive for the team.

[C]

Yeah, so one project that comes to mind now was this particular project. We were working on cutting edge technology. This was in the software healthcare space. And you know, I don't want to share, you know, because of confidential reason, but basically this was, it was going to be like implementing a new technology in, in the software space. And this was in, in healthcare. So basically this team was moving along on this project, but they couldn't quite hit any of their milestones. It just felt like there was just a lot of chaos. So this team had a product manager, engineering team and the head of engineering, like, you know, like an architect, you know, leading the engineering, the engineering team. So, you know, this was supposed to be a team that was, I guess self sustaining but they couldn't quite hit their muscles. So they brought me in, I was a technical project manager then and they brought me in like, what's going. Just help us figure things out and just drive us to where we need to get to. So, you know, like I mentioned before, one of the first things is just meeting people one on one is the different stakeholders understanding like what's really going on, where do we want to be, what is the problem? And this one was particularly difficult because there was a lot of finger pointing, like you know, product pointing fingers or engineering, engineering, you know, and then, you know, or the product manager doesn't really know what they're doing, the engineering doesn't, you know. So anyway, met all these people and then started to formulate a plan for us to move forward.

[B]

Right.

[C]

But this was still early on, I wasn't quite sure because like sometimes it's just a lot of chaos. One of the first things that you just want to do is just have some structure. Okay, let's meet every week. That's progress. We're not even talking about the plan yet, but let's just have rituals, you know. But then in one meeting the head of engineering just burst out like he, he started yelling in a meeting like he was frustrated. And like I, it was, it was a bit shocking because like this was happening not, not in a one on one setting but in public, right. And then I was like, okay, this is probably one of the main reasons, you know. So I ended up speaking to him one on one and like, you know, what's, what's going on? And I up finding out that he was very frustrated that a lot of the team was depending on him because he is like, you know, you have these people in, in, in companies that they're very smart and a lot of things like their bottlenecks, a lot of things just depend on them, right? So this was just one project. He had other things, you know, that he was also. So he was just frustrated that the team was not, was too reliant on him and he ended up coming out in that way. So you know, I, in a one on one, I was like, okay, your name is on this project. Yelling is not going to help, right. So he ended up like leveling with me and sort of seeing that this is not the best way forward. Now long story short, he ended up trying to change his approach and everything and with that with him just really just trying to not lose it in, in the meeting like that just started to improve team morale, right? So in addition with now adding structure and people just feel like okay, we have this low hanging fruit, let's try and get there. And then that result in, in, in in momentum. And then, you know, so, so just that little thing like that was able to create momentum where it's like okay, I could take a step back and the team was now self sufficient. Now what I really learned from there is a lot of times the problem is not necessarily technical. So this was a cutting edge. Technology was complex, but the problem was really a human problem. People just felt like, all right, it's either I don't trust this person or I don't understand why this person is yelling at me and all of that. So just figuring out the problem, the human dynamics and the human problem that just sort of removed the obstacles and just make the project flow, if that makes sense.

[B]

So that highlights one of the, one of my favorite let's call it project phrases. It's not only project, it's pretty much all kinds of large systems or large organizations phrase. And it goes like this. No matter how much how it may look at first, it's always a people problem. And your story is a great Reminder then when teams fail, whether they don't deliver or they just implode, self destruct, disappear, disband, that can also happen. It's always because of people. It's not because of technology. And sometimes it's because they can't even talk about what is the problem, right? Like this person, this story you just shared is a person that got driven to a point of so much frustration that they just had to explode because they, they were not, they had not been able to this point to express the fact that hey, this is too much on me. I can't take this team. Help me out, right? Like figure out how to take more ownership, how to unload some of this load that you're putting on my back. Right. And these days when you, when you work with teams, how do you try to kind of surface this? But it's called them forbidden topics, right? Like topics we can't talk about even if it's only implicitly so.

[C]

Yeah, yeah, yeah. So that's why I'm a huge fan of one on one. So one of the things that I do when I start my project is that I have regular recurring one on one meetings. It could be 15 minutes every week like with, you know, and it varies in terms of frequency. With some people it's twice a week. With some people it's every week and some people it's every two weeks with. I try to do this with as many people as possible, you know, while still protecting my time and all of that. Because the one on ones, so many things. So not only do you get like, you know, for many topics, like you mentioned, things left unsaid in meetings, but it's also an avenue, it's like a venting like a lot of the pent up things that people can't say they get to release. It's like a pressure valve. Your one on one is a pressure valve that releases all so that it doesn't come and people don't explode in the meetings because like that sometimes can be irreparable.

[B]

Right.

[C]

You know, because you're going to affect the team overall. And once the group feels a certain way like that's, that's an uphill battle to reverse as opposed to dealing with things in a one on one. So for me one on ones are like, I swear by one on one.

[B]

So yeah, it's almost like an early warning system. Right, right, right, right, right.

[C]

And not only that, you also build trust. So it's not just, okay, let me just, let me just see what the status is. But because also another thing that I know we PMS face is resistance from like engineering and product. Like, you know, what value are you bringing?

[B]

Yeah, this is all process bureaucracy.

[C]

Exactly. Yeah. You know, like I just, I just want to do my job. I don't want to get any more meetings. But so one on ones really help with building like, you know, building that relationship. Because you can't, I mean, in a meeting, the more they see you. In a group meeting, the more they see you. Yes. The more that will become familiar and the more you will start like building a relationship with them. But with one on ones it's like you're accelerating that process. Right. So yeah, I really.

[B]

One on one is a very, very useful approach to navigating all kinds of issues. So great recommendation.

[A]

Thank you for sharing that, Mukhtar. Alright, 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 [e-mail] membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community.

[C]

Slack.

[B]

We really hope you liked our show. And if you did, why not rate

[A]

this podcast on Stitcher or itunes, Share

[B]

this podcast and let other Scrum masters

[A]

know about this valuable resource for their work. Remember that sharing is caring.