Stories on Facilitating Software Architecture & Design

Virtual Domain-Driven Design

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

  1. We Spent Years Improving the Wrong Thing

    HÁ 4 H

    We Spent Years Improving the Wrong Thing

    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

    31 min
  2. Everyone Had an Opinion But Nobody Changed Their Mind

    12 DE MAI.

    Everyone Had an Opinion But Nobody Changed Their Mind

    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

    29 min
  3. Why Drawing the Same System Reveals Different Architectures

    28 DE ABR.

    Why Drawing the Same System Reveals Different Architectures

    We often assume that architects working on the same system share the same understanding of its structure. They're looking at the same code, attending the same meetings — surely they see the same thing. But what happens when you actually test that assumption? That's the challenge Aino Corry faced when she was brought into a large American company to help a team of architects understand their monolith before breaking it into microservices. When she asked for a full day, the response was skeptical: "A whole day? We're just gonna look at some diagrams." But Aino held firm. Drawing on work with Simon Brown, she gave the architects a deceptively simple task: draw the component diagram of the monolith from memory, without looking at the code. Then they put every diagram on the wall — and walked the line. The surprise was immediate. Architects who'd been working on the same system for years had fundamentally incompatible mental models of its core structure. Using the liberating structure 1-2-4-All, Aino turned that surprise into a conversation unlike any they'd had before — one where not knowing became acceptable, and the quiet voices finally had room to speak. This conversation explores how externalising individual mental models creates richer architectural discussions, why structured facilitation changes who gets heard, how to handle the vocal skeptic who thinks you've wasted their day, and the consultant's dilemma of never quite knowing if your workshop made a lasting difference — unless you happen to have a spy in the organisation you drink red wine with. Key Discussion Points [00:01] Setting the Stage: Aino explains how she came to facilitate architecture workshops even though she's no longer a practicing architect — and why the same facilitation dynamics apply regardless of domain[00:02] A Whole Day? Really?: The team's resistance to spending a full day on understanding before doing, and why Aino insisted on it[00:04] Draw What You Know: The deceptively simple exercise of drawing the monolith's component diagram from memory — without looking at the code[00:05] Walking the Wall: The moment architects discovered their mental models of the same system were fundamentally incompatible[00:08] You Can't Win Them All: How one vocal skeptic dismissed the day as a waste of time, while newer team members found it invaluable[00:12] The Champion Skeptic: Aino reflects on what she'd do differently now — using Linda Rising's pattern to redirect skepticism into constructive energy[00:16] The Consultant's Dilemma: How do you know if your workshop actually made a difference once you've left the building?[00:22] To Understand Everything Is to Forgive Everything: Why seeing each other's mental models changed judgment into curiosity Guest: Aino Corry Hosts: Kenny Schwegler, Andrea Magnorsky

    23 min
  4. When Method Wars Hide the Real Problem

    14 DE ABR.

    When Method Wars Hide the Real Problem

    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

    31 min
  5. When Fixing an Outage Means Staying Out of the Way

    31 DE MAR.

    When Fixing an Outage Means Staying Out of the Way

    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

    24 min
  6. When Explaining More Isn't the Answer

    17 DE MAR.

    When Explaining More Isn't the Answer

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

    29 min
  7. When the Loudest Voice in the Room Architects Your Future

    3 DE MAR.

    When the Loudest Voice in the Room Architects Your Future

    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 [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[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[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[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[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[09:00] Quit Sooner: Gien's hard-won advice—it's okay to leave bad environments, and finding one is not a personal failure[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[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

    22 min
  8. The Slow Clap That Killed the Workshop

    17 DE FEV.

    The Slow Clap That Killed the Workshop

    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 [00:01] Physical Reactions as Data: Evelyn explains why intense physical responses during facilitation are a signal to act, not to freeze[00:03] "A Wasted Day": How leadership's resistance to the session set the conditions for failure before it even began[00:05] Working Too Hard: The facilitator heuristic — when you're working harder than the group, something structural is blocking participation[00:06] The CTO's Rounds: Arms crossed, sarcastic comments, no questions — and how the whole group froze every time he walked in[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[00:11] Understanding, Not Excusing: Evelyn's one-on-one with the CTO — learning that his behaviour earned him compliments from peers[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[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

    23 min
Ver tudo (15)

Sobre

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

Informações