
Alex Sloley: When Toxic Leadership Creates Teams That Self-Destruct Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: . "They would take notes at...
Loading summary
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. Welcome to our Team Tuesday. This week we have back Alex Slowly. Hey, Alex, welcome back.
C
Thank you. Good to be here.
B
So Team Tuesday, of course, is where we talk about teams, but as tradition goes, we first hear about the book that most inspired you in your career as a Scrum Master. Alex.
C
Okay. You know, I was thinking about this the other day, and it's a book I constantly think of. And I've been thinking of this book for years. I'm not sure I would call it that. It like, inspired me because the book is the Goal by Goldbratt. And the reason I'm constantly thinking about this book, the Goal, which I first read around 2012, it's like, if you go through an MBA program, a lot of MBAs, this is like standard reading. But the reason I think about this book a lot is because sometimes when I'm in my bed late at night and I'm trying to go to sleep, I worry about that book. So rather than inspiring me, it worries me a little. And I'll tell you why it worries me. It's because when I read it, I'm not sure I entirely understood everything that it was trying to say. Like, I read the book and it was a hardcore book for me to read. Like, I really struggled reading that book. Like, it took me like four times as long to read that book than any other book I've read about this particular, like, agile area. And I had to reread it because I was like, okay, I just don't understand what happened here. I've got to reread this entire paragraph again. And I would reread entire sections of that book multiple, multiple times because the concepts were so deep and meaningful. Now I can look back on it and I can say, okay, it talks about toc, or Theory of Constraints. It's got systems thinking type stuff. It talks about optimizing globally versus optimizing locally. But still to this day, I worry that maybe there was something in there that I missed and maybe I really should read it again. I'm not sure. But I also came up with a second book if you want to hear what a second book is, too. If I had to pick one other book that was most influential for me, it would have to be the Scrum Guide. And I read the Scrum Guide, like, all the time. At least once a week, I read the Scrum Guide. And every single time I read it, I'm like, I find a little tidbit that's new. And I'm like, how am I discovering this now? I've been reading this for years, and there's this little nuance in there that I've never truly appreciated. So even though the scrum guide is 15 pages long, it has such deep meaning in it. It's interesting to read and then to contemplate. What I do is I like to read little sections. Like, I might just read the Scrum Master section of the Scrum Guide, and then I'll ask myself, why does it say what it's saying in this little section in the Scrum Guide? Literally, there are things in the Scrum Guide that are described by two sentences. And you gotta put a lot of deep thought into those two sentences. Why? Why? Why? So if you've never read the Scrum Guide, you should totally go to scrumguides.org and read the Scrum Guide and then maybe do something like I do, which is, like, read just one small section, like a day or a week, and ask yourself why as you read it. Because you can get really deep into the wine, like, truly understand, like, the deeper meaning behind.
B
It's funny because it's kind of the same thread for both books, right? Like, it's the text that isn't in the text, right? Like, it's the understanding that is behind the text that is trying to come out through the text. But it's not always easy to grasp at first reading. But also the other thing that, especially the Scrum Guide, I'm sure will be like that for most of us, which is that when you read something before you have experience, it means something. When you read something after you have experience, it means Something else. And then when you read something after you've made many, many, many mistakes that are similar, it will mean something else altogether. So there's an in depth that comes with also experience. Some might call it wisdom perhaps, but definitely experience of going through several situations at the same time and talking about experience and going through same situations at the same time. One of the things we very often don'. Talk about as Scrum masters, that teams actually can create their own problems. Yes, sure, there's influence from the outside, other teams, management, whatever that is, but teams can create their own problems. And that's the story we want to hear from you, Alex, so that we may learn to detect those patterns as they emerge in front of our eyes before they become a problem. So tell us that story, give us a little bit about the context of that team and then walk us through those steps or behaviors that maybe started small but over time became a real problem for the team.
C
Yeah, I mean, I think we've all probably been in a situation where we've seen things go sideways in teams. And one of the gnarly examples that I reflect upon a lot, you know, one of those things that keeps me up at night, like the, like. The goal is I was working with a client at a aviation company around 2018 and it was a small team and for whatever reason we had a PM on that team.
B
PM as project manager or product manager.
C
Project manager, yeah. Not a product manager, a project manager. And the way the project manager engaged with the team was quite toxic. So they would like belittle people in the team in public. They would take notes at every team meeting so that later on they could argue with team members about what they committed to and what they said in meetings. There's a line in the Agile Manifesto about this. Right. Contract negotiation. That's essentially what this person was doing.
B
They were without permission, by the way, contract negotiation without permission, absolutely.
C
And they were using it like a weapon. You know when you're seeing contract negotiation happen in a bad way, when it's used like a weapon. We had one person join the team in the morning and by the end of that day they quit. They lasted less than eight hours on the team because it was. That project manager was so toxic.
B
Wait, wait, wait. If it was that toxic for somebody coming from the inside, the next interesting question is how come the people who were on the inside didn't quit?
C
Also because they were cowed and subdued and dominated by this project manager who would put you down in a room with their written notes and get you to Submit to their authority and their dominance. It got to the point where one of the team members didn't come in to work one day and sent an email to the team. And the email kind of looked like a suicide note. It had that kind of vibe, right? And I had to like, do something about that. So I had to make sure to talk to this person over the phone, make sure that they were, that they were well, that it wasn't a suicide note. And ultimately what ended up happening was one day I was in that team and I was creating slide decks for agile trainings and I was working with the project manager and they looked over at me and they said that my slide deck velocity was too low, that they could create four slides every 15 minutes from my one slide. So they're like comparing slide deck velocities between. And eventually I came to the conclusion that that project manager was so toxic that I couldn't work with that team anymore. My solution was actually to exit that team and I ex at that client. Now I look back and I asked myself, was there anything I could have done? And I don't think so really, but I have reflected on like, in terms of the Scrum values, what was it about that project manager that kind of made me want to go somewhere else? And I think it was. I think it was respect. So if you read the Scrum Guide, one of the Scrum values is respectful. And I urge you to go read the Scrum Guide and look at the Scrum values and reflect on those and how those values, whether you live them or not, could affect your team. And that's my story.
B
And that's an important story. We don't always win, but it's very important to know when you're losing enough that it's better to leave. And that's something we've had here as a theme also in the podcast before. But it's always great to remember that you can't win all of the potential improvement fights that you're involved with. Sometimes the system just takes over and I'm reminded, and I don't know if you know about this or if you ever thought about this, I'm reminded that for a person like that to be accepted within the team, you need two sides of the system to agree that that person brings value in some way. So one is the team, because the team can rebel against that can make their life hell as well. So it's not just one sided. And then the other is that there's an expectation from the manager of that person that they are doing a good job because if that would not be the case, eventually they would be let go as well. So when you think about that, obviously you decided to quit, so you were no longer going to take it anymore. But what do you think about these two other sides, like the team members and the organization or the system around that person as well?
C
Definitely. I came to the conclusion that they were being encouraged to act that way by upper management in that organization. And my conclusion was that they were doing that to control the team and ensure that the team did the work that they were committing to. That whole contract negotiation thing. Which means, you know, did management really trust the team in the first place? I don't think so. What caused it? I don't know. Had trust been broken in the past? I have no idea. But there was definitely no trust in the system, as it were. Management, I think, was encouraging that behavior in terms of the team. They were just completely dominated and submissive. Probably the closest example I can think of is learned helplessness, where people just become used to being helpless and eventually they just submit to that helplessness because they believe that there's nothing they can do to change the situation. And for sure there are organizations where I think they try to adopt agile ways of working for perhaps not the most healthy reasons. And yeah, sometimes I've had to self exit clients where I think they're not really embracing the values that I personally hold dear, which are like this, what I'm doing.
B
Great story. Thank you for sharing that with us, Alex.
C
My pleasure.
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 in question, 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.
B
Free of all of that AI slop you see everywhere.
A
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@scratch 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.
Episode Title: When Toxic Leadership Creates Teams That Self-Destruct
Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Host: Vasco Duarte (Agile Coach, Certified Scrum Master, Certified Product Owner)
Guest: Alex Sloley
Date: October 21, 2025
This episode dives into the destructive impact of toxic leadership on agile teams. Alex Sloley shares a cautionary tale from his experience with a particularly unhealthy team dynamic fostered by an authoritarian project manager. The discussion emphasizes the significance of organizational culture, respect, and the core Scrum values.
"The Goal" by Eliyahu Goldratt:
The Scrum Guide:
Host Reflection:
Team Background:
Toxic Behavior Examples:
Team Impact and Escalation:
Personal Story and Breaking Point:
Notable Quote:
Host Reflection:
Alex’s Analysis:
Learned Helplessness:
On Living Scrum Values:
On Organizational Influence:
On Experience and Learning:
The discussion is candid, thoughtful, and grounded in real, sometimes uncomfortable experience. Both host and guest use humor and humility to convey the gravity of toxic leadership and the importance of upholding Scrum values, especially respect. Listeners are encouraged to be vigilant for signs of dysfunction and to prioritize alignment with their own values, even if that means exiting unsalvageable situations.
Recommended Next Step:
Read (or re-read) the Scrum Guide and reflect on the Scrum values in your current context, especially “respect.” Seek environments where those values are lived, not just claimed.