How Upper Management Can Destroy a High-Performing Team in Minutes | Somya Mehra

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches Episode: How Upper Management Can Destroy a High-Performing Team in Minutes | Somya Mehra Host: Vasco Duarte Guest: Somya Mehra Release Date: August 12, 2025

---

Introduction

In this insightful episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages in a candid conversation with Somya Mehra, an experienced Scrum Master, about the fragile dynamics between upper management and high-performing Agile teams. Titled "How Upper Management Can Destroy a High-Performing Team in Minutes," the episode delves deep into the subtle yet destructive behaviors that can erode team trust and efficiency overnight.

Somya’s Inspiring Journey

Somya begins by sharing her foundational inspiration: the book Agile Retrospectives: Making Good Teams Great by Diana Larsen and Esther Derby. She emphasizes the book's impact on her approach to retrospectives, highlighting its practical frameworks and adaptability beyond traditional Scrum practices.

Somya Mehra [01:36]: "It's not about the format but telling you how to make an effective retro for your team... you can use it anywhere throughout your profession and personal and any part of your life."

The High-Performing Team Before the Incident

Somya recounts her experience working in a startup focused on developing exam evaluation software for universities. Despite being a non-traditional Scrum team, they exhibited strong collaboration, timely deliveries, and effective backlog refinements. The team comprised relatively young developers under a tech lead who was not a part of their immediate team structure.

Somya Mehra [05:05]: "Everything was running on time, and the team was delivering as expected."

The Catalyst: Upper Management’s Intervention

The harmony within the team was disrupted when upper management, including the CEO, expressed concerns over perceived padding in the team's story point estimates. This accusation was communicated to the tech lead and the Scrum Master, setting the stage for conflict.

Vasco Duarte [06:50]: "When you say they started challenging, did they come to a retrospective or did they just make a comment to the team lead?"

The Confrontation and Its Aftermath

During the critical meeting with upper management present, the tech lead unilaterally blamed the developers for inaccurate estimates without seeking their perspective or understanding the context behind the numbers. This public shaming led to a swift breakdown of trust within the team.

Somya Mehra [08:34]: "He just threw the whole devs under the bus. Totally devs."

The CEO's reaction further compounded the issue, undermining the team's credibility and fostering an environment of distrust and fear.

Somya Mehra [08:36]: "Now the team feels like, okay, you can't trust your tech lead... you've lost all your reputation in front of the CEO."

Consequences of Leadership Failure

The incident led to several team members contemplating leaving their roles to protect their professional integrity and mental well-being. Somya reflects on the pivotal role of leadership in either nurturing or dismantling team dynamics.

Somya Mehra [10:05]: "It's the leadership who destroys the team sometimes... you feel helpless and then the team is just gone because you did not show the true leadership when the time was needed."

Lessons Learned: Embracing Servant Leadership

Somya shares crucial lessons from this experience:

1. Empathy in Leadership: Understanding and respecting the unique capacities of each team member is paramount.

   Somya Mehra [11:32]: "If I think like I can do this work in one day, I won't say like the others can do it in one day. It can take five days for them."

2. Advocacy as a Scrum Master: The Scrum Master should defend the team’s integrity and facilitate transparent, constructive dialogues with upper management.

   Somya Mehra [12:00]: "As a Scrum Master, you should have come forward to help your team... explain what you are talking is not being agile."

3. Proactive Communication: Regular, open conversations can prevent misunderstandings and mitigate conflicts before they escalate.

   Vasco Duarte [13:06]: "These are the conversations we should be having every single day... create the opportunity for improvement rather than the opportunity for blaming."

Conclusion

This episode serves as a poignant reminder of the delicate balance required in Agile environments. It underscores the profound impact that upper management's perceptions and actions can have on team morale and performance. By fostering empathetic leadership and proactive communication, Scrum Masters can safeguard their teams against such destructive patterns.

Key Takeaways

• Leadership Accountability: Effective leadership is crucial in maintaining team trust and morale, especially during conflicts.

• Scrum Master’s Role: Beyond facilitating processes, Scrum Masters must advocate for their teams and ensure their voices are heard in higher-level discussions.

• Proactive Problem-Solving: Addressing potential issues early through open dialogue can prevent catastrophic breakdowns in team dynamics.

Notable Quotes

• Somya Mehra [01:36]: "You can use it anywhere throughout your profession and personal and any part of your life."

• Somya Mehra [05:05]: "Everything was running on time, and the team was delivering as expected."

• Somya Mehra [08:34]: "He just threw the whole devs under the bus. Totally devs."

• Vasco Duarte [13:06]: "Create the opportunity for improvement rather than the opportunity for blaming."

---

This comprehensive exploration by Somya Mehra offers valuable lessons for Scrum Masters and Agile Coaches, emphasizing the importance of resilient leadership and the protection of team integrity against external pressures.

Transcript

[Vasco]

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. Hello everybody. Welcome to our Team Tuesday. This week we have with us Somia Mehra. Hey Somia, welcome back.

[Somia Mehra]

Thank you for having me again, Vasco.

[Vasco]

Absolutely. So Team Tuesday is of course today's episode. But before we dive into the teams, share with us. Somia, what's the book that most inspired you in your career as a Scrum Master?

[Somia Mehra]

Okay, well the book that inspired me was the first book that I read on Agile and it's Agile Retrospective Making Good Teams. Great. So the reason why I chose this book as my first book was as I told you in my previous interview, that in our previous discussion, that when I like I was a business analyst and I was in a Scrum team but we were not doing Scrum as a Scrum. So I have never been part of an actual retrospective where you know, people are talking about improvements. So when I was given a chance to be a Scrum Master, I wanted to do it right because whenever I, when I was learning about Scrum I had, I read it and I also had this feeling like the most important and the game changing event is the Scrum. Like is the Scrum retrospective where team comes together and try to improve, improve their ways of working and that's how you are more agile and you are more efficient. So that's why I chose this book. After reading few of the reviews and to be honest I would say like all the reviews were correct the reason and I would say like whenever most of the Scrum masters ask me like how to take a good retro or can you describe how you take the retro. I obviously invite them to you know at my retros and see it. But I also tell them that to read this book, the reason behind is like this book, you know, divide and give you a stage and a proper format on how to run a retrospective, how to start a retro, how the main retro board work and how to take the action points. It's just not about the format but telling you how to make an effective retro for your team. There you see multiple examples of doing it. To be honest, there are certain examples which are related to retro, but I use it outside retro with my team and I have seen great results. So that why and I always say like whenever you are reading any book, not this book, any book, keep your mind open. Do not think like whatever you are reading will be you will be using it for that purpose only. You can use it anywhere throughout your profession and personal and any part of your life.

[Vasco]

Absolutely. That's a very, very good point and it's a great facilitation book just as you said. So Agile Retrospectives, Making Good Teams. Great by Diana Larson, Esther Dun and the link is in the show notes as usual. So check out the book. Great recommendation Somia, of course. Today's Tuesday, Team Tuesday as we call it here on the podcast. So we dive into the story of the team that self destructed and we do this because we want to understand what are these behaviors, these patterns that emerge in teams that lead to problems. So tell us that story, give us a little bit about the context. How big was the team who was on the team? How big is the company? Give us the context and then walk us through how those little behaviors or patterns maybe started small but quickly escalated and became a problem for the team.

[Somia Mehra]

Definitely. So I was part of one of the team, but I saw like a very good team turning into a shattered and being silent completely. So I was working in a startup company where we were building software, like software product on exam evaluation for the university. So this was the team of like it was not a Scrum Scrum team, but I was working as a business analyst. There were developers who were pretty young, not very experienced one because it was a startup. Then there was one Scrum Master who was like a ghost Scrum Master coming and then going and like that. We were having testers in it. Everything was going good. Like in the refinements were happening really nice. We were having the collaboration happening, people asking questions, we are getting back to them, giving good estimates and everything was running on time. And I forgot to mention that these developers were having a tech lead as their manager. Who was not part of our team. He was somebody who is outside the team and just guide the team as and when that person is needed. As I told you, everything was going good. We were working on time, everything was delivering at time. But suddenly the upper management having the CEOs and the other people questioned that. I think people are not working efficiently, we are delivering it on time. But.

[Vasco]

When you say they started challenging, did they come to a retrospective or did they just make a comment to the team lead? How did that challenging happen?

[Somia Mehra]

They commented it to the team lead and the Scrum master that they think based on the backlog and the story points that were estimated, team is padding them a lot. So then the Scrum master came to us and told us the whole scenario. And based on the scenario, I thought like this meeting is going to be confrontational and something can go wrong. So because I was a scrum master and I was not in a responsible or accountable role to tell the team how to work and how to respond. But still I told them that if you are true to your estimates, if you are true to your work, speak about it, even if the conversation is hard, stick around it because you know your work, not other people know your work. And then we went to the meeting and I was hoping like, okay, the scrum master is there, the tech lead is there to help everyone, so things will be fine. And then there was CEO and all of them were there. And to be honest, I was shocked by how the discussion went on. The tech lead said, looking at the estimates, he was like, yeah, you are right, the estimates are wrong. The team has padded a lot. And just like that, he just threw the whole devs into the under the bus. Totally devs.

[Vasco]

Wow, amazing.

[Somia Mehra]

And the devs who are so new to the business, like they are two or three years old, pass out from the university. They can't defend themselves if somebody like a tech lead is telling that you are wrong. So that was like a shit show. Like it was a very bad show for everyone. The CEO was like, yeah, I told you, you know, I'm technical guy. That's why I was able to catch it. If, if I was not a technical guy guy, you would have fooled me. So now the trust has been broken. Now the team feels like, okay, you can't trust your tech lead. You can't. And you have lost all your reputation in front of CEO because now CEO thinks like they are making fool of them. And that's how the whole shattering of team happened. I saw people wanting to leave the team or even the role of a developer and finding some another role just to save themselves. So I would say like from this experience. I would say like teams do not get self destroyed by their mistakes because you can always learn from your mistakes. It's the leadership who destroys the team sometimes and you feel helpless and then the team is just gone because you did not show the true leadership when the time was needed.

[Vasco]

Wow, that's a shocking story. And I bet many of our listeners have probably lived through similar stories. I have lived through similar stories and what is really shocking for me is not that people would think, oh, the estimates are being padded. Of course people can get all kinds of ideas and that's not necessarily a thing if we can openly talk about what is going on. And what is really shocking for me is that the tech lead would not even discuss that with the team first to understand the team's perspective, to understand more of the context, and would just go and throw the whole team under the bus. Which basically means that the tech lead probably felt guilty and responsible and wanted to blame someone else to save face in front of the CEO, which is in itself a destructive behavior. Right? Like when you need to blame someone to remove that guilt or that responsibility. Then of course, in this case, the tech lead is the one that didn't do their job. They didn't do their job first by understanding what was there and they didn't do their job second by just throwing the team under the bus. Because estimates are just random numbers. Imagine if the team would have given the exact number that the CEO thought that the estimates would be, but would still take the same time.

[Somia Mehra]

Exactly. And the thing here is like, that's what I learned. Like whenever I will be in this kind of leadership role or in a servant leadership role, I will be more empathetic towards the people. Like if I think like I can do this work in one day, I won't say like the others can do it in one day. It can take five days for them. The second thing which I felt bad was the Scrum master about the Scrum master. The Scrum master was there in the meeting. As a Scrum Master, you should have come forward to help your team out in that to at least you know, take their side and explain this thing to the CEOs. Like, hey, this is what you are talking is not being agile. Agile is being like whenever we do the story points, estimates, it's not about, we are telling it will, the work will happen in one day or two day. It's a relative thing. Like Okay, I think this story, the login story is. I'll be able. It's a small story, but maybe building a category backlog. Category feature is a medium sized story. It's a five pointer stories and it's very different. And also at that time explaining the tech lead, his responsibility. Like your role is to help your team to achieve the highest efficiency, not to please your upper management. Yeah, throwing them under the bus.

[Vasco]

And these are the conversations we should be having every single day. Not when problems come up because that's too late. Right. Like once the CEO is convinced that somehow the team is trying to fool them, nobody is the winner anymore. Right. And participating in these conversations, early one on ones investigating, trying to figure out what's going on, that really is our responsibility as Scrum masters. So that we avoid catastrophic conflict, but rather create this productive discussion all the time and always creating the opportunity for improvement rather than the opportunity for blaming. That's a very good point. Thank you for sharing that with us. Soumya.

[Somia Mehra]

You're welcome.

[Vasco]

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