<![CDATA[Stories on Facilitating Software Architecture & Design]]>11c2cb40-7f0e-5e4f-b3e7-8eda1586ec87Tue, 14 Apr 2026 06:15:04 +0000Captivate.fmVirtual Domain-Driven Designhttps://artwork.captivate.fm/48d90c65-20cb-44f0-bd10-21a18a809b5a/sfsad-logo.pngStories on Facilitating Software Architecture & DesignVirtual Domain-Driven DesignVirtual Domain-Driven DesignWe’ve consistently observed a common pattern: regardless of the architectural approach—from traditional enterprise to more hands-on, emergent methods—teams face similar obstacles when building effective systems. The core challenge remains how to build software that truly works and enables a smooth flow of delivery. To address this, we’ve started a new series, Stories on Facilitating Software Design and Architecture. In these sessions, we focus on real-world experiences from our community, sharing practical stories about the alternative approaches that have delivered results. It’s about moving beyond the theoretical and into the practical, shared wisdom of what actually works.https://virtualddd.com/stories-on-facilitating-software-architecture-design/falseepisodic656809nopodcastWhen Method Wars Hide the Real ProblemWhen Method Wars Hide the Real ProblemWe fight about Agile versus Six Sigma, build versus buy, in-house versus outsourced. We pick our camps and defend them with the certainty of people who've never mapped the territory they're fighting over. But what if the real problem isn't which method is right — it's that we're choosing methods before we understand what we're building?

That's the story Simon Wardley brought to this conversation, centred on HS2 — Britain's high-speed rail project. CIO James Finley needed to build a virtual railway before the physical one, because it's cheaper to mess up a virtual landscape than the English countryside. The typical government approach would bundle everything into domain-based contracts and outsource. Instead, James spent a Sunday afternoon doing something different: he mapped the entire system. Not a component diagram. A proper map — with users at the top, a chain of needs underneath, and a critical question about each component: how evolved is it? Custom-built land referencing systems on the left. Commodity compute on the right. Suddenly, the methodology war dissolved. You need Agile where things are novel and changing. Six Sigma where things are commodity. Lean in the middle. They built the system using multiple methods simultaneously — ahead of schedule, under budget.

But Simon doesn't stop at the success story. The conversation digs into the harder questions: what happens when people have built 20-year careers on a single methodology and you're implicitly telling them they've been doing it wrong? How do you handle dominant voices who weaponise information asymmetry in collaborative mapping sessions? And why do maps create safer spaces for challenge than stories — even when the topic is as divisive as Brexit?

Key Discussion Points

  • [00:01] The Virtual Railway: Why HS2 needed to model the entire railway digitally before breaking ground — and how James Finley approached it differently from typical government IT
  • [00:06] The Sunday Afternoon Map: How plotting components on an evolution axis — from genesis to commodity — dissolved the methodology debate
  • [00:10] Burning the Heretic: What happens when Simon tells Agile conferences that Agile isn't appropriate everywhere — and gets the same reaction at Six Sigma conferences
  • [00:13] The Excuse Loop: Why "we didn't specify the requirements well enough" is the most dangerous sentence in software delivery
  • [00:16] The Military Advantage: How situational awareness training gives people like James an instinct for context that methodology-trained professionals often lack
  • [00:21] Practicing on Real Terrain: Andrea's experience joining a transport research group to deliberately practice mapping on systems, not just theory
  • [00:26] Defeating Weaponised Silence: Using multiple mapping groups to dilute political power — you can hide the Eiffel Tower in your map, but it appears in six others
  • [00:31] Maps Over Stories: Why challenging a map feels safe but challenging a story feels like challenging someone's leadership — and how Brexit supporters and opponents could argue productively through a map

Guest: Simon Wardley Hosts: Andrea Magnorsky, Kenny Schwegler, Andrew Harmel-Law

]]>We fight about Agile versus Six Sigma, build versus buy, in-house versus outsourced. We pick our camps and defend them with the certainty of people who've never mapped the territory they're fighting over. But what if the real problem isn't which method is right — it's that we're choosing methods before we understand what we're building?

That's the story Simon Wardley brought to this conversation, centred on HS2 — Britain's high-speed rail project. CIO James Finley needed to build a virtual railway before the physical one, because it's cheaper to mess up a virtual landscape than the English countryside. The typical government approach would bundle everything into domain-based contracts and outsource. Instead, James spent a Sunday afternoon doing something different: he mapped the entire system. Not a component diagram. A proper map — with users at the top, a chain of needs underneath, and a critical question about each component: how evolved is it? Custom-built land referencing systems on the left. Commodity compute on the right. Suddenly, the methodology war dissolved. You need Agile where things are novel and changing. Six Sigma where things are commodity. Lean in the middle. They built the system using multiple methods simultaneously — ahead of schedule, under budget.

But Simon doesn't stop at the success story. The conversation digs into the harder questions: what happens when people have built 20-year careers on a single methodology and you're implicitly telling them they've been doing it wrong? How do you handle dominant voices who weaponise information asymmetry in collaborative mapping sessions? And why do maps create safer spaces for challenge than stories — even when the topic is as divisive as Brexit?

Key Discussion Points

  • [00:01] The Virtual Railway: Why HS2 needed to model the entire railway digitally before breaking ground — and how James Finley approached it differently from typical government IT
  • [00:06] The Sunday Afternoon Map: How plotting components on an evolution axis — from genesis to commodity — dissolved the methodology debate
  • [00:10] Burning the Heretic: What happens when Simon tells Agile conferences that Agile isn't appropriate everywhere — and gets the same reaction at Six Sigma conferences
  • [00:13] The Excuse Loop: Why "we didn't specify the requirements well enough" is the most dangerous sentence in software delivery
  • [00:16] The Military Advantage: How situational awareness training gives people like James an instinct for context that methodology-trained professionals often lack
  • [00:21] Practicing on Real Terrain: Andrea's experience joining a transport research group to deliberately practice mapping on systems, not just theory
  • [00:26] Defeating Weaponised Silence: Using multiple mapping groups to dilute political power — you can hide the Eiffel Tower in your map, but it appears in six others
  • [00:31] Maps Over Stories: Why challenging a map feels safe but challenging a story feels like challenging someone's leadership — and how Brexit supporters and opponents could argue productively through a map

Guest: Simon Wardley Hosts: Andrea Magnorsky, Kenny Schwegler, Andrew Harmel-Law

]]>f124eda9-769d-442e-ac9f-b1a12d478ec6Tue, 14 Apr 2026 06:15:00 +000031:11falsefull1717When Fixing an Outage Means Staying Out of the WayWhen Fixing an Outage Means Staying Out of the WayWe often assume that resolving a major outage requires centralised command and control—getting the right experts in a room, coordinating their efforts, and directing the recovery. But what if the most important thing an incident commander can do is resist that impulse entirely, and simply create space for the right person to surface?

That's the situation Liz Fong-Jones found herself in during a July 2018 Google Cloud outage that took down nearly every service—not just Google's own, but every customer running on Google Cloud. As incident commander, Liz had the war room assembled, the escalation path triggered, and the right teams on the call. What broke the incident open was none of that. It was an engineer nobody had thought to page, who called in unprompted, said "I think this was my change," and had already started rolling it back.

That moment was only possible because of something built long before the outage: a culture where people don't hide under their desks when things break. Liz traces how psychological safety gets constructed—not in crises, but in how organisations respond to smaller failures every day. She shares the quiet signals that reveal when it's missing (the call that goes silent after an acronym nobody understands, the junior engineer who never speaks), and the heuristics she uses to build it deliberately as a senior engineer.

This conversation goes beyond incident response to explore what it actually means to build resilient systems and resilient people—and why those two things are inseparable.

Key Discussion Points

  • [00:01] The July 2018 Google Cloud Outage: Liz introduces her role as a volunteer incident commander and the scale of the incident—nearly every Google Cloud service down simultaneously
  • [06:00] The Fix That Came From Outside the War Room: An engineer nobody had thought to page calls in, identifies their change, and has already started the rollback before the room knows what's happening
  • [12:00] Why a Safety Feature Caused a System-Wide Failure: How a canary deployment designed to limit blast radius instead pushed metadata globally—and triggered a bug in every front end
  • [17:00] Distributed Debugging and the Limits of Centralisation: Why the person holding the critical piece of information is rarely in the escalation room, and how you design for that
  • [22:00] Psychological Safety Built Before the Crisis: Why the engineer's willingness to raise their hand depended entirely on how the organisation handles smaller failures day-to-day
  • [28:00] The Quiet Signals That Reveal Fear: Silence after acronyms, juniors who never speak, decisions nobody will revisit—how Liz reads the room for safety
  • [34:00] Design Ownership and Haunted Graveyards: Why accountability for running a system long-term requires input into its design—and what happens when it doesn't exist
  • [40:00] Building Resilient People, Not Just Systems: If an organisation crushes someone when they make a mistake, they won't be resilient the next time something breaks—and something always breaks

Guest: Liz Fong-Jones Hosts: Andrea Magnorsky, Kenny Schwegler

]]>We often assume that resolving a major outage requires centralised command and control—getting the right experts in a room, coordinating their efforts, and directing the recovery. But what if the most important thing an incident commander can do is resist that impulse entirely, and simply create space for the right person to surface?

That's the situation Liz Fong-Jones found herself in during a July 2018 Google Cloud outage that took down nearly every service—not just Google's own, but every customer running on Google Cloud. As incident commander, Liz had the war room assembled, the escalation path triggered, and the right teams on the call. What broke the incident open was none of that. It was an engineer nobody had thought to page, who called in unprompted, said "I think this was my change," and had already started rolling it back.

That moment was only possible because of something built long before the outage: a culture where people don't hide under their desks when things break. Liz traces how psychological safety gets constructed—not in crises, but in how organisations respond to smaller failures every day. She shares the quiet signals that reveal when it's missing (the call that goes silent after an acronym nobody understands, the junior engineer who never speaks), and the heuristics she uses to build it deliberately as a senior engineer.

This conversation goes beyond incident response to explore what it actually means to build resilient systems and resilient people—and why those two things are inseparable.

Key Discussion Points

  • [00:01] The July 2018 Google Cloud Outage: Liz introduces her role as a volunteer incident commander and the scale of the incident—nearly every Google Cloud service down simultaneously
  • [06:00] The Fix That Came From Outside the War Room: An engineer nobody had thought to page calls in, identifies their change, and has already started the rollback before the room knows what's happening
  • [12:00] Why a Safety Feature Caused a System-Wide Failure: How a canary deployment designed to limit blast radius instead pushed metadata globally—and triggered a bug in every front end
  • [17:00] Distributed Debugging and the Limits of Centralisation: Why the person holding the critical piece of information is rarely in the escalation room, and how you design for that
  • [22:00] Psychological Safety Built Before the Crisis: Why the engineer's willingness to raise their hand depended entirely on how the organisation handles smaller failures day-to-day
  • [28:00] The Quiet Signals That Reveal Fear: Silence after acronyms, juniors who never speak, decisions nobody will revisit—how Liz reads the room for safety
  • [34:00] Design Ownership and Haunted Graveyards: Why accountability for running a system long-term requires input into its design—and what happens when it doesn't exist
  • [40:00] Building Resilient People, Not Just Systems: If an organisation crushes someone when they make a mistake, they won't be resilient the next time something breaks—and something always breaks

Guest: Liz Fong-Jones Hosts: Andrea Magnorsky, Kenny Schwegler

]]>cae1c91a-e8c6-401d-aaf6-58f4d3eac439Tue, 31 Mar 2026 07:15:00 +000024:08falsefull1616When Explaining More Isn't the AnswerWhen Explaining More Isn't the AnswerWe often assume that when people resist a new architectural direction, the answer is to explain better — clearer diagrams, more detailed documents, another walkthrough of the rationale. Diana Montalion spent twenty years perfecting this instinct. Then she realized she was Sisyphus: pushing the same rock up the same hills, and getting flattened every time it rolled back down.

The shift came at Kripalu, a retreat center where Diana had gone to rest from the exhaustion of constant explanation. The environment was overwhelmingly female — the opposite of the tech spaces where she'd spent her career, often as the only woman in the room. Learning happened there through movement and experience, not endless discussion. When her phone pinged with a question from the DDD Europe organizer — "You said this could be a workshop. What would you do?" — the answer suddenly felt obvious: design an experience, not an explanation.

What followed was a workshop that used the iceberg model to help participants understand how systems generate outcomes — using, as their subject, the fact that 91.88% of software developers are male. Nobody debated gender politics. Instead, working in groups, they modelled how a system produces that result, then designed a different system. Diana has run it four or five times now and learns something new every time. Back in her current role, she's applying the same logic to architectural change: rather than explaining until people understand, she tries things with them — and finds that people who were deeply resistant often pick up the ball and run with it once they've had the experience.

This conversation explores what it actually takes to move from explanation to experience — including how to work inside genuine uncertainty, how to interrupt cognitive patterns without steering people to your predetermined answer, and why facilitative leadership is, in Diana's words, genuinely harder than just telling people what to do.

Key Discussion Points

  1. [00:01] The Sisyphus Pattern: Diana names her core habit — when facing resistance, explain more — and the exhaustion that finally forced her to question it
  2. [03:00] The Kripalu Moment: A retreat centre, a predominantly female room, and a way of learning through experience rather than discussion that stops Diana cold
  3. [04:00] The DDD Europe Workshop: How a well-timed ping from the conference organiser became the prompt to design an iceberg model workshop unlike anything she'd done before
  4. [06:00] Modelling the Patriarchy: How asking teams to model a system that produces 91.88% male developers — not to debate gender, but to practise systems thinking — unlocks participation in a way no lecture ever could
  5. [08:00] Architectural Miracles: In her current role, Diana catches herself falling back into "explain more" — and experiments with just trying things instead, with surprising results
  6. [12:00] There Is Only Uncertainty: Diana's perspective on complexity, consent, and why promising important insight rather than solved problems is the honest deliverable
  7. [22:00] Flying with the Flock: The delicate balance between listening, facilitating, and nudging — knowing when to interrupt a cognitive pattern without simply steering people to your own answer
  8. [28:00] A Science and an Art: How facilitation is both deep listening and an energetic interruption of pattern — and why the hardest part is the work itself, once the friction is gone

Guest: Diana Montalion Hosts: Andrea Magnorsky, Kenny Schwegler

Part of the Stories on Facilitating Software Architecture and Design series from Virtual DDD.

]]>We often assume that when people resist a new architectural direction, the answer is to explain better — clearer diagrams, more detailed documents, another walkthrough of the rationale. Diana Montalion spent twenty years perfecting this instinct. Then she realized she was Sisyphus: pushing the same rock up the same hills, and getting flattened every time it rolled back down.

The shift came at Kripalu, a retreat center where Diana had gone to rest from the exhaustion of constant explanation. The environment was overwhelmingly female — the opposite of the tech spaces where she'd spent her career, often as the only woman in the room. Learning happened there through movement and experience, not endless discussion. When her phone pinged with a question from the DDD Europe organizer — "You said this could be a workshop. What would you do?" — the answer suddenly felt obvious: design an experience, not an explanation.

What followed was a workshop that used the iceberg model to help participants understand how systems generate outcomes — using, as their subject, the fact that 91.88% of software developers are male. Nobody debated gender politics. Instead, working in groups, they modelled how a system produces that result, then designed a different system. Diana has run it four or five times now and learns something new every time. Back in her current role, she's applying the same logic to architectural change: rather than explaining until people understand, she tries things with them — and finds that people who were deeply resistant often pick up the ball and run with it once they've had the experience.

This conversation explores what it actually takes to move from explanation to experience — including how to work inside genuine uncertainty, how to interrupt cognitive patterns without steering people to your predetermined answer, and why facilitative leadership is, in Diana's words, genuinely harder than just telling people what to do.

Key Discussion Points

  1. [00:01] The Sisyphus Pattern: Diana names her core habit — when facing resistance, explain more — and the exhaustion that finally forced her to question it
  2. [03:00] The Kripalu Moment: A retreat centre, a predominantly female room, and a way of learning through experience rather than discussion that stops Diana cold
  3. [04:00] The DDD Europe Workshop: How a well-timed ping from the conference organiser became the prompt to design an iceberg model workshop unlike anything she'd done before
  4. [06:00] Modelling the Patriarchy: How asking teams to model a system that produces 91.88% male developers — not to debate gender, but to practise systems thinking — unlocks participation in a way no lecture ever could
  5. [08:00] Architectural Miracles: In her current role, Diana catches herself falling back into "explain more" — and experiments with just trying things instead, with surprising results
  6. [12:00] There Is Only Uncertainty: Diana's perspective on complexity, consent, and why promising important insight rather than solved problems is the honest deliverable
  7. [22:00] Flying with the Flock: The delicate balance between listening, facilitating, and nudging — knowing when to interrupt a cognitive pattern without simply steering people to your own answer
  8. [28:00] A Science and an Art: How facilitation is both deep listening and an energetic interruption of pattern — and why the hardest part is the work itself, once the friction is gone

Guest: Diana Montalion Hosts: Andrea Magnorsky, Kenny Schwegler

Part of the Stories on Facilitating Software Architecture and Design series from Virtual DDD.

]]>546b1af7-d871-41ff-abb0-265d4cf7611cTue, 17 Mar 2026 07:15:00 +000029:26falsefull1515When the Loudest Voice in the Room Architects Your FutureWhen the Loudest Voice in the Room Architects Your FutureWe often assume that bad architectural decisions come from bad architects. But what if there are no architects at all—just a team of software developers trying to do their best, with no one in the room who knows how to facilitate a decision of that magnitude?

That's the situation Gien Verschatse found herself in early in her career. The team had just been pulled off a Phoenix project—a fresh-start initiative killed after six months—and reassigned to maintain a legacy system built on technologies that were outdated even then. Eager to modernise, Gien organised an EventStorming session to map the technical debt from an emotional angle: what frustrates you most? What makes your job difficult? The session was, in her words, an absolute disaster—she couldn't get people to step away from how the system currently worked. Meanwhile, a developer with a dominant personality pushed hard for an event sourcing implementation. It was cutting-edge technology, exciting, new. And that was enough. "The person who was the loudest in the meeting got their way. There was no plan. There was no sitting down and thinking this through. It was just 'this is the latest and greatest and we're going to do that.'"

The event sourcing system got built entirely alongside the existing codebase. The emotional wall of technical debt stayed untouched. QA didn't know how to test the new system. IT didn't know how to deploy it. People started leaving. Gien eventually left too—after a massive burnout, feeling like she'd failed. It took fifteen years and a career as a consultant to see it clearly: the problem wasn't the technology. It was that nobody in that room knew how to make architectural decisions together, and nobody was there to facilitate the ones that needed to be made.

This conversation explores what happens when dominant personalities fill the vacuum left by absent facilitation, why value-based heuristics are a more effective lever than emotional appeals, and what Gien—now co-author of a book on decision-making—would do differently today.

Key Discussion Points

  1. [00:01] The Phoenix That Died: Gien's team is pulled off a promising fresh-start project and reassigned to a legacy system with outdated technology
  2. [03:00] The EventStorming That Failed: An attempt to map technical debt emotionally collapses—the team can't imagine beyond how the system currently works
  3. [04:00] The Loudest Voice Wins: A dominant developer pushes event sourcing through with no plan, no consequence-mapping, and no one with the skills to push back
  4. [05:00] The Architecture That Solved Nothing: The new system is built alongside the old one; QA can't test it, IT can't deploy it, the technical debt remains untouched
  5. [06:00] The Exodus and the Burnout: People leave one by one; Gien leaves after burnout, carrying a sense of personal failure that took years to reframe
  6. [09:00] Quit Sooner: Gien's hard-won advice—it's okay to leave bad environments, and finding one is not a personal failure
  7. [20:00] Digging Into the Preference: How Gien now uncovers the value-based heuristics driving strong positions—fear of skill obsolescence, career anxiety—without triggering defensive reactions
  8. [22:00] Talking About Emotions Without Talking About Emotions: After 20 years in a male-dominated industry, Gien's approach to surfacing emotional drivers through values-based framing

Guest: Gien Verschatse, Evelyn van Kelle Hosts: Kenny Schwegler, Andrea Magnorsky

]]>We often assume that bad architectural decisions come from bad architects. But what if there are no architects at all—just a team of software developers trying to do their best, with no one in the room who knows how to facilitate a decision of that magnitude?

That's the situation Gien Verschatse found herself in early in her career. The team had just been pulled off a Phoenix project—a fresh-start initiative killed after six months—and reassigned to maintain a legacy system built on technologies that were outdated even then. Eager to modernise, Gien organised an EventStorming session to map the technical debt from an emotional angle: what frustrates you most? What makes your job difficult? The session was, in her words, an absolute disaster—she couldn't get people to step away from how the system currently worked. Meanwhile, a developer with a dominant personality pushed hard for an event sourcing implementation. It was cutting-edge technology, exciting, new. And that was enough. "The person who was the loudest in the meeting got their way. There was no plan. There was no sitting down and thinking this through. It was just 'this is the latest and greatest and we're going to do that.'"

The event sourcing system got built entirely alongside the existing codebase. The emotional wall of technical debt stayed untouched. QA didn't know how to test the new system. IT didn't know how to deploy it. People started leaving. Gien eventually left too—after a massive burnout, feeling like she'd failed. It took fifteen years and a career as a consultant to see it clearly: the problem wasn't the technology. It was that nobody in that room knew how to make architectural decisions together, and nobody was there to facilitate the ones that needed to be made.

This conversation explores what happens when dominant personalities fill the vacuum left by absent facilitation, why value-based heuristics are a more effective lever than emotional appeals, and what Gien—now co-author of a book on decision-making—would do differently today.

Key Discussion Points

  1. [00:01] The Phoenix That Died: Gien's team is pulled off a promising fresh-start project and reassigned to a legacy system with outdated technology
  2. [03:00] The EventStorming That Failed: An attempt to map technical debt emotionally collapses—the team can't imagine beyond how the system currently works
  3. [04:00] The Loudest Voice Wins: A dominant developer pushes event sourcing through with no plan, no consequence-mapping, and no one with the skills to push back
  4. [05:00] The Architecture That Solved Nothing: The new system is built alongside the old one; QA can't test it, IT can't deploy it, the technical debt remains untouched
  5. [06:00] The Exodus and the Burnout: People leave one by one; Gien leaves after burnout, carrying a sense of personal failure that took years to reframe
  6. [09:00] Quit Sooner: Gien's hard-won advice—it's okay to leave bad environments, and finding one is not a personal failure
  7. [20:00] Digging Into the Preference: How Gien now uncovers the value-based heuristics driving strong positions—fear of skill obsolescence, career anxiety—without triggering defensive reactions
  8. [22:00] Talking About Emotions Without Talking About Emotions: After 20 years in a male-dominated industry, Gien's approach to surfacing emotional drivers through values-based framing

Guest: Gien Verschatse, Evelyn van Kelle Hosts: Kenny Schwegler, Andrea Magnorsky

]]>39d4201d-1de5-4d28-92c1-2c755489223eTue, 03 Mar 2026 07:15:00 +000021:50falsefull1414The Slow Clap That Killed the WorkshopThe Slow Clap That Killed the WorkshopWe often assume the hardest part of facilitation is designing the exercises. But what happens when hierarchy doesn't just shape the conversation — it physically stops it?

That's the story Evelyn van Kelle brought to this episode. She was a few weeks into working with a company going through major changes — uncertainty everywhere, fingers being pointed, decisions being avoided. She and a colleague proposed an EventStorming session. Leadership called it "a wasted day." Participants showed up hesitant, conversations stayed high-level, and there were no disagreements — a red flag for any facilitator. People were asking permission just to move a sticky note. Then there was the CTO. He wouldn't participate, but he'd walk in periodically, arms crossed, sometimes dropping a sarcastic comment. Each time, the entire group froze. But the grand finale came during a sense-making exercise: for the first time all day, someone was sharing something vulnerable. The CTO walked in, listened, and after a few seconds of silence — slow clapped. The room went silent. Everyone looked to the facilitators. Evelyn and her co-facilitator were overwhelmed.

What followed — and what Evelyn learned from it — is a masterclass in what facilitators do when their own physical reactions are peaking, when safety collapses in real time, and when dominant behaviour reveals how fragile the conditions for collaboration really were. This conversation explores the line between being neutral and acting neutral, why understanding destructive behaviour matters more than condemning it, and what Evelyn would do differently if she could go back.

Key Discussion Points

  1. [00:01] Physical Reactions as Data: Evelyn explains why intense physical responses during facilitation are a signal to act, not to freeze
  2. [00:03] "A Wasted Day": How leadership's resistance to the session set the conditions for failure before it even began
  3. [00:05] Working Too Hard: The facilitator heuristic — when you're working harder than the group, something structural is blocking participation
  4. [00:06] The CTO's Rounds: Arms crossed, sarcastic comments, no questions — and how the whole group froze every time he walked in
  5. [00:08] The Slow Clap: The moment a vulnerable breakthrough was met with the CTO's slow clap, and how it peaked the facilitators' own physical reactions
  6. [00:11] Understanding, Not Excusing: Evelyn's one-on-one with the CTO — learning that his behaviour earned him compliments from peers
  7. [00:14] The Session That Shouldn't Have Happened: Why making collaborative modeling "business as usual" might have worked better than a big official event
  8. [00:18] Acting Neutral vs. Being Neutral: Why facilitators can't truly be neutral, but must avoid setting the emotional tone for the group

Guest: Evelyn van Kelle, Gien Verschatse Hosts: Andrea Magnorsky, Kenny Schwegler

]]>We often assume the hardest part of facilitation is designing the exercises. But what happens when hierarchy doesn't just shape the conversation — it physically stops it?

That's the story Evelyn van Kelle brought to this episode. She was a few weeks into working with a company going through major changes — uncertainty everywhere, fingers being pointed, decisions being avoided. She and a colleague proposed an EventStorming session. Leadership called it "a wasted day." Participants showed up hesitant, conversations stayed high-level, and there were no disagreements — a red flag for any facilitator. People were asking permission just to move a sticky note. Then there was the CTO. He wouldn't participate, but he'd walk in periodically, arms crossed, sometimes dropping a sarcastic comment. Each time, the entire group froze. But the grand finale came during a sense-making exercise: for the first time all day, someone was sharing something vulnerable. The CTO walked in, listened, and after a few seconds of silence — slow clapped. The room went silent. Everyone looked to the facilitators. Evelyn and her co-facilitator were overwhelmed.

What followed — and what Evelyn learned from it — is a masterclass in what facilitators do when their own physical reactions are peaking, when safety collapses in real time, and when dominant behaviour reveals how fragile the conditions for collaboration really were. This conversation explores the line between being neutral and acting neutral, why understanding destructive behaviour matters more than condemning it, and what Evelyn would do differently if she could go back.

Key Discussion Points

  1. [00:01] Physical Reactions as Data: Evelyn explains why intense physical responses during facilitation are a signal to act, not to freeze
  2. [00:03] "A Wasted Day": How leadership's resistance to the session set the conditions for failure before it even began
  3. [00:05] Working Too Hard: The facilitator heuristic — when you're working harder than the group, something structural is blocking participation
  4. [00:06] The CTO's Rounds: Arms crossed, sarcastic comments, no questions — and how the whole group froze every time he walked in
  5. [00:08] The Slow Clap: The moment a vulnerable breakthrough was met with the CTO's slow clap, and how it peaked the facilitators' own physical reactions
  6. [00:11] Understanding, Not Excusing: Evelyn's one-on-one with the CTO — learning that his behaviour earned him compliments from peers
  7. [00:14] The Session That Shouldn't Have Happened: Why making collaborative modeling "business as usual" might have worked better than a big official event
  8. [00:18] Acting Neutral vs. Being Neutral: Why facilitators can't truly be neutral, but must avoid setting the emotional tone for the group

Guest: Evelyn van Kelle, Gien Verschatse Hosts: Andrea Magnorsky, Kenny Schwegler

]]>2ffa26c7-e26d-47f2-9b07-19a7c61c431bTue, 17 Feb 2026 07:30:00 +000023:15falsefull1313When Everyone Agrees But Nobody ActsWhen Everyone Agrees But Nobody ActsWe often assume that once we get everyone in a room and reach agreement on an architecture, the hard part is over. But what happens when the workshop goes perfectly, everyone nods along, puts their sticky note on "Yes, I support this," and then four weeks later... nobody has shipped anything?

That's the pattern Xin Yao encountered twice in her career—separated by seven years and what should have been much better facilitation techniques the second time around. In her first story, Xin orchestrated a multi-day integration architecture workshop for a major financial institution. Cross-functional teams aligned on APIs, event-driven patterns, and walked away with a clear action list. Four weeks later, an engineering manager asked the question nobody wanted to hear: "Did you notice anybody was excited about it?" The answer was no. The work? Also no.

Seven years later, armed with Event Storming and collaborative modeling techniques, Xin tried again. This time it was a DDD workshop during COVID, with real-time collaboration and all the right practices. But the timeline wouldn't merge, participants couldn't walk through the model without Xin taking over, and the board ended up more red (hotspots and conflicts) than orange (domain events). In the retrospective, someone said: "The whiteboard doesn't compile." Another admitted: "We didn't want to ruin it for you—you had so much passion."

This conversation explores the gap between facilitation techniques and the emotional safety required to make them work. We dig into why "success theater" happens, how to invite dissent from the very beginning, and why architects need to remember they're "feeling machines that think"—not thinking machines that feel.

Key Discussion Points

* [00:01] The Flying Squad: Xin's role as an integration architect parachuting into a multi-day workshop for a major CRM integration project

* [06:00] Agreement Without Excitement: Four weeks after a "successful" workshop, the action list sits untouched—nobody shipped

* [08:00] The Event Storming That Wouldn't Merge: Seven years later with better techniques, but the timeline clusters, the facilitator becomes the bottleneck, and the board turns red

* [12:00] "The Whiteboard Doesn't Compile": Why participants stayed silent when the entry and exit events were wrong from the start

* [16:00] Taking the Authority Out: How Xin learned to say "I'm a couple steps ahead, not the expert—trust your own experience"

* [21:00] Inviting Dissent Early: The heuristic of pausing every 10 minutes to ask "What would you say if you didn't have to be polite?"

* [36:00] Connection Before Content: Why breaking into small groups of three creates the safety to surface real concerns

* [38:00] Feeling Machines That Think: The role of emotion in architectural decision-making and why facilitators need to invite emotional language into the room

**Guest:** Xin Yao

**Hosts:** Andrew Harmel-Law, Kenny Schwegler, Andrea Magnorsky

*Part of the Stories on Facilitating Software Architecture and Design series from Virtual DDD.*

]]>We often assume that once we get everyone in a room and reach agreement on an architecture, the hard part is over. But what happens when the workshop goes perfectly, everyone nods along, puts their sticky note on "Yes, I support this," and then four weeks later... nobody has shipped anything?

That's the pattern Xin Yao encountered twice in her career—separated by seven years and what should have been much better facilitation techniques the second time around. In her first story, Xin orchestrated a multi-day integration architecture workshop for a major financial institution. Cross-functional teams aligned on APIs, event-driven patterns, and walked away with a clear action list. Four weeks later, an engineering manager asked the question nobody wanted to hear: "Did you notice anybody was excited about it?" The answer was no. The work? Also no.

Seven years later, armed with Event Storming and collaborative modeling techniques, Xin tried again. This time it was a DDD workshop during COVID, with real-time collaboration and all the right practices. But the timeline wouldn't merge, participants couldn't walk through the model without Xin taking over, and the board ended up more red (hotspots and conflicts) than orange (domain events). In the retrospective, someone said: "The whiteboard doesn't compile." Another admitted: "We didn't want to ruin it for you—you had so much passion."

This conversation explores the gap between facilitation techniques and the emotional safety required to make them work. We dig into why "success theater" happens, how to invite dissent from the very beginning, and why architects need to remember they're "feeling machines that think"—not thinking machines that feel.

Key Discussion Points

* [00:01] The Flying Squad: Xin's role as an integration architect parachuting into a multi-day workshop for a major CRM integration project

* [06:00] Agreement Without Excitement: Four weeks after a "successful" workshop, the action list sits untouched—nobody shipped

* [08:00] The Event Storming That Wouldn't Merge: Seven years later with better techniques, but the timeline clusters, the facilitator becomes the bottleneck, and the board turns red

* [12:00] "The Whiteboard Doesn't Compile": Why participants stayed silent when the entry and exit events were wrong from the start

* [16:00] Taking the Authority Out: How Xin learned to say "I'm a couple steps ahead, not the expert—trust your own experience"

* [21:00] Inviting Dissent Early: The heuristic of pausing every 10 minutes to ask "What would you say if you didn't have to be polite?"

* [36:00] Connection Before Content: Why breaking into small groups of three creates the safety to surface real concerns

* [38:00] Feeling Machines That Think: The role of emotion in architectural decision-making and why facilitators need to invite emotional language into the room

**Guest:** Xin Yao

**Hosts:** Andrew Harmel-Law, Kenny Schwegler, Andrea Magnorsky

*Part of the Stories on Facilitating Software Architecture and Design series from Virtual DDD.*

]]>57ee2f33-ce16-48a8-9d82-320393458a5eTue, 03 Feb 2026 07:15:00 +000036:11falsefull1212Misaligned Expectations: When Goals Don't AlignMisaligned Expectations: When Goals Don't AlignWe often assume that once we get everyone into a room for a collaborative modeling session, the hardest part is over. But what happens when you discover—just 48 hours before kickoff—that the person signing the checks has a fundamentally different definition of success than the product team?. In this episode, Beija Nigl joins Kenny and Andrew to share a candid story about a legacy migration project where the goalposts moved before the game even started.

Beija recounts her experience facilitating a workshop intended to handle a 20-year-old legacy system where Java 8 support was running out. While the Product Owner wanted to completely "rethink" the broken processes, the sponsor introduced the session as a documentation exercise to rebuild the system's edge cases "as-is". This critical misalignment led to a room full of business experts getting bogged down in technical implementation details—debating status codes like "Status 800" and "nightly runs"—rather than solving the underlying business problems.

This conversation goes deep into the socio-technical challenges of our work. We explore the emotional attachment stakeholders have to legacy complexity and how facilitators can navigate power dynamics when the "ground truth" is uncomfortable. Beija also reveals how this challenging experience became the catalyst for creating the "Como Prep Canvas," a tool designed to surface these conflicting motivations before the sticky notes ever hit the wall.

Key Discussion Points

  1. [00:01] The Legacy Trap: Setting the stage for a workshop to replace a 20-year-old system facing end-of-life support.
  2. [03:00] The "Rebuild" vs. "Rethink" Conflict: Discovering at the 11th hour that the sponsor wants to document edge cases while the team wants to fix the process.
  3. [05:00] When Technical Debt Hijacks the Conversation: How the workshop drifted into mapping status codes (e.g., Status 800 vs. 305) instead of business value.
  4. [08:00] Emotional Safety in Modeling: Understanding why experts cling to complex legacy numbers as a form of job security and identity.
  5. [13:00] The Facilitator’s Dilemma: Navigating the tension of facilitation when you cannot refer to an aligned goal because one doesn't exist.
  6. [16:00] Delivering the "Ground Truth": The consultant's responsibility to present uncomfortable findings to leadership to drive organizational alignment.
  7. [19:00] Aligning on Intent: How to prepare mentally to ensure you are solving the right problem for the business success.

Resources Mentioned

  1. Como Prep Canvas: The tool Beija developed with the DDD-crew to better align stakeholder expectations prior to collaborative modeling. https://github.com/ddd-crew/como-prep-canvas

]]>We often assume that once we get everyone into a room for a collaborative modeling session, the hardest part is over. But what happens when you discover—just 48 hours before kickoff—that the person signing the checks has a fundamentally different definition of success than the product team?. In this episode, Beija Nigl joins Kenny and Andrew to share a candid story about a legacy migration project where the goalposts moved before the game even started.

Beija recounts her experience facilitating a workshop intended to handle a 20-year-old legacy system where Java 8 support was running out. While the Product Owner wanted to completely "rethink" the broken processes, the sponsor introduced the session as a documentation exercise to rebuild the system's edge cases "as-is". This critical misalignment led to a room full of business experts getting bogged down in technical implementation details—debating status codes like "Status 800" and "nightly runs"—rather than solving the underlying business problems.

This conversation goes deep into the socio-technical challenges of our work. We explore the emotional attachment stakeholders have to legacy complexity and how facilitators can navigate power dynamics when the "ground truth" is uncomfortable. Beija also reveals how this challenging experience became the catalyst for creating the "Como Prep Canvas," a tool designed to surface these conflicting motivations before the sticky notes ever hit the wall.

Key Discussion Points

  1. [00:01] The Legacy Trap: Setting the stage for a workshop to replace a 20-year-old system facing end-of-life support.
  2. [03:00] The "Rebuild" vs. "Rethink" Conflict: Discovering at the 11th hour that the sponsor wants to document edge cases while the team wants to fix the process.
  3. [05:00] When Technical Debt Hijacks the Conversation: How the workshop drifted into mapping status codes (e.g., Status 800 vs. 305) instead of business value.
  4. [08:00] Emotional Safety in Modeling: Understanding why experts cling to complex legacy numbers as a form of job security and identity.
  5. [13:00] The Facilitator’s Dilemma: Navigating the tension of facilitation when you cannot refer to an aligned goal because one doesn't exist.
  6. [16:00] Delivering the "Ground Truth": The consultant's responsibility to present uncomfortable findings to leadership to drive organizational alignment.
  7. [19:00] Aligning on Intent: How to prepare mentally to ensure you are solving the right problem for the business success.

Resources Mentioned

  1. Como Prep Canvas: The tool Beija developed with the DDD-crew to better align stakeholder expectations prior to collaborative modeling. https://github.com/ddd-crew/como-prep-canvas

]]>c328974e-e58f-4054-87e4-7945ca286668Tue, 20 Jan 2026 07:30:00 +000023:20falsefull1111Modernizing with Respect: Acknowledging the Best Intentions Behind Legacy CodeModernizing with Respect: Acknowledging the Best Intentions Behind Legacy CodeWe have all been there: you walk into a new client engagement ready to implement modern patterns, only to find a tangle of a 20-year-old legacy system and a wall of resistance from the existing staff. It’s easy to label the old system as "crap" and the gatekeepers as "blockers," but what if that legacy system is the only reason the company survived long enough to hire you?

In this episode of Stories of Facilitating Software Design and Architecture, Michael Plöd shares a powerful story about a modernisation project that was nearly derailed by a "difficult" stakeholder. By taking a massive emotional risk and stepping away from the technical arguments to ask, "Why are you resisting?", Michael uncovered that he was criticising the life's work of the company's original "rockstar developer."

Michael, together with Beija and hosts Andrea, Kenny, and Andrew, explores the critical role of empathy in architecture. They discuss how to reframe legacy conversations using Gregor Hohpe’s concept of shifting from "Economies of Scale" to "Economies of Speed," and why the most important tool in an architect's belt isn't Kubernetes—it’s the ability to ride the "elevator" between the engine room and the penthouse without losing the message.

Key Discussion Points

  1. [00:02:50] Conference Driven Development: The danger of throwing buzzwords like Microservices, DDD, and Kubernetes at a problem without understanding the context.
  2. [00:06:00] The Hidden History of Legacy: Discovering that the "blocker" in the room is often the creator of the system that earned the company millions.
  3. [00:09:20] Contextual Reframing: How to explain the need for change by contrasting the historical need for "Economies of Scale" (centralization/control) with today's need for "Economies of Speed."
  4. [00:10:00] The Architect as Path-Maker: Transforming a legacy developer from a defender of the old guard into the architect of the new context.
  5. [00:14:00] Professional Resilience: How to draw boundaries and not take professional resistance as a personal attack, allowing you to stay objective in heated modernization efforts.
  6. [00:25:00] Riding the Elevator: Why stakeholder communication—translating technical complexity for different audiences—is the number one skill for aspiring architects.

]]>We have all been there: you walk into a new client engagement ready to implement modern patterns, only to find a tangle of a 20-year-old legacy system and a wall of resistance from the existing staff. It’s easy to label the old system as "crap" and the gatekeepers as "blockers," but what if that legacy system is the only reason the company survived long enough to hire you?

In this episode of Stories of Facilitating Software Design and Architecture, Michael Plöd shares a powerful story about a modernisation project that was nearly derailed by a "difficult" stakeholder. By taking a massive emotional risk and stepping away from the technical arguments to ask, "Why are you resisting?", Michael uncovered that he was criticising the life's work of the company's original "rockstar developer."

Michael, together with Beija and hosts Andrea, Kenny, and Andrew, explores the critical role of empathy in architecture. They discuss how to reframe legacy conversations using Gregor Hohpe’s concept of shifting from "Economies of Scale" to "Economies of Speed," and why the most important tool in an architect's belt isn't Kubernetes—it’s the ability to ride the "elevator" between the engine room and the penthouse without losing the message.

Key Discussion Points

  1. [00:02:50] Conference Driven Development: The danger of throwing buzzwords like Microservices, DDD, and Kubernetes at a problem without understanding the context.
  2. [00:06:00] The Hidden History of Legacy: Discovering that the "blocker" in the room is often the creator of the system that earned the company millions.
  3. [00:09:20] Contextual Reframing: How to explain the need for change by contrasting the historical need for "Economies of Scale" (centralization/control) with today's need for "Economies of Speed."
  4. [00:10:00] The Architect as Path-Maker: Transforming a legacy developer from a defender of the old guard into the architect of the new context.
  5. [00:14:00] Professional Resilience: How to draw boundaries and not take professional resistance as a personal attack, allowing you to stay objective in heated modernization efforts.
  6. [00:25:00] Riding the Elevator: Why stakeholder communication—translating technical complexity for different audiences—is the number one skill for aspiring architects.

]]>9e596e88-6d5a-4c61-91f2-6ae67d039f9bTue, 06 Jan 2026 07:30:00 +000024:51falsefull1010The Hidden Weight of Rank: How Well-Intended Improvement Sessions can Drive Teammates AwayThe Hidden Weight of Rank: How Well-Intended Improvement Sessions can Drive Teammates AwayIn this episode of Stories on Facilitating Software Design and Architecture, we are joined by Paul Rayner, a seasoned consultant and expert in Domain-Driven Design and EventStorming. Paul shares a candid "war story" from his time as a tech lead that completely changed how he views leadership and influence. He recounts a well-intentioned refactoring session where he publicly critiqued a team member's code, aiming to teach better practices. The result was unexpected and severe: the developer felt shamed by the experience and quit shortly after.

This experience served as a harsh wake-up call about the "unseen authority" leaders wield and how easily the "blast radius" of our actions can damage team psychological safety, even when our motives are pure. Paul opens up about the "dominant blindness" that often affects technical leaders—where we fail to see how our rank amplifies our words, turning a simple suggestion into a crushing directive.

We dive deep into the power dynamics of technical leadership, exploring why simply having the "right" technical solution isn't enough. The conversation covers how to move from "fixing" people's work to facilitating their growth, why resistance should be treated as a valuable resource rather than an obstacle, and how methods like EventStorming can help externalize conflict.

Key Learning Points:

  1. The Gap Between Intent and Impact: Why "I meant well" is never a sufficient excuse when a team member feels alienated or embarrassed by your actions.
  2. Dominant Blindness: How leaders often underestimate the heavy weight of their rank and the pressure it puts on colleagues, especially when navigating contractor-employee dynamics.
  3. Resistance is a Resource: Instead of pushing harder against pushback, view it as a signal to understand the underlying fears, threats, or misunderstandings driving the resistance.
  4. Challenging Mental Models: Recognizing that when you criticize code, you are often challenging the deep-seated mental models and hard work of the person who wrote it.
  5. Externalizing the Problem: How using visual tools like sticky notes (e.g., in EventStorming) can shift the focus from "me vs. you" to a collaborative discussion about the problem on the wall.

]]>In this episode of Stories on Facilitating Software Design and Architecture, we are joined by Paul Rayner, a seasoned consultant and expert in Domain-Driven Design and EventStorming. Paul shares a candid "war story" from his time as a tech lead that completely changed how he views leadership and influence. He recounts a well-intentioned refactoring session where he publicly critiqued a team member's code, aiming to teach better practices. The result was unexpected and severe: the developer felt shamed by the experience and quit shortly after.

This experience served as a harsh wake-up call about the "unseen authority" leaders wield and how easily the "blast radius" of our actions can damage team psychological safety, even when our motives are pure. Paul opens up about the "dominant blindness" that often affects technical leaders—where we fail to see how our rank amplifies our words, turning a simple suggestion into a crushing directive.

We dive deep into the power dynamics of technical leadership, exploring why simply having the "right" technical solution isn't enough. The conversation covers how to move from "fixing" people's work to facilitating their growth, why resistance should be treated as a valuable resource rather than an obstacle, and how methods like EventStorming can help externalize conflict.

Key Learning Points:

  1. The Gap Between Intent and Impact: Why "I meant well" is never a sufficient excuse when a team member feels alienated or embarrassed by your actions.
  2. Dominant Blindness: How leaders often underestimate the heavy weight of their rank and the pressure it puts on colleagues, especially when navigating contractor-employee dynamics.
  3. Resistance is a Resource: Instead of pushing harder against pushback, view it as a signal to understand the underlying fears, threats, or misunderstandings driving the resistance.
  4. Challenging Mental Models: Recognizing that when you criticize code, you are often challenging the deep-seated mental models and hard work of the person who wrote it.
  5. Externalizing the Problem: How using visual tools like sticky notes (e.g., in EventStorming) can shift the focus from "me vs. you" to a collaborative discussion about the problem on the wall.

]]>cafee170-d3be-46e6-90fb-2447349e7d38Tue, 23 Dec 2025 07:30:00 +000024:20falsefull99The true cost of "The simplest thing to do"The true cost of "The simplest thing to do"In software architecture, there is often a difficult tension between enforcing best practices and allowing teams the autonomy to learn through experience. One of the most common pitfalls in Event-Driven Architecture is the confusion between meaningful Domain Events and mere technical noise. When a team insists on the "easy way," is it better for an architect to block them or let them proceed into a potential disaster?.

In this episode, we are joined by Krisztina Hirth, Staff Engineer at PayFit and a longtime Virtual DDD co-organizer. Krisztina shares a candid story about a high-throughput team that insisted on publishing technical JSON logs rather than proper domain events because they didn't want to "mess up" their clean repository. Rather than forcing her will in a one-hour meeting, Krisztina made the calculated decision to let the tigers roam: she allowed the team to fail so they could learn the lesson empirically.

This conversation dives deep into the patience required for true socio-technical change. We explore why "going fast is often just wrong" and how a failure that generated 90% useless noise eventually led to a robust RFC process and a company-wide understanding of Domain-Driven Design. As Krisztina puts it, sometimes what looks like a mistake is actually just an "asynchronous domain modeling session" that takes eight months to complete.

3. Key Discussion Points

[00:01:00] The Trap of Technical Events: Krisztina recounts a debate with a team that viewed events as "technical JSON" sent to messaging, ignoring the business importance required for a true Domain Event.

[00:02:00] The "Clean Code" Fallacy: The team's resistance stemmed from a belief that adding domain logic would "mess up" their clean repository—an argument that left the architect speechless.

[00:03:00] Tigers vs. Mice: Utilizing a quote from George Box, Krisztina explains her decision to prioritize the long-term learning opportunity over the immediate technical correctness of a single service.

[00:04:00] The Cost of Noise: The team's implementation resulted in 90% of their published messages being filtered out as noise by other teams, highlighting the waste of "easy" implementation.

[00:06:00] From Failure to Process: How the team owned their mistake, presented their learnings to the company, and helped establish a standardized LFC (RFC) process for defining future events.

[00:17:00] Asynchronous Domain Modeling: Reframing a long-term failure and recovery period as a necessary, extended modeling session that aligns the team with the architecture.

[00:15:00] The Goal isn't "Being Right": A heuristic for architects—if your primary goal is to prove you are right, you are likely wrong. The goal must be shared understanding and doability.

]]>In software architecture, there is often a difficult tension between enforcing best practices and allowing teams the autonomy to learn through experience. One of the most common pitfalls in Event-Driven Architecture is the confusion between meaningful Domain Events and mere technical noise. When a team insists on the "easy way," is it better for an architect to block them or let them proceed into a potential disaster?.

In this episode, we are joined by Krisztina Hirth, Staff Engineer at PayFit and a longtime Virtual DDD co-organizer. Krisztina shares a candid story about a high-throughput team that insisted on publishing technical JSON logs rather than proper domain events because they didn't want to "mess up" their clean repository. Rather than forcing her will in a one-hour meeting, Krisztina made the calculated decision to let the tigers roam: she allowed the team to fail so they could learn the lesson empirically.

This conversation dives deep into the patience required for true socio-technical change. We explore why "going fast is often just wrong" and how a failure that generated 90% useless noise eventually led to a robust RFC process and a company-wide understanding of Domain-Driven Design. As Krisztina puts it, sometimes what looks like a mistake is actually just an "asynchronous domain modeling session" that takes eight months to complete.

3. Key Discussion Points

[00:01:00] The Trap of Technical Events: Krisztina recounts a debate with a team that viewed events as "technical JSON" sent to messaging, ignoring the business importance required for a true Domain Event.

[00:02:00] The "Clean Code" Fallacy: The team's resistance stemmed from a belief that adding domain logic would "mess up" their clean repository—an argument that left the architect speechless.

[00:03:00] Tigers vs. Mice: Utilizing a quote from George Box, Krisztina explains her decision to prioritize the long-term learning opportunity over the immediate technical correctness of a single service.

[00:04:00] The Cost of Noise: The team's implementation resulted in 90% of their published messages being filtered out as noise by other teams, highlighting the waste of "easy" implementation.

[00:06:00] From Failure to Process: How the team owned their mistake, presented their learnings to the company, and helped establish a standardized LFC (RFC) process for defining future events.

[00:17:00] Asynchronous Domain Modeling: Reframing a long-term failure and recovery period as a necessary, extended modeling session that aligns the team with the architecture.

[00:15:00] The Goal isn't "Being Right": A heuristic for architects—if your primary goal is to prove you are right, you are likely wrong. The goal must be shared understanding and doability.

]]>b9001bb9-070a-4c03-89e4-faf221c37778Tue, 09 Dec 2025 07:30:00 +000022:24falsefull88The Architect's Dilemma: What to Do When You Disagree With a Team's DecisionThe Architect's Dilemma: What to Do When You Disagree With a Team's DecisionIn this episode of "Stories of Software Architecture and Design," hosts Kenny (Baas) Schwegler and Andrea Magnorsky welcome back guests Elena and Pete to discuss the challenges of managing team autonomy when an architect disagrees with a decision.

Pete, who discussed this topic at QCon, shares his perspective on dealing with decisions made by teams that he felt were incorrect.

Key Discussion Points

  1. Architect's Dilemma and Self-Reflection: Pete shared his challenge when teams made decisions he disagreed with, stressing the need for the architect to first reflect on whether their own feedback was persuasive and to remove emotional attachment from the outcome.
  2. Building Accountability and Skills: The discussion covered the difficulty when teams lack the "harder skills" for questioning , emphasizing that Architecture Principles are key for guidance, especially regarding cost , and that the architects' role is critical for supporting teams to build accountability and trust.
  3. Decisions Across Boundaries: The team tackled the issue of decisions affecting multiple teams (i.e., "context wars") , confirming that a key tool is the Context Map (from DDD) to promote autonomy and that dealing with this requires facilitating communication.
  4. Granularity of ADRs: A challenge was the differing frequency and size of Architecture Decision Records (ADRs) across teams. The consensus was to encourage teams to write ADRs, even small ones that don't need the formal advice forum , as long as they find their right flow and document impactful decisions.

]]>In this episode of "Stories of Software Architecture and Design," hosts Kenny (Baas) Schwegler and Andrea Magnorsky welcome back guests Elena and Pete to discuss the challenges of managing team autonomy when an architect disagrees with a decision.

Pete, who discussed this topic at QCon, shares his perspective on dealing with decisions made by teams that he felt were incorrect.

Key Discussion Points

  1. Architect's Dilemma and Self-Reflection: Pete shared his challenge when teams made decisions he disagreed with, stressing the need for the architect to first reflect on whether their own feedback was persuasive and to remove emotional attachment from the outcome.
  2. Building Accountability and Skills: The discussion covered the difficulty when teams lack the "harder skills" for questioning , emphasizing that Architecture Principles are key for guidance, especially regarding cost , and that the architects' role is critical for supporting teams to build accountability and trust.
  3. Decisions Across Boundaries: The team tackled the issue of decisions affecting multiple teams (i.e., "context wars") , confirming that a key tool is the Context Map (from DDD) to promote autonomy and that dealing with this requires facilitating communication.
  4. Granularity of ADRs: A challenge was the differing frequency and size of Architecture Decision Records (ADRs) across teams. The consensus was to encourage teams to write ADRs, even small ones that don't need the formal advice forum , as long as they find their right flow and document impactful decisions.

]]>c397619c-c430-460e-9e36-c36f4c632c3bTue, 25 Nov 2025 07:30:00 +000016:48falsefull77The Path to Team-Led Architecture: From Opinions to AdviceThe Path to Team-Led Architecture: From Opinions to AdviceWelcome to a new episode where we share stories from the field. For the first time, we're thrilled to welcome guests to the show!

This week, we're joined by Elena Stojmilova, Technical Lead at Open GI, and Peter Hunter, Technical Architect at Open GI, alongside our Hosts Andrea Magnorsky and Kenny (baas) Schwegler. Elena shares her personal journey and lessons learned from implementing a decentralised decision-making process within her team at Open GI, including the shift to autonomous teams and the introduction of Architectural Decision Records (ADRs).

Elena provides a candid look at the challenges and triumphs of moving from a software engineering focus to taking on full architectural decision-making authority.

Key Discussion Points

  1. Decentralised Decision-Making: The necessary move to create independent, autonomous teams and empower Technical Leads to make architectural decisions.
  2. The Mindset Shift: Moving from a coding focus to considering the broader impact of decisions, including cost and system-wide effects.
  3. The Power of Support: The crucial importance of technical and soft skills guidance when transitioning into a new leadership role.
  4. Architectural Decision Records (ADRs): The process introduced to formalise decisions, helping guide the team and ensuring accountability.
  5. Navigating the Advisory Forum: The challenge of managing many strong opinions initially, and the evolution toward receiving more constructive advice.
  6. Facilitating Advice: The techniques used to manage opinionated discussions, including asking questions to uncover the reasoning behind feedback.
  7. Cultural Change: How the process promoted a culture of knowledge sharing between teams and the need for architects to adapt their role from "broadcasting" to facilitating.

]]>Welcome to a new episode where we share stories from the field. For the first time, we're thrilled to welcome guests to the show!

This week, we're joined by Elena Stojmilova, Technical Lead at Open GI, and Peter Hunter, Technical Architect at Open GI, alongside our Hosts Andrea Magnorsky and Kenny (baas) Schwegler. Elena shares her personal journey and lessons learned from implementing a decentralised decision-making process within her team at Open GI, including the shift to autonomous teams and the introduction of Architectural Decision Records (ADRs).

Elena provides a candid look at the challenges and triumphs of moving from a software engineering focus to taking on full architectural decision-making authority.

Key Discussion Points

  1. Decentralised Decision-Making: The necessary move to create independent, autonomous teams and empower Technical Leads to make architectural decisions.
  2. The Mindset Shift: Moving from a coding focus to considering the broader impact of decisions, including cost and system-wide effects.
  3. The Power of Support: The crucial importance of technical and soft skills guidance when transitioning into a new leadership role.
  4. Architectural Decision Records (ADRs): The process introduced to formalise decisions, helping guide the team and ensuring accountability.
  5. Navigating the Advisory Forum: The challenge of managing many strong opinions initially, and the evolution toward receiving more constructive advice.
  6. Facilitating Advice: The techniques used to manage opinionated discussions, including asking questions to uncover the reasoning behind feedback.
  7. Cultural Change: How the process promoted a culture of knowledge sharing between teams and the need for architects to adapt their role from "broadcasting" to facilitating.

]]>ba3ab849-6602-4816-9e3b-68f502e5834dTue, 11 Nov 2025 06:45:00 +000022:33falsefull66Decision, Reversal, Frustration: Navigating Governance After an IncidentDecision, Reversal, Frustration: Navigating Governance After an IncidentThe episode explores the tension between necessary on-the-spot decision-making during a software incident and subsequent organizational governance. Andrea’s story sets the scene: a colleague makes a critical, correct decision under pressure, only to have a later, higher-level investigation reverse it without adequately addressing the systemic issue that caused the incident, leading to frustration and burnout. We then further discuss how organizations—whether centralized or decentralized—often struggle with decision paralysis and the human consequences of chronic underinvestment in long-term fixes. The conversation emphasizes that true decentralized architecture requires not only empowering individuals to act but also leadership allyship and robust, non-weaponized processes to support and record their actions.

The core of the governance solution lies in documenting decisions effectively and creating a culture of learning over blame. To avoid "decision paralysis" and preserve the historical context, the hosts advocate for recording critical choices using Architectural Decision Records (ADRs). A key principle is that these records should be immutable; any subsequent change must be documented as a new, superseding decision rather than reopening the original. Furthermore, decision-making health can be assessed both quantitatively (by measuring flow and reversal rates) and qualitatively, by including sense-making questions about team readiness and feelings toward the decision, drawing on insights from practitioners like Rebecca Wirfs-Brock. This approach transforms governance from a bureaucratic bottleneck into a feedback loop that highlights deeper systemic failures.

Key Takeaways for Architectural Governance

  1. Immutable Decisions: Decisions recorded in ADRs must be treated as read-only history. Reversals or changes should always be documented as new, superseding decisions to prevent "decision paralysis."
  2. Leadership Allyship: Managers should use their political capital to support and empower the team's expert decisions, acting as facilitators and advocates rather than simply taking over.
  3. Systemic Focus: Governance must move beyond validating individual actions to addressing the root causes of repeated incidents and failures to prevent team burnout.
  4. Decision Metrics: Measure the health of the decision-making process both quantitatively (number of decisions, time to decide, rate of reversals) and qualitatively (team's emotional readiness/frustration).

]]>The episode explores the tension between necessary on-the-spot decision-making during a software incident and subsequent organizational governance. Andrea’s story sets the scene: a colleague makes a critical, correct decision under pressure, only to have a later, higher-level investigation reverse it without adequately addressing the systemic issue that caused the incident, leading to frustration and burnout. We then further discuss how organizations—whether centralized or decentralized—often struggle with decision paralysis and the human consequences of chronic underinvestment in long-term fixes. The conversation emphasizes that true decentralized architecture requires not only empowering individuals to act but also leadership allyship and robust, non-weaponized processes to support and record their actions.

The core of the governance solution lies in documenting decisions effectively and creating a culture of learning over blame. To avoid "decision paralysis" and preserve the historical context, the hosts advocate for recording critical choices using Architectural Decision Records (ADRs). A key principle is that these records should be immutable; any subsequent change must be documented as a new, superseding decision rather than reopening the original. Furthermore, decision-making health can be assessed both quantitatively (by measuring flow and reversal rates) and qualitatively, by including sense-making questions about team readiness and feelings toward the decision, drawing on insights from practitioners like Rebecca Wirfs-Brock. This approach transforms governance from a bureaucratic bottleneck into a feedback loop that highlights deeper systemic failures.

Key Takeaways for Architectural Governance

  1. Immutable Decisions: Decisions recorded in ADRs must be treated as read-only history. Reversals or changes should always be documented as new, superseding decisions to prevent "decision paralysis."
  2. Leadership Allyship: Managers should use their political capital to support and empower the team's expert decisions, acting as facilitators and advocates rather than simply taking over.
  3. Systemic Focus: Governance must move beyond validating individual actions to addressing the root causes of repeated incidents and failures to prevent team burnout.
  4. Decision Metrics: Measure the health of the decision-making process both quantitatively (number of decisions, time to decide, rate of reversals) and qualitatively (team's emotional readiness/frustration).

]]>47be4840-e08e-42b6-8319-7936a9914daeTue, 28 Oct 2025 06:45:00 +000020:06falsefull55Navigating Architectural Indecision: What to do when teams stay silentNavigating Architectural Indecision: What to do when teams stay silentIn this episode Andrew Harmel-Law, Kenny (Baas) Schwegler, and Andrea Magnorsky discussed the difficulties of facilitating software architecture decisions, particularly when teams are hesitant to take responsibility. Kenny shared his experience at a growing company that needed to choose a new front-end framework (Vue or React) to scale from 8 to 115 developers. His goal was to empower the team to make a democratic decision, but they were mostly junior to mid-level developers who were uncomfortable with the accountability of a major choice.

Key Strategies for Facilitation

The discussion highlighted several methods for navigating this kind of indecision:

  1. Ask for consent: When the team felt too uncomfortable to decide, Kenny asked for their consent to make the decision himself. This approach still involved them in the process, and he ultimately chose React.
  2. Support the decision: After making the decision, Kenny asked the team what they needed to get on board with it. The developers requested training, which was then arranged. This practice, also known as "disagree and commit," ensures that even if people don't agree with a decision, they are given the necessary resources to follow through with it.
  3. Create a safe environment: People are often afraid to make decisions because of the potential for future negative consequences. Andrew pointed out that an architect can act as a "proxy" for the team, taking on the accountability to protect them.
  4. Understand Governance and Accountability: Andrea emphasized the importance of clarifying who is responsible for a decision. A good governance framework provides checks and balances to prevent bad decisions

]]>In this episode Andrew Harmel-Law, Kenny (Baas) Schwegler, and Andrea Magnorsky discussed the difficulties of facilitating software architecture decisions, particularly when teams are hesitant to take responsibility. Kenny shared his experience at a growing company that needed to choose a new front-end framework (Vue or React) to scale from 8 to 115 developers. His goal was to empower the team to make a democratic decision, but they were mostly junior to mid-level developers who were uncomfortable with the accountability of a major choice.

Key Strategies for Facilitation

The discussion highlighted several methods for navigating this kind of indecision:

  1. Ask for consent: When the team felt too uncomfortable to decide, Kenny asked for their consent to make the decision himself. This approach still involved them in the process, and he ultimately chose React.
  2. Support the decision: After making the decision, Kenny asked the team what they needed to get on board with it. The developers requested training, which was then arranged. This practice, also known as "disagree and commit," ensures that even if people don't agree with a decision, they are given the necessary resources to follow through with it.
  3. Create a safe environment: People are often afraid to make decisions because of the potential for future negative consequences. Andrew pointed out that an architect can act as a "proxy" for the team, taking on the accountability to protect them.
  4. Understand Governance and Accountability: Andrea emphasized the importance of clarifying who is responsible for a decision. A good governance framework provides checks and balances to prevent bad decisions

]]>a6cf2188-2539-4986-8975-a44af952981dTue, 14 Oct 2025 06:45:00 +000019:32falsefull44Uncovering the Ghost Decisions in Your ArchitectureUncovering the Ghost Decisions in Your ArchitectureIn this episode, Andrew Harmel-Law, joined by Andrea Magnorsky and Kenny (Baas) Schwegler, discusses "ghost decisions," which are fundamental architectural choices that are often undocumented, implicit, or even forgotten. These decisions can cast a long shadow, influencing everything from technology choices to team structures.

Key Takeaways

  1. Implicit Decisions: Andrew shares his experience with projects where he found that the most fundamental architectural decisions had already been made, often implicitly or as a result of legacy choices. These are often not explicitly architectural decisions, but rather things like the product being built or the team structure, which have a significant architectural impact.
  2. Reverse-Engineering ADRs: To address these "ghost decisions," one team Andrew worked with began reverse-engineering Architecture Decision Records (ADRs). They documented historical decisions, including the three different options they selected and the reasons why they were rejected at the time. This provided clarity on the original constraints and allowed the team to revisit decisions when the context had changed, such as a startup growing into a large scale-up.
  3. Documenting Disagreements: The episode also touches on the challenge of documenting the human factors behind decisions, such as conflicts and power imbalances. Andrew suggests using phrases like "
  4. adopted despite" or "rejected despite" in ADRs to acknowledge opposing viewpoints and ensure all perspectives are represented in the official documentation. This approach can help people feel acknowledged and provides valuable context for new team members.
  5. The "Telephone Game": Kenny highlights the dangers of relying on undocumented decisions, which can lead to a "telephone game" where information is distorted or lost as people join and leave the team. Without a clear record, it becomes difficult to understand why certain choices were made, making it harder to evolve the codebase.

]]>In this episode, Andrew Harmel-Law, joined by Andrea Magnorsky and Kenny (Baas) Schwegler, discusses "ghost decisions," which are fundamental architectural choices that are often undocumented, implicit, or even forgotten. These decisions can cast a long shadow, influencing everything from technology choices to team structures.

Key Takeaways

  1. Implicit Decisions: Andrew shares his experience with projects where he found that the most fundamental architectural decisions had already been made, often implicitly or as a result of legacy choices. These are often not explicitly architectural decisions, but rather things like the product being built or the team structure, which have a significant architectural impact.
  2. Reverse-Engineering ADRs: To address these "ghost decisions," one team Andrew worked with began reverse-engineering Architecture Decision Records (ADRs). They documented historical decisions, including the three different options they selected and the reasons why they were rejected at the time. This provided clarity on the original constraints and allowed the team to revisit decisions when the context had changed, such as a startup growing into a large scale-up.
  3. Documenting Disagreements: The episode also touches on the challenge of documenting the human factors behind decisions, such as conflicts and power imbalances. Andrew suggests using phrases like "
  4. adopted despite" or "rejected despite" in ADRs to acknowledge opposing viewpoints and ensure all perspectives are represented in the official documentation. This approach can help people feel acknowledged and provides valuable context for new team members.
  5. The "Telephone Game": Kenny highlights the dangers of relying on undocumented decisions, which can lead to a "telephone game" where information is distorted or lost as people join and leave the team. Without a clear record, it becomes difficult to understand why certain choices were made, making it harder to evolve the codebase.

]]>fc4b652d-b818-4669-af76-27577cd253d6Tue, 30 Sep 2025 06:45:00 +000019:03falsefull33