We like to think architecture starts with a problem. But often, by the time we're brought in, someone has already chosen the answer — and the real work becomes figuring out how to slow things down without making anyone feel foolish.

That's the situation Kim Kao, a solutions architect manager at AWS in Taiwan, walked into. A retail client — battered by the pandemic, competitors circling — had already been told by another vendor exactly what to do: containerise everything, deploy Kubernetes, and the operational problems would disappear. "Don't laugh," Kim recalls. The system underneath that confident prescription was twenty years old, and nobody left in the building fully understood how it worked. "Nobody knows what the content is."

Rather than argue about Kubernetes, Kim worked backwards. He ran impact mapping with decision-makers and functional leads, asking a deceptively simple question — who would support a goal of growing month-on-month revenue? — and watched the room fall silent. Then a two-day event storming workshop with forty to fifty people, many sitting together for the first time, surfaced merchant management as the place to actually begin. Somewhere in the middle of it, Kim had a realisation: "I found I was a businessman, not a technical guy."

This conversation explores what it takes to redirect a client who arrives with the answer already in hand — and why understanding the problem first is so often the faster route to solving it.

Key Discussion Points

• [00:04] The Answer Was Already Chosen: A retail GM, hit by the pandemic, arrives with a vendor's verdict — Kubernetes will fix everything
• [00:06] A System Nobody Understands: Twenty years of accumulated decisions, and "nobody knows what the content is"
• [00:09] Don't Decorate the Weakness: Why building on an unmapped system was "quite dangerous," and how merchant management emerged as the right starting point
• [00:11] Compared to What?: Making the true cost of Kubernetes visible — a million-plus active members, hours-long promotions, six-month hardware lead times
• [00:14] The Question Behind the Question: Separating the symptom from the cause before committing to any solution
• [00:16] The Silence in the Room: Running impact mapping, setting a revenue goal, and asking "who's your supporter?" to a team used only to taking orders
• [00:19] A Businessman, Not a Technical Guy: How connecting marketing, inventory, and logistics reframed Kim's sense of his own role
• [00:20] The Conjunction Role: Sending clients to DDD Taiwan and letting them discover the value of collaborative modelling for themselves

Guest: Kim Kao Hosts: Andrea Magnorsky, Andrew Harmel-Law, Kenny Schwegler

We like to believe that if we do everything right — bring in proven methods, hire experienced people, build the feedback loops — then the system will eventually bend toward better. Marco Heimeshoff spent years inside a company doing exactly that, and watching it fail anyway. Not because EventStorming, context mapping, or domain storytelling were the wrong tools. But because the real problem was somewhere none of those methods could reach.

This is what Marco calls a "graveyard story" — the kind he usually pushes under the rug. Through a multi-year transformation, his team improved the architecture, introduced agile feedback loops, and brought in collaborative modeling. Things kept getting better in parts, and kept failing as a whole. The EventStorming sessions made the dysfunction transparent, but transparency wasn't welcome everywhere. For some people in the room, asking "what can we improve next week?" didn't feel like progress. It felt like an attack. As Marco puts it, "feedback becomes violence" — and he slowly realised that, with the best intentions, he had been walking "through a culture with an ax," hurting people who never wanted the change in the first place.

A colleague's introduction to spiral dynamics gave him a language for it: not everyone in a system wants to improve it. Some want to keep it alive, because it gives them belonging and identity. And above all of it sat a boss who said yes to everything, sat at the back of every session with a quiet smirk, and quietly commissioned the company's most revenue-critical software outside the entire process — telling that developer not to talk to Marco's team.

This conversation is about the limits of method, and the power facilitators hold without realising it. We dig into why a sponsor's mandate isn't the same as the team's, why psychological safety is necessary but not sufficient without intrinsic motivation to change, and what it really means to meet a system where it is rather than where you wish it were.

Key Discussion Points

• [00:00] The Graveyard Story: Marco opens a multi-year engagement he usually keeps buried — where everything improved except the thing that mattered
• [02:00] EventStorming Makes It Visible: The sessions surface buried relationships and dynamics that sticky notes can't make safe to break
• [03:30] When Feedback Becomes Violence: Why "what can we improve?" lands as a positive for some and an identity attack for others
• [05:30] An Ax Through the Culture: Marco's uncomfortable realisation that he was hurting people who never asked for his help
• [06:30] Context Mapping the Culture: Using bounded contexts to map mindsets — and why people read it as being put in a corner
• [09:30] The Boss Who Said Yes and Meant No: The smirk at the back of the room, and the revenue-critical software built in secret
• [14:30] How He Knew It Was Cultural: Working through technology, feedback, communication, and method before spiral dynamics named the real problem
• [19:30] Safe and Motivated: Why safety removes a blocker but never creates the desire to change
• [20:00] What He'd Do Differently: Leave earlier, get a real mandate, and meet the system where it actually is
• [23:30] Heuristics for the Pain: Keep your heuristic list short, observe the non-interaction, run small controlled experiments, and hold space — "shut the f*** up" and let people think

Guest: Marco Heimeshoff Hosts: Kenny Schwegler, Andrea Magnorsky, Andrew Harmel-Law

We've all been in that meeting. Someone proposes a solution, someone else proposes a different one, and within minutes the room has split into camps. People stop listening and start waiting for their turn to argue. Whatever decision comes out feels less like a conclusion and more like whoever had the most stamina won.

Laïla Bougria has spent over two decades in software engineering, much of it working in messaging and event-driven systems at Particular Software. Her story isn't a single incident — it's a pattern she's seen repeat across teams, companies, and years: smart people in a room, a decision to make, and a conversation that quickly becomes "my opinion versus yours." At Particular, Laïla learned to break this cycle through an RFC process that forces a different question before solutions are even compared: what problem are we solving, and for whom? That reframing removes a surprising amount of conflict before it starts. But what happens when two teams share a decision and neither is technically wrong? Or when you're convinced something is a mistake, and the team moves on without you?

This conversation digs into the emotional weight of architectural decisions — the gut reactions we dress up as rational analysis, the perfectionism that makes letting go feel like losing, and the personal practices that help you stay honest with yourself over time. Laïla shares how she builds evidence instead of winning arguments, why she runs personal retrospectives every six to twelve weeks, and what it taught her when she gathered evidence against a decision and found… nothing.

Key Discussion Points

• [00:01] The Pattern That Keeps Repeating: Smart people in a room, comparing solutions before they've agreed on the problem — and why it turns personal fast
• [00:04] Problem Before Solutions: How Particular Software's RFC process reframes decisions by requiring a shared problem statement before alternatives are discussed
• [00:06] "That's a Horrible Idea": Turning gut reactions into constructive questions about hidden assumptions and risks
• [00:09] When Two Teams Share a Decision: Navigating the give-and-take of event granularity between teams, and using coupling arguments that land because they serve both sides
• [00:14] Boundaries as Everyone's Job: Why service boundaries shouldn't be a few people's problem and how curiosity about the business domain surfaces issues early
• [00:18] Building Evidence, Not Arguments: The story of tracking bugs to prove a hunch right — and the equally important story of tracking evidence and finding none
• [00:25] Personal Retrospectives: A quarterly practice for resolving frustration, testing your instincts against reality, and genuinely letting go

Guest: Laïla Bougria Hosts: Andrew Harmel-Law, Kenny Schwegler, Andrea Magnorsky