Why System Design Beats Individual Coaching Every Time | Karim Harbott

Summary

Podcast Summary

Scrum Master Toolbox Podcast

Episode: Why System Design Beats Individual Coaching Every Time
Guest: Karim Harbott
Host: Vasco Duarte
Release Date: November 4, 2025

---

Episode Overview

This episode focuses on how systemic factors within organizations are often the true root cause of team dysfunctions—far more than individual or team-level failings. Karim Harbott, a leading Agile coach and Less (Large Scale Scrum) trainer, joins Vasco Duarte to share compelling stories and actionable insights about system-centered problem solving. Rather than blaming individuals, Karim advocates for designing better environments that enable teams to thrive.

---

Key Discussion Points & Insights

1. Books and Influences on the Agile Journey

• Karim’s Most Impactful Book
  Karim discusses the profound impact that Scaling Lean & Agile Development by Craig Larman and Bas Vodde (2008) had on his career.

  • Introduced systems thinking, systems modeling, queuing theory, feature teams, and holistic approaches to scaling agility.
  • Emphasized principles that later became the foundation of the LeSS framework.
  • Led to a deeper understanding of complex systems and cognitive biases.

  "That book contributed more to my knowledge and experience than any other book...I felt like that book contributed more to my knowledge and experience than any other book. So I started implementing those things."
  — Karim Harbott [04:07]

• Other Book Mentions

  • Mike Cohn’s "User Stories Applied" and "Agile Estimating and Planning" as early-career essentials.

  "I’d answer it like I was an expert. And really I just read it like two hours ago. So thank you, Mike, for keeping me in my job."
  — Karim Harbott [01:55]

2. The Importance of System Design Over Individual Coaching

• Teams React to Their Environment

  • Karim argues most issues are symptoms of a poorly designed system rather than personal failures.
  • Changing the surrounding system yields disproportionate positive effects compared to trying to change people directly.
  • Karim channels thought leaders like Jocko Willink (Extreme Ownership: “No bad teams, just bad leaders”) and David Marquet (“change the environment, not the people”).

  "Individuals and teams do the best job they can do in the system that’s been designed for them...if what we’re seeing are anti-patterns, our behaviors that we don’t want to see...it’s more useful to look at the system that’s been designed around them."
  — Karim Harbott [06:37]

3. Real-World Story: Systemic Anti-Patterns at a Large Bank

• The Dysfunctional Team Case Study

  • Karim recounts coaching teams at a major UK bank where one team struggled with excessive bugs and a lack of collaboration between developers and testers.
  • Retrospectives and attempts at improved collaboration (Behavior Driven Development/specification by example) initially failed.

• Root Cause: Perverse Incentives

  • Developers and testers were from different vendor companies based in different locations.
  • Worse, payment was tied to per-defect metrics: testers were paid per bug found, developers per bug fixed.
  • This led to rational but adversarial behavior, incentivizing more defects and reinforcing silos.

  "...the testers were from one company, the developers were from another company...The testers were paid by the number of defects they found and then the developers were paid by the number of defects they fixed. Right. So you can't make this up...Who's written this contract? This is a terrible idea."
  — Karim Harbott [09:27]

• The Turnaround: Systemic Solutions

  • Structure reorganized so testers and developers from the same company formed unified teams.
  • Enabled true collaboration—shared scenarios were created, reducing misunderstandings and drastically lowering defects.
  • After ~8 months, productivity improved by an estimated 30-40% as teams could focus on delivering new features instead of rework.

  "We finally got to the point where the team was sitting together...and then of course, when they came to test, they found far fewer defects...Imagine if you could be 30, 40% more productive, right? Just that tweak."
  — Karim Harbott [11:19]

4. The Principle: Bad Systems Defeat Good People

• Blame the System, Not the Individual

  • Bad systems demotivate good people; the right environment is essential for high performance.
  • It’s nearly impossible for any team to sustainably excel in a dysfunctional system.

  "A bad system will always beat down a good person. Every time."
  — Vasco Duarte [12:17]

  "It's very hard to be a high performing team in a dysfunctional system, right? Yeah, absolutely."
  — Karim Harbott [12:54]

---

Notable Quotes & Memorable Moments

• Book Impact and Systemic Roots

  "I love that book. I still have my copy. I don't have many physical books anymore, but I still have this one because it's been so impactful."
  — Karim Harbott [05:25]

• Kafkaesque Contracting

  "I think Kafka wrote the contract."
  — Vasco Duarte [10:35]

• Metrics Gone Wrong

  "They were doing what was reasonable for them to do...it was entirely rational behavior."
  — Karim Harbott [10:43]

---

Timestamps for Major Segments

• [01:20] Karim’s influential books and learning journey
• [06:35] Introduction of the root cause lens: systems, not individuals
• [09:00] Dysfunctional incentive structures in team contracts
• [11:19] System redesign, improved collaboration, and dramatic productivity gains
• [12:17] The principle: Bad systems stifle good people
• [13:06] Final reflections on systemic change and team performance

---

Tone and Language

• The episode maintains a conversational, candid, and practical tone, with humor and relatable analogies.
• Karim is open about past mistakes and learnings, making the content accessible and credible for Scrum Masters and coaches.

---

Takeaway

For Scrum Masters and Agile Coaches: Focus on systemic conditions—not just individual coaching—to unlock team performance. Examine how contracts, organizational design, incentives, and culture shape team behaviors, and tackle root causes at the system level for lasting Agile transformation.

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 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.

[A]

Welcome to our team Tuesday. This week with us we have Karim Arbot. Hey, Karim, welcome back.

[B]

Thank you. Good to be here again.

[A]

So, Karim, on Tuesdays we talk about teams and we'll talk about teams in a second. But before we go there, what's the book that most inspired you in your career as a Scrum Master?

[B]

Yeah, that's a great question. And I get that question a lot. Before I give you the answer, I'm going to call out some books that were very, very helpful for me when I became a new Scrum Master. I remember I had my first grandmaster role. I was doing a long commute and so I was on the tube, as we call it here in the uk, the underground, the Metro. And I had a lot of time to read and I had to because I didn't know what I was doing. And just to shout out to Mike Cohn's books that User Stories Applied and Agile Estimating and Planning, because the number of times I would read a chapter on the way to work and then somebody would ask a question and I'd answer it like I was an expert. And really I just read it like two hours ago. So thank you, Mike, for keeping me in my job. Happened a few times and people thought I was a lot better than I was because of those books. Oh, we need to split these user stories. I can help you with that. So they were very useful for me, but they're not the books I'm going to pick because they are quite obvious choices because they are so great. I'm going to pick a book that came out in 2008 and it's scaling, Lean and Agile Development by Craig Lahmann and Bus Voder. And the reason I love this book, I found this book by accident again, early days maybe 2008, nine early days in my journey. One it just, you know when the book just resonates with you, you're reading it and you're like, yes, I like this. I like that. The way they write, the tools that they talked about, they went way beyond the things I was talking about. They started, they introduced me in that book to systems thinking, which is incredibly powerful systems modeling. They introduced me to the queuing theory, they introduced me to the concept of feature teams and why that's so important and of course the principles for scaling, lean and agile development. And it was very timely because at that point I was having to work with kind of multiple teams, right? As we go into sort of 2010, 11, I've now got sort of three, four, five teams collaborating to build the product. And I don't know if this was pre safe. It was definitely pre less. There wasn't a lot of guidance around scaling or multiple team agile as I prefer to call it. And that book was absolute gold. So I took all of those tools, I took all of the advice. By the way, there's like a million references at the end of each chapter. I exaggerate slightly, probably about sort of dozen. And I went off and I read those books and it just broadened my horizons so, so far beyond the agile world. I felt like that book contributed more to my knowledge and experience than any other book. So I started implementing those things that they were suggesting in there, which is basically the patterns that they created at Nokia in sort of 2005 when they were working there. And I found that they worked incredibly well. So when Less Large Scale scrum was formalized 2015, I looked at it and I thought, yes, this is basically what I've been doing. I mean it's obviously what I've been doing because I've been read the book from the creators, right? So when I, when I got to meet Craig and Bus, who are both incredibly, incredibly nice and generous with their time and have shared a lot of knowledge with me, I very quickly became a less trainer and I very quickly began working under the large scale Scrum framework. But I think everything that led up to that was down to that book, me reading that in about 2009 and being exposed to the holistic approach to scaling rather than just the standard team stuff, right? And I think those thinking tools, understanding our cognitive biases understanding how complex systems work, understanding how to minimize cues. This is stuff I hadn't come across at this point and it just blew my mind a little bit. I love that book. I still have my copy. I don't have many physical books anymore, but I still have this one because it's been so impactful. Yeah, absolutely.

[A]

And by the way, we have an episode with Bas Vode, so for those interested, check it out. He introduces less and why less was the approach that they took way back when at Nokia Networks. It's good to mention that because I was on the other side, on the Nokia mobile phone side and we were trying to adopt safe while the Nokia networks was adopting what is now less. At the time it wasn't called less, it was just scaled agile. But of course we do this. We read the books, we learn because we want to help teams succeed. But sometimes teams kind of create their own problems. So today's Team Tuesday. Karim. So we want to explore a story of a team and maybe how they develop these ways of interacting, these behaviors, these patterns that maybe started small in the beginning but eventually grew and became a problem for that team. Tell us that story.

[B]

Well, I'm going to slightly defend the team in my answer because I believe, and I've come to believe this over the years, that individuals and teams do the best job they can do in the system that's been designed for them to do the work in the context in which they're operating. So if what we're seeing are anti patterns, our behaviors that we don't want to see or are exhibiting a lack of results, then for me it's less useful to look at the people and look at the teams and it's more useful to look at the system that's been designed around them. One, because you can't change people, you can change yourself, you can't change other people. And two, because you can change the system and that's going to have a disproportionate, disproportionate effect. So whenever I've seen this, it's always been system changes that, that have, that have resolved it. And, and I'll give you, I'll give you an example of one, by the way, I've been very influenced by Leif Babin and Jocko Willink is a, there's a great book called Extreme Ownership. No bad teams, just bad leaders. They say that or I like to change that to leadership. And, and you mentioned David Marquet yesterday. And I think that, that he's another person who's A big advocate of change the environment, not the people. So I'm going to take you back probably to somewhere around 2011 12. I'm a sort of scrum master, sort of agile coach, trying to scale. I'm at a big UK retail bank now. Big messy sort of developments going on and I've got a few teams with I'm working, but one of them in particular is exhibiting a crazy amount of defects in the Sprint. Like I'm talking, we were spending 30, 40% of the sprint testing, fixing, testing, fixing, right? Now you think of all of the productivity you're losing by spending time finding and fixing defects, right? And I couldn't work this out. I've never seen so many defects before in a team. So I'm a big fan of the technique specification by example or behavior driven development, whichever version or flavor you like. And a shout out to Goiko Adzic, the creator of that from back in the day. So I decided, let's have a session in the retrospective. Let's try and get developers and testers collaborating more because they're really not at the moment, developers are building in a silo, testers are testing in a silo, and it's back in its fourth and it's back and it's forth. It didn't help that they were at different, different ends of Pune out in India, right? They were in different locations, right? So this didn't help. So I was like, look, let's get together, let's have some chats early on and let's understand what we're building, let's create some scenarios, let's get a shared understanding before a line of code is written so that we can reduce and in my experience, you can reduce sort of 80, 90% of the defects if you use these techniques well, especially in non trivial software development. I thought, this has worked before, I think this is going to work brilliantly. And I had such stony faces, they're looking at me like, I don't want to do this. And I'm thinking, why would you not want to reduce defects? Like, is it me? Do you like defects? Do you enjoy them? I don't understand. And so basically I had no traction at all. And it was by chance I was talking to someone in a different team. And what I realized is the testers were from one company, the developers were from another company, which is why they went in the same office. And it gets worse. The testers were paid by the number of defects they found and then the developers were paid by the number of defects they fixed. Right. So you can't make this up. And I was thinking to myself, who's written this contract? This is a terrible idea.

[A]

I think Kafka wrote the contract.

[B]

What is going on? Right. So this is an example of how basically team wasn't talking, team wasn't collaborating negative behaviors, but actually it was entirely rational behavior. They were doing what was reasonable for them to do. And so we had to spend months going back and we actually couldn't change the suppliers. But what we did is we. We got testers and developers from one company, testers and developers from another company. So we still had the same number of people from each company, but we actually just had like one organization did one team, one did another team, and now they can chat to each other. And we did. I mean, this took about eight months. It took about eight months. We finally got to the point where the team was sitting together. They don't even have to be sitting together. Right? But they were talking and they were coming up with scenarios. They were ironing out those misunderstandings before they wrote a line of code. And then of course, when they came to test, they found far fewer defects. This is incredibly important because now that 30, 40% of the sprint that was spent doing all the test, fix, retest, retest, refix, that was just building new features or collaborating with customers or something else that's valuable. Imagine if you could be 30, 40% more productive, right? Just that tweak.

[A]

Easily 30% more productive. I mean, can you think about it? Just the amount of time that is spent reading and writing emails and then doing the investigation to understand what the hell the email meant in the first place. Let's not forget that most humans are not very good at explaining themselves in a written format. Right? Like without this, you know, interaction, physical interaction where you see each other and point at things and do whiteboarding and whatever. That is such a great story that illustrates so well how a bad system will always beat down a good person. Every time.

[B]

And I see it, and sometimes it's more subtle, people say, oh, my team just isn't motivated. And I was like, well, why are you hiring demotivated people? It's like, oh, we're not. It's like, okay, then you're demotivating them somehow, right? So stop doing that.

[A]

Right.

[B]

And what is it that you're doing that's leading to that behavior? It's always something. The culture and the systems and the governance is the problem. So when we address those, I think it's incredibly important, but you can't. It's very hard to be a high performing team in a dysfunctional system, right? Yeah, absolutely.

[A]

Great story. Thank you for sharing that. Karim.

[B]

No worries.

[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, 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. 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.