When Knowledge Hoarding Destroys Team Dynamics | Florian Georgescu

Summary

Scrum Master Toolbox Podcast: Detailed Summary of "When Knowledge Hoarding Destroys Team Dynamics | Florian Georgescu"

Introduction

In the August 5, 2025 episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages in a compelling conversation with Florian Georgescu, an experienced Scrum Master, about the detrimental effects of knowledge hoarding within Agile teams. This episode, titled "When Knowledge Hoarding Destroys Team Dynamics," delves deep into the challenges faced by teams when critical knowledge is siloed, exploring the ramifications on team cohesion, productivity, and overall project success.

Inspiration and Foundational Concepts

The Responsibility Process

At the outset, Florian shares the book that has significantly influenced his approach to Scrum Mastery:

Florian Georgescu [01:34]: "There were a lot of books, but I think the one that I liked most was the Responsibility Process from Christopher Avery. I found it very interesting about all these stages that we go through when we are facing problems."

The Responsibility Process introduces a framework that helps individuals and teams navigate challenges by understanding their reactions and taking appropriate responsibility. Florian emphasizes the importance of this framework in managing team frustrations and preventing the descent into blame and justification.

Florian Georgescu [02:14]: "Every Scrum Master should read this book because it allows them to support their teams not only in conflict management discussions or to navigate in conflicts but also to support teams in taking responsibility for the things that they can influence."

Applying the Responsibility Process to Team Dynamics

Vasco prompts Florian to share practical advice derived from the Responsibility Process that Scrum Masters can use to foster better team dynamics.

Florian Georgescu [03:33]: "They should understand what are the things that they can influence whenever they want to take responsibility. It is important to understand what they can influence, what they can change and where this responsibility ends."

Florian underscores the necessity for teams to distinguish between areas they can control and those they cannot, promoting honest reflections and open conversations, especially during retrospectives. This approach encourages teams to focus their energies on aspects they can improve, fostering a culture of accountability and continuous improvement.

The Team Story: A Case of Knowledge Hoarding

Florian recounts a real-life scenario that vividly illustrates the adverse effects of knowledge hoarding within a team.

Team Context

Florian Georgescu [05:00]: "We were working with a US client in the mortgage industry. And the goal for the team, so it was a team of around eight people. And the goal of the team was to create a payment system for that client."

The team consisted of diverse skill sets, including approximately eight developers and a seasoned technical lead who was not only proficient in the required technologies but also had established relationships with the client, having worked on multiple projects with them.

Emergence of Knowledge Hoarding

The crux of the issue began with the technical lead's central role within the team.

Florian Georgescu [06:18]: "Everything moved or everything happened around that person."

His extensive knowledge of both the technical aspects and the client's expectations made him indispensable. However, this centralization led to unintended negative consequences:

• Decision-Making Bottleneck: The technical lead had the final say in sprint planning estimates and technical solutions, stifling other team members' input.

• Knowledge Siloes: Other developers started emulating the technical lead's behavior, leading to isolated knowledge pockets within the team.

• Reduced Collaboration: During daily stand-ups, team members became hesitant to ask questions, fearing they might appear incompetent.

Florian Georgescu [07:44]: "Exactly. So they started to mirror this behavior and build those knowledge silos."

This environment fostered an atmosphere where collaboration was minimal, and team members operated as independent entities rather than a cohesive unit.

Visible Impacts on Team Performance

Initially, the team's performance metrics remained robust due to the technical lead's dedication and expertise. However, the true fragility lay beneath the surface.

Florian Georgescu [09:02]: "Right, exactly. But the interesting thing was that if you looked at the data, the team was doing well."

This facade of success was soon shattered when the technical lead had to leave the project unexpectedly.

The Downfall: Consequences of Knowledge Hoarding

The departure of the technical lead exposed the team's vulnerabilities starkly.

Unpreparedness and Delays

Without the technical lead's guidance:

Florian Georgescu [09:52]: "We had planning meetings and didn't know how to react, what to do, how to estimate."

The team struggled with planning and estimation, leading to project delays. The reliance on a single individual for critical decisions and knowledge meant that the team was ill-equipped to handle such a transition.

Increased Attrition

The deteriorating team dynamics resulted in tangible losses:

Florian Georgescu [10:45]: "We were delayed with the delivery. Two juniors left the team because the main reason was that on one side the atmosphere, but on the other side there was no learning involved as this tech lead did everything by himself."

The lack of collaborative learning opportunities and a supportive environment led to frustration among team members, prompting juniors to leave in search of more nurturing workplaces.

Quality Compromises

With the technical lead absent, the remaining team members struggled to maintain code quality and project standards.

Florian Georgescu [10:45]: "I remember even the code reviews. It was done something super fast. And obviously for those colleagues that wanted to learn, it was very difficult to handle this situation because there was no learning."

The rushed code reviews and absence of mentorship hindered the team's growth and compromised the project's integrity.

Host's Reflections and Insights

Vasco reflects on Florian's story, drawing broader lessons applicable to Scrum Masters and Agile Coaches.

Vasco Duarte [11:34]: "Sometimes, even when things seem to be going well and there's that one person that knows all the answers, this is when teams are starting to crumble. ... We need to be attentive to that and really help teams to take collective ownership of the delivery, not just one person."

Vasco emphasizes the importance of distributed knowledge and collective ownership within teams. Relying heavily on a single individual, regardless of their expertise, can lead to systemic weaknesses that jeopardize the entire project's success.

Key Takeaways

1. Avoid Knowledge Silos: Ensure that knowledge is shared openly within the team to prevent dependency on a single individual.

2. Promote Collective Ownership: Encourage all team members to take responsibility for various aspects of the project, fostering a sense of shared accountability.

3. Facilitate Open Communication: Create an environment where team members feel comfortable voicing their ideas and questions without fear of judgment.

4. Prepare for Transitions: Develop contingency plans to handle unexpected departures, ensuring that the team remains resilient and adaptable.

5. Invest in Continuous Learning: Provide opportunities for team members to learn and grow, enhancing their skills and contributing to the team's overall capability.

Conclusion

This episode of the Scrum Master Toolbox Podcast serves as a poignant reminder of the intricacies involved in maintaining healthy team dynamics within Agile environments. Florian Georgescu's narrative underscores the subtle yet profound impact of knowledge hoarding, illustrating how it can erode trust, stifle collaboration, and ultimately undermine project success. For Scrum Masters and Agile Coaches, the lessons drawn from this discussion highlight the critical need to foster a culture of transparency, shared responsibility, and continuous learning to build resilient and high-performing teams.

Notable Quotes

• Florian Georgescu [01:34]: "Every Scrum Master should read this book because it allows them to support their teams not only in conflict management discussions or to navigate in conflicts but also to support teams in taking responsibility for the things that they can influence."

• Florian Georgescu [03:33]: "They should understand what are the things that they can influence whenever they want to take responsibility."

• Florian Georgescu [07:44]: "They started to mirror this behavior and build those knowledge silos."

• Florian Georgescu [09:02]: "But the interesting thing was that if you looked at the data, the team was doing well."

• Vasco Duarte [11:34]: "Sometimes, even when things seem to be going well and there's that one person that knows all the answers, this is when teams are starting to crumble."

These insights encapsulate the essence of the episode, providing listeners with actionable wisdom to enhance their Scrum Mastery and foster healthier team environments.

Transcript

[Vasko]

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.

[Host]

Hello everybody. Welcome to our Team Tuesday. This week we have with us Florian Giorgesku. Hey Florian, welcome back.

[Florian Giorgesku]

Hey Vasco.

[Host]

So, Florian, Tuesday is of course Team Tuesday 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?

[Florian Giorgesku]

There were a lot of books, but I think the one that I liked most was the Responsibility Process from Christopher Avery. I found it very interesting about all these stages that we go through when we are facing problems. I also did, especially when we talked about that team and about the frustration with the burnout and it was very easy to me to go into the blaming phase and justification. But I believe every Scrum Master should read this book because it allows them to support their teams not only in conflict management discussions or to navigate in conflicts, but also to support teams in taking responsibility for the things that they can influence. I think this is very, very important. So yeah, so when you think about.

[Host]

The responsibility process and we talked about that, I mean, you already talked about how that would have applied to perhaps even productively if you had that knowledge and experience in the Monday story. Right. But we also are helping teams all the time with that process. What is one tip you took from the book when it comes to helping teams understand how they can benefit from this? Let's call it. Well, it's Responsibility process. Right? Like accepting responsibility for the right things. Not everything. Right. Like, what's the one tip you have to share with us about that.

[Florian Giorgesku]

They should understand what are the things that they can influence whenever they want to take Responsibility. It is important to understand what they can influence, what they can change and where this responsibility ends. And then by understanding also the model, to use reflections and be honest, have honest conversations, especially in retrospectives, and have an honest discussion about what happened and what can they do in the future to improve the situation.

[Host]

So the book is Responsibilities the Responsibility Process by Christopher Avery. The link is in the show notes. Everybody check it out. We also have a podcast episode with Christopher here on the podcast, so check that out as well. And of course, because today is Tuesday, Florian, we dive into the team story. So tell us a story of a team. Give us a little bit of, you know, is this a small team, big team, small company, big company, whatever that is. But help us understand the context of the team and then walk us through the steps, how those small little behaviors, bites, certain or even all of the team members started small, but eventually grew and became a big problem for the team.

[Florian Giorgesku]

Yeah, it was. So we were working with a US client in the mortgage industry. And the goal for the team, so it was a team of around eight people. And the goal of the team was to create a payment system for that client. And there were various skills in the team, around 80 developers. One of them was the technical lead, the senior one. And he was also experienced not only in the technologies he was using, but also with the customer. So he knew the client. He worked also for other projects with that client. And what happened was that everything moved or everything happened around that person.

[Host]

So kind of like all of the communication, all of the decisions, all of the planning, that person always had to be involved, Right?

[Florian Giorgesku]

Exactly. And also the knowledge. Also the knowledge. And it was not because he took that knowledge only for himself, only from. Because it was not something malicious, but it was maybe a job security and also a little bit of pride. But what happened basically was, for example, in spend plannings, he was the one that was providing the final estimates, or he was the one that kind of had the last say when it comes to the technical solution that we wanted to implement. There were also, for example, when other developers, I realized it when other developers tried to voice their opinion, cut the discussions short. And what was interesting is that what made this issue even stronger was its spiral effect, in the sense that the other developers also started to build the knowledge silos around themselves discussions.

[Host]

They kind of started to copy the behavior.

[Florian Giorgesku]

Exactly. So they started to mirror this behavior and build those knowledge silos. Also during dailies, questions started to not come up so often anymore because everybody was scared of not appearing incompetent Sprint planning was mainly done in a short period of time with the input of that tech lead. And yeah, it was a very bad atmosphere in the team.

[Host]

I can totally understand because the moment you start separating, right. Like, it becomes a group of independent individuals that are loosely coupled through the, of course, technical dependencies they have on each other. There's very little human interaction or even motivation to collaborate. Right. Like, I can imagine that decision making was very easy when it affected only one developer, but if it affected multiple developers, it was probably slow and cumbersome to make any decisions because everybody was looking at it just from their personal perspective.

[Florian Giorgesku]

Right, exactly. But the interesting thing was that if you looked at the data, the team was doing well. Yeah. Because again, we had that technical lead who was knowledgeable, who knew the product, who knew the client. He was also very dedicated to the project. So if you looked at the number and such things were going well, not bad until that developer had to. Had to leave for what happened.

[Host]

When that developer left.

[Florian Giorgesku]

Things got blurry. Things got blurry.

[Host]

Give me an example what started happening.

[Florian Giorgesku]

We had planning meetings and didn't know how to react, what to do, how to estimate. They were nervous about. I remember we had a discussion on the technical solution. They were saying, you know what? Alex was the one dealing with architecture and the design. We don't have this knowledge. And I remember very well how this information was provided. To me, it was a smile, but with a frustration. It was a mix between smiling and frustration. So it's Alex that we don't have this. Know how.

[Host]

What happened to the team? Like, I can imagine that maybe they started delivering late, Maybe there were some quality problems. What happened?

[Florian Giorgesku]

We were delayed. So we were delayed with. With. With the delivery. Two juniors left the team because the main reason was that they didn't. Like on one side the atmosphere, but on the other side there was no learning involved as this tech lead did everything by himself. I remember even the code reviews. It was done something super fast. And obviously for those colleagues that wanted to learn, it was very difficult to handle this situation because there was no learning. In the best case scenario, they received some information on what to do and how to do, and that's it.

[Host]

This reminds me that sometimes, even when things seem to be going well and there's that one person that knows all the answers, this is when teams are starting to crumble. And I think this story is a great illustration of that and how important it is to make sure that the whole team is contributing at all times. Now, it may not start there but as Scrum masters, as leaders, as Agile coaches, we need to be attentive to that and really help teams to take collective ownership of the delivery, not just one person. That's been a great story and a great reminder of that. Florian, thank you very much for sharing that.

[Vasko]

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

[Host]

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.