Culture Follows Structure — Why Some Teams Self-Destruct By Design | Aimé Flemm

Summary

Podcast Summary: Culture Follows Structure — Why Some Teams Self-Destruct By Design

Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Host: Vasco Duarte
Guest: Aimé Flemm
Date: June 16, 2026

---

Episode Overview

In this episode, Vasco Duarte welcomes Aimé Flemm for "Team Tuesday," discussing how organizational structure deeply shapes team culture, often determining whether teams thrive or self-destruct. Drawing from personal stories and systemic analysis, Aimé and Vasco explore the idea that "culture follows structure," and why attempts at team improvement can fail without organizational structure change. The conversation focuses on real-world experiences, trade-offs between different team topologies (component teams vs. feature teams), and the foundational importance of aligning organizational design with actual purpose and strategy.

---

Key Discussion Points & Insights

1. Inspirational Books Shaping Scrum Masters

• Aimé’s top recommendations:
  • Large Scale Scrum (LeSS) by Bas Vodde and Craig Larman
    • Described as the "holy Bible" for mastering organizational agility, filled with practical tools, workshops, and deep guidance.
    • Quote: “I think I read it in two weeks, the whole book...It all makes sense now; I finally know what to do.” (02:06, Aimé)
  • 10xOrg by Alexey Krivitsky, Roland Flemm, and Craig Larman
    • Focuses on a systemic approach to organizational change involving management with strong visual maps and tools for aligning structure with market needs.
    • Quote: “They really dive into the truly systemic approach…how to involve management…a beautiful map in which you can use visual language to explain to management but also to the people, hey, this is currently how we're structured. This is what the market requires from us.” (02:56, Aimé)

2. Culture Follows Structure: Teams as Products of Design

• Main Thesis: Destructive team behaviors are often symptoms of organizational constraints. The Scrum Master’s role is to understand and challenge these constraints.
• Story:
  • At a pension fund, a UX team was restricted to UX only, creating frustration as they couldn’t test with customers. The narrow boundaries led to toxicity.
  • In contrast, at another organization, Scrum Masters could establish cross-functional teams with broader mandates, drastically improving morale and performance.
  • Quote: “Culture follows structure. Habits come from a team are often a cause of the boundaries set by the organization.” (05:08, Aimé)
  • Learning: Changing structure yields better outcomes than focusing solely on coaching.
  • Consequence for “pushing too fast”: Aimé got fired when attempting too rapid a change. When given a real mandate, was able to move from seven siloed component teams (each with its own Product Owner) to unified, end-to-end teams sharing one Product Owner, reducing dependencies and “dependency hell.”

3. The Trade-offs of Team Topologies: Component Teams vs. Feature Teams

• Component Teams: Deep specialization (e.g., Frontend, Backend), maintain strong identity, but foster silos and dependencies.
• Feature Teams: Own vertical product slices, increase speed and adaptability, but can threaten architectural coherence due to divergent decisions.
• Adaptiveness: Moving to feature teams (even more so to product teams/organizations) makes the org more adaptive, with faster capability to pivot, but introduces new coordination challenges.
  • Quote: “Fast does not mean customer value; that's why we have this third move…where the adaptive organization…teams working on the whole product in sprints.” (11:02, Aimé)
  • Host Reflection: “The people problems don’t disappear when the structure works, but the structure problems disappear.” (08:32, Vasco)

4. Fit-for-Purpose Organizations: Starting with Purpose

• Purpose First: Any change to team structure should start with, “What is our purpose?”
• How to Define Purpose:
  • If there's a single Product Owner with a vision, clarify "What change do we want to see in the world?"
  • If multiple POs, involve upper management in strategy discussions—otherwise, risk defaulting to meaningless objectives.
  • Quote: “If your strategy could also be make as much money as possible, that's a really difficult strategy because that does not motivate at all.” (14:10, Aimé)
  • Host Point: “Money is the outcome. It's not the goal itself.” (14:35, Vasco)

5. You Can’t Coach Your Way Out of a Bad Org Design

• Structural change is fundamental: Coaching alone is the “cherry on top,” providing “maybe 5% of the real gains.”
  • Quote: “You can't coach your way out of a broken organizational design.” (08:41, Vasco citing Aimé’s bio)
  • The bulk of improvements come from addressing structure, not just people or process tweaks.

6. Beyond Structure: Other Levers for Change

• Five Organizational Assets to Influence Culture:
  1. Organizational structure (team topology, reporting lines)
  2. Processes (meetings, ceremonies, workflows)
  3. People (skills, fit to desired culture)
  4. Rewards/Incentives (career paths, recognition)
  5. Change mechanisms (tools, HR practices, competency matrices)
     • Example: Competency matrices rewarding multi-skilled individuals, promoting adaptability over deep specialization.
  • Quote: “If your career is only rewarded for getting deeper specialism, that's the only thing you'll do. But if you're able to change…see if you can fit things in…make people more multi-skilled and reward them for becoming more multi-skilled." (16:21, Aimé)

---

Memorable Quotes & Moments

• “Culture follows structure. Habits come from a team are often a cause of the boundaries set by the organization.”
  (05:08, Aimé)

• “You can't coach your way out of a broken organizational design.”
  (08:41, Vasco referencing Aimé's perspective)

• “The people problems don’t disappear when the structure works, but the structure problems disappear.”
  (08:32, Vasco)

• “Fast does not mean customer value.”
  (11:02, Aimé)

• “Money is the outcome. It's not the goal itself.”
  (14:35, Vasco)

• “Coaching is like the cherry on top… The big improvements are really in the structural changes.”
  (15:26, Aimé)

---

Important Timestamps

• 01:11–03:53 — Inspirational book recommendations and why they made an impact
• 04:55–08:32 — Story of teams self-destructing due to structural constraints and the role of the Scrum Master
• 08:32–10:06 — Deeper dive into component vs feature teams and management resistance to change
• 10:06–12:10 — When specialized teams are fit for purpose, and when adaptability matters
• 12:10–14:27 — Risks of feature teams, architectural coherence, and aligning structure with purpose
• 14:27–15:26 — The importance of purpose in defining structure; why “make more money” is not real strategy
• 15:26–17:54 — Key assets to influence culture: beyond structure—people, incentives, processes, and tools

---

Tone and Style

The episode is conversational, candid, and filled with practical insights from the trenches. Both Aimé and Vasco draw openly from real-life failures and successes, using humor and authentic language to make complex organizational concepts accessible and actionable.

---

Summary Takeaways

• Team dysfunction is often a symptom, not a root cause—look at the structures and boundaries.
• Organizational change must start with clarity of purpose/strategy, then leverage the right team topologies and rewards.
• Coaching is powerful—but only when the structure and incentives are aligned with desired culture.
• Feature teams and adaptation bring trade-offs; no single “best” solution exists.
• True agility comes from structural flexibility, not sprint-level optimizations.

---

Recommended for: Scrum Masters, Agile Coaches, product leaders, and any practitioner seeking deeper understanding of how team structure and organizational design directly shape results, culture, and morale.

---

For more: See full episode links and referenced models in the show notes.
Related episodes: Interviews with Bas Vodde, Roland Flemm, and deep dives on LeSS and 10xOrg.

Transcript

[A]

Hey there, agile adventurer, just a quick question.

[B]

What if for the price of a

[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 warfree 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 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, joining us from the Netherlands, Eme Flem. Hey Eme, welcome back.

[C]

Hi there.

[B]

So Team Tuesday of course is today, but we always start with an inspiration. So Emma, share with us, what was the book that most inspired you in your career as a Scrum Master?

[C]

I have two for you in the offering, actually. Oh, we get one for free. Yes. So I think the, the first book that really opened my eyes and I had to read twice because I was like, wow, this is, this is like the holy Bible was large scale Scrum, more or less from Buzz 40 and Greg Larman. I remember reading this for the first time and I think I read it in two weeks, the whole book and I was just constantly texting all the people like, oh, this is this. It all makes sense. Now I finally know what to do because there's so much information in there on how to get your change going, how to what the structure could look like, workshops you could try, you know, all these beautiful tools wrapped in one book and in a nice story. And I think it really, it's a pleasant reading experience and I could highly recommend reading this book to anyone who wants to find ways to be creating more of the adaptive organization to really on the how. Then you also have the what and the why. And there I would like to focus on another book which recently came out, which was 10xorg by Alexey Krivitsky, Roland Flem and Craig Larman. And they really dive into the truly systemic approach to organizational change and how to involve management because I think more or less is more Folks on the people side and also a bit of management. But management likes a two by two and just an overview on hey, where do we optimize this organization for and where should we move and what does the market require from us? And they have a beautiful map in which you can use like visual language to explain to management but also to the people, hey, this is currently how we're structured. This is what the market requires from us. Well, where should we change? How should we change? And I think yeah, both are so truly, truly valuable and if you have time spare I would recommend them reading.

[B]

And for those of you who are not yet convinced, check out the link to the episodes with both authors of both books, Basvod and Roland Flem. So check it out. The episode link is in the show notes. Definitely worth listening to the episodes even if you read the book. But it can also be a great way to dip your toes into the ideas in the book and then read it of course. So Eme, thank you very much for sharing those great recommendations. Now we turn our attention to the teams and how sometimes they can become their own worst enemies. We've all witnessed it. Teams that start well or perhaps were not that well to begin with, but they kind of find this rot and then they just start digging into it and things can spiral out of control and eventually the team can self destroy. So we'll identify and catalog all of the root causes later, but tell us the story first. Eme.

[C]

Yeah, so when I so when I heard this question I'm easily thinking of more the the destructive tendencies of a team are the consequence of how organization is actually structured. Because most often I truly believe culture follows structure. So habits come from a team are often a cause of the boundaries set by the organization. And I think it's your role as a Scrum Master to really look at these boundaries to set the right conditions to make sure that the team starts acting in certain way. For example, circling back to this first gig where I worked in this pension fund, it was really clear that the constraints set by the organization was this UX team will only do ux, that's all. And there's really clear boundaries. But then they really start complaining and becoming like toxic because we are making so many screens and nobody's using them and we are not allowed to test with the customer. And there was this toxicity and the teams were really struggling with finding their place and the system is so big. As a Scrum Master, it's really hard to change compared to this organization where I'm currently working where we had the mandate as a Scrum Master to set these boundaries of broader teams with more end to end capabilities. And there you see really that there's way more team performance because there was less complaining, complaining about other stuff, but not about the dependencies because often these dependencies with other teams just cause frustration. And yeah, I think it's your job as Scrum Master to try and fix these, but it's also the hardest job to fix because culture follows structure. And one of Larman's laws is the organization is organized in such a way that middle management and upper management try to have the status quo stay as it is. And to change this is the hardest part, but I think the most important one. And as you see in my first experience, because I tried too fast, too quickly, too boldly to try and change this, the status quo, I got fired. But the moment that we did get the mandate to change this and move from. Well, so a bit of context about this organization. They used to have component teams, there were seven of them, so back end billing, whatever. And they each had their own product owner. And we were able to move to one product owner with seven teams. And they, they, we reorganized the teams that they had full end to end capability to work on the products. Like there's one product, they made a backend software for charging stations for your electric car and you, you, you'll get different problems because it's always a trade off whatever you do. There's no silver bullet, it's always a trade off. But it really improved morale compared to the component teams because yeah, they were not in this dependency hell anymore. It was more focused on, oh, we need to talk to each other to fix stuff. But we're allowed to.

[B]

Yeah, the people problems don't disappear when the structure works. But the structure problems disappear.

[C]

Yes, exactly. So, yeah, that helps.

[B]

Yeah. I'm reminded of your bio and the last phrase you had in the bio is you can't coach your way out of a broken organizational design. And I think that this idea of the component versus feature teams is a great example of that. Right. Because if what you want is ownership and faster cycle time or lead time, depending on what you're focusing on at the moment, then component teams give you that. Sorry, feature teams give you that. But component teams have structural meaning, right? Like it's the whole idea, like I am a front end developer, right? Like there's this guy that I follow online that talks about this identity function, right. And the manager of a front end team will never want to give that away. Because they have been front end developers. Like why would I give that away? I know everything about front end. I perhaps even designed the original front end architecture for this thing. I've been on this for like whatever, five years, 10 years, 15 years in a pension fund, probably 25 years. And then you're not going to want to change that. Like it's not that you're a bad person. Is that what's out there? What's beyond the component team? It's the total unknown.

[C]

Exactly. And so it depends, right? So if, if is your organization fit for purpose? That's the question that you should be able to answer. And it could well be that having these component teams, these specialized teams is fit for purpose because that's what the market requires from you. An example could be construction companies often have like really strict plannings and we need people who are really well at welding stuff to weld in this specific week. Could be like the component team, the welding team, you know, or you want, if you have, if you're running a movie, you want the actors to do acting and the dancers to do dancing and you know when to do it, you want to have them. But when, when these the there comes more uncertainty that you want to be a bit more adaptive. Right. So we had the first wave of agile. We created feature teams so that we can, can become more adaptive. But often we see that the feature teams still only work on features and not necessarily the whole product. So you have speed often as an outcome more than adaptive actually. So we became really fast. Fast does not mean customer value. It doesn't always mean customer value. That's why we have this third move right up on the map in org topologies where the adaptive organization is where you often see like the less framework and we saw this at the company I'm working at now, is that we became truly became more adaptive because we had teams working on the whole product in sprints of two weeks. So if the switching costs were really low, because if in Wednesday we decided we want to do something else next week, we'll refine it on Thursday, Tuesday, sprint change and then we can already switch to seven teams to do something else. And then you're really adaptive on the organizational level.

[B]

Yeah, but adaptive also brings other problems.

[A]

Right?

[B]

And that's the ability to discuss this coherently that allows us to create that fit for purpose quality for the organization. A very simple example is that feature teams have the problem that they move fast but they don't keep coherence. In other words, if you have five feature Teams working on the same parts of the system with different goals. They will have five different reasons to make design decisions which may lead to an incoherent overall architecture. It's a risk. It's not a certainty, but it's a risk. Right. So we need to be aware, and I think you said it very well. We need to have the right organization for the purpose we have today. And that brings me to the next question, which is something I'm dealing with right now at a client, which is this idea that, well, I mean, if we want to be fit for purpose, we should spend some time defining what the purpose is. Because in a software organization or an organization that delivers value through software, the purpose shouldn't be more software.

[C]

Yeah. So I think there are two ways in which you could tackle this question, right? If. If there's one product owner, then the product owner probably has a vision that you could sharpen. And then from there you could really easily find the purpose of the organization. Because then I would focus on answering the question, what change do we want to see in the world? And organization is the vehicle to bring that change. If not there, because organization complexity, you have more POs, and they all have their own vision, then it's really, I think, a case of sitting down with higher management and looking at the strategy. Where do we expect to be, you know, in the future? Where do we want to be? And having these more strategy discussions. But that's difficult because in the company that I've worked, your strategy could also be make as much money as possible. That's a really difficult strategy because that does not motivate at all.

[B]

And also, it's not really a strategy, it's a wish. Right. Because we need to figure out, okay, but make more money. How?

[C]

Yeah, right. So money is the outcome. It's not the goal itself. That's. Yeah.

[B]

So we need to figure out. And I think that that's the key. Right. Because the shift from component teams to feature teams obviously makes sense if your goal is to be more adaptive to whatever comes. Right. So obviously, the less stable the market is, the more adaptive you want to be. The more stable the market is, the more you can survive not being so adaptable. Right. And I think that that kind of discussion is so important. And that's why, as you said, like, you can't coach yourself out of a bad organizational design. You need to start first from the purpose, what is the purpose? And then you can start asking, okay, what organization would help us get there?

[C]

Yep. Yeah. Fully agree. I think the as you mentioned, you know, the coaching is like the cherry on top of. It's less 5% of the real gains you can make. And the big improvements are really in the structural changes you could do. But it's not only organizational structure, right. So people are. You have other assets which referring to the model of of course I forget so I'll let you know. But there are, there are five things you could change really to have this outcome of culture and see the change in behavior. Organizational structure is one of those. But you also have the processes. So those are more like your stand ups and the way you do the meetings, whatever scrum nice. Could all be the people. Do we have the right people in the organization for the culture that we want and do they have the right skills? Very important. Because yeah, often if you want to become more adaptive, you don't want very deep specialism but you want more of these M shaped people so you can create a tool we made. This was actually really cool and I'm also quite proud of to have people change, which is the fourth one. Reward people for a certain behavior, which is really primitive but it works. And then one of the tools you can make as a scrub master or help make is build a competency matrix which rewards certain career paths. Because if you're, if, if your career is only rewarded for getting deeper specialism, that you'll get a deeper specialism and it's the only thing you'll do. But if you can, if you're able to change with hr or maybe you don't even need HR in our case we did need HR to be part of the change because they in the end are the ones that sign it off to make it like an official document. Change the requirements for each level, Junior Senior media, level one to five, whatever you use and see if you can fit things in. Like if you want to be more adaptive, make people more multi skilled and reward them for becoming more multi skilled.

[B]

We'll find the link to that model and put it in the show notes. Make sure that people can go and read more about it. It's a great conversation. Thank you for sharing that Ame.

[C]

Awesome.

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

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