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

    We Spent Three Months Talking and Got Nowhere Until Someone Picked Up a Marker

    Most decisions in software teams don't fail because people disagreed. They fail because people thought they agreed — and nobody found out for weeks. You leave the meeting feeling good about where things landed, and three weeks later you're having the same conversation, wondering how you got back to the start. Michael Joyce, a technical principal at Thoughtworks, joined Andrea and Andrew with a story from an unusual vantage point: he worked as a solution architect inside a New Zealand agriculture company, left for the UK, and then went back to the same company four years later. Long enough that his designs were still running, and nobody knew he'd made them. He got both barrels — "I don't know why it does this," which he could answer by pulling up a design document nobody had ever seen, and, from the ops team, the first long-term praise of his career: when things fell over, the services just restarted and recovered. The systems survived. The reasoning behind them didn't. The turning point in the conversation is a whiteboard. Michael was locked in a circular argument with a vendor architect, both of them making points to win rather than to resolve. He stopped, walked to the board, and wrote down what the other person had just said. The vendor architect looked at it and said: "That's wrong." Not embarrassed — genuinely surprised that what he'd said out loud meant something different once it was visible. They stopped arguing at each other and started looking at the same thing. Michael's clients have hit the same effect at scale: three months of talking about a decision, then one day in a workshop run by someone with no knowledge of the subject, and it was done. "That's what alignment is. It's not about having a conversation. It's about externalising it." The subtler trap he names is the one that shows up when things feel like they're going well: valuing harmony over precision. Agreement is a nice feeling, so you stop writing, stop clarifying — and what got documented was one person's version of the agreement. This conversation explores externalisation as a facilitation move rather than a paperwork exercise, why precision is usually plain language rather than intricacy, why saying what something doesn't do matters as much as what it does, and why an IKEA wardrobe explains most broken professional relationships. Key Discussion Points [01:00] Becoming an Architect by Accident: From giving opinions in London to holding the title in New Zealand, and finding the word itself a little strange[02:00] Something at Stake: Defending designs against vendors when your colleagues, not your next client, have to live with the result[04:00] Going Back to Face Your Own Designs: Four years later, the systems are still running and nobody knows they're yours — "I've never seen that design before, so we just went and implemented it"[05:00] Design the Project, Not Just the System: Why the biggest lever an architect has is team interaction, learning, and how the work starts[09:00] A True Partnership: The product manager who presented P&L to the board, visited customers, and took support calls — and the product folks who didn't want developers near customers[13:00] Intent and Radical Empathy: The one thing Michael kept from Crucial Conversations, and the difference between "I don't understand the decision" and "I don't agree with it"[17:00] "That's Wrong": The whiteboard moment that ended a circular argument with a vendor architect — and changed the relationship[18:00] Three Months vs. One Day: Why alignment isn't conversation, it's externalisation[20:00] Valuing Harmony Over Precision: How the nice feeling of agreement stops you documenting, and leaves you in disagreement without knowing it[22:00] Positive and Negative Boundaries: Saying what a service will do — and what it will not — because the grey areas are where understandings quietly diverge[25:00] The IKEA Wardrobe: They supply the materials and the handbook. They don't come to your house and build it Guest: Michael Joyce Hosts: Andrea Magnorsky, Andrew Harmel-Law

    We Spent Three Months Talking and Got Nowhere Until Someone Picked Up a Marker

  2. Jul 7

    She Spent Years Watching Architects Lose Their Spark

    There is a version of career progression that looks like success from the outside and feels like erosion from the inside: you get more senior, you sit in more meetings, you write less software, and eventually someone asks whether you'd like to become an architect. Most people in that position have already watched what happens to the ones who said yes. Larisa Feldman joined Andrew, Andrea, and Kenny to tell a story that doesn't begin with a design problem — it begins with a decision she kept refusing to make. Over 18 years at National Australia Bank, she worked alongside integration, solution, domain, and enterprise architects, and she noticed a pattern: "they start very happy and they become quite sad." Their clear, well-reasoned visions kept getting stripped back by a mainframe that couldn't cope, an old system that wouldn't integrate, priorities that never arrived. As a senior and then principal engineer, Larisa was the one explaining how the systems actually worked before any design conversation could start — using a floppy disk as her analogy for why mobile isn't a website deployment. But she never wanted the title. As she put it, the sadness in the architects' eyes protected her. What eventually changed her mind wasn't ambition. After leaving financial services for REA Group — no change panels, no product/tech split, everything straight to production — she was offered an architecture role on a modernisation programme. The pull was specific: "an opportunity to actually do something the way I wanted it to, rather than do it as another architect suggests." She became an architect almost by accident, but not without reason — and now measures the role by a single test: is the architecture making engineers' lives better, or harder? This conversation explores what the architect role actually is and who it's actually for. We dig into Gregor Hohpe's "do we want architects or do we want architecture?", the case for advisor roles over architect titles, Kenny's analogy of decisions made by someone from a distant village with authority but no context, and why writing things down turns out to be an architectural act in its own right. Key Discussion Points [00:01] The Reluctant Architect: Larisa frames a story that isn't about designing a system, but about years of deliberately refusing the role[02:00] From Steel Plants to Software: an electro-mechanical degree in a collapsing Soviet economy and an accidental route into writing code[05:00] "Let Me Tell You How Mobile Works": translating system constraints to architects who arrived without context — and the floppy-disk analogy that stuck[08:00] The Sadness That Protected Her: why the bank's architects started happy and ended demoralised, and why that kept Larisa saying no[10:00] Architects or Architecture?: Kenny raises Gregor Hohpe's distinction; Larisa on why an architect who still wants to code is probably in the right job[13:00] Advisor, Not Architect: the slightly controversial idea that some senior engineers contribute more from an advisory seat than from a room full of stakeholders[19:00] Self-Fulfilling Roles and the Next Village: roles that stop enabling teams and start justifying themselves — authority without context[22:00] Learning Not to Be Blunt: influence across stakeholder levels, writing to crystallise what only she knew, and architecture as the glue between engineers and leadership Guest: Larisa Feldman Hosts: Andrew Harmel-Law, Kenny Schwegler, Andrea Magnorsky

    She Spent Years Watching Architects Lose Their Spark

  3. Jun 23

    Nobody Could Agree on Whether the Problem Was Technical a DDD Europe Special

    There's a pattern that turns up in almost every struggling team: the problem gets named as technical, the technical fix gets applied, and nothing improves. The complaints come back louder, and the only thing that really changes is who gets blamed next. We recorded this one differently. At DDD Europe, Andrea, Kenny, and Andrew spent the conference wandering the halls with a single question for attendees and speakers alike: what's the hardest part of facilitating software architecture and design? Nine people answered — Matthias Verraes, Zsófia Herendi, Stefan Hofer, Samantha Dellaert, Eric Evans, Henning Schwentner, Hadi Ahmadi, Alexandra Junghans, and Susanne Kaiser — and their answers sorted themselves into three groups: one about how organisations are wired, one about who's actually in the room, and one about the facilitator's own state of mind. Almost none of them was really about software. Matthias mapped a "broken" core team and found the failure was economic, not technical — and surfaced it by inventing notation on the fly ("one red dot means I don't like working on this; three means I'd rather quit"). Eric Evans argued that fun is a diagnostic, not a perk. Henning Schwentner reminded us that without the right people you don't have collaboration, just modelling. Susanne Kaiser showed why the real negotiation is often with leadership, in a different language entirely. This episode is a tour of the gap between technique and reality — the power structures, the missing domain experts, the curiosity you can't manufacture, and the question that outlasts every workshop: what needs to change for the insights to actually go anywhere? Key Discussion Points [00:00] One Question, Nine Answers: The premise — roaming DDD Europe to ask what's genuinely hardest about facilitation[01:00] Matthias Verraes — The Problem Was Economic, Not Technical: A blamed core team, country profit centres, and externalised costs[04:00] "Put the Ugh on the Map": Improvised red-dot notation to make frustration, churn, and CEO access visible[07:00] Zsófia Herendi — You Can't Manufacture Curiosity: Leading by example when the room just sits and stares[09:00] Stefan Hofer — From Writing Code to Building Things: The mindset shift behind stepping into rooms full of people and sticky notes[11:00] Samantha Dellaert — Making the Bigger Picture Visible: Starting with a model of the whole so people can locate themselves in it[13:00] Eric Evans — Fun as a Diagnostic: Why enjoyment is information about whether the work is going well, not just a nice-to-have[19:00] Henning Schwentner — Get the Right People: Without real domain knowledge, it's modelling, not collaboration[22:00] Hadi Ahmadi — The Sociopolitical Layer: Why power structures cause the most issues, and studying outside engineering[24:00] Alexandra Junghans — Just Start: Teaching facilitation from the ground up; there's nothing to lose[25:00] Susanne Kaiser — Speaking Leadership's Language: Reframing three days of modelling as investment, not cost Guests: Matthias Verraes, Zsófia Herendi, Stefan Hofer, Samantha Dellaert, Eric Evans, Henning Schwentner, Hadi Ahmadi, Alexandra Junghans, Susanne Kaiser Hosts: Andrea Magnorsky, Andrew Harmel-Law, Kenny Schwegler

    Nobody Could Agree on Whether the Problem Was Technical a DDD Europe Special

  4. Jun 9

    They Knew the Answer Before They Understood the Problem

    We like to think architecture starts with a problem. But often, by the time we're brought in, someone has already chosen the answer — and the real work becomes figuring out how to slow things down without making anyone feel foolish. That's the situation Kim Kao, a solutions architect manager at AWS in Taiwan, walked into. A retail client — battered by the pandemic, competitors circling — had already been told by another vendor exactly what to do: containerise everything, deploy Kubernetes, and the operational problems would disappear. "Don't laugh," Kim recalls. The system underneath that confident prescription was twenty years old, and nobody left in the building fully understood how it worked. "Nobody knows what the content is." Rather than argue about Kubernetes, Kim worked backwards. He ran impact mapping with decision-makers and functional leads, asking a deceptively simple question — who would support a goal of growing month-on-month revenue? — and watched the room fall silent. Then a two-day event storming workshop with forty to fifty people, many sitting together for the first time, surfaced merchant management as the place to actually begin. Somewhere in the middle of it, Kim had a realisation: "I found I was a businessman, not a technical guy." This conversation explores what it takes to redirect a client who arrives with the answer already in hand — and why understanding the problem first is so often the faster route to solving it. Key Discussion Points [00:04] The Answer Was Already Chosen: A retail GM, hit by the pandemic, arrives with a vendor's verdict — Kubernetes will fix everything[00:06] A System Nobody Understands: Twenty years of accumulated decisions, and "nobody knows what the content is"[00:09] Don't Decorate the Weakness: Why building on an unmapped system was "quite dangerous," and how merchant management emerged as the right starting point[00:11] Compared to What?: Making the true cost of Kubernetes visible — a million-plus active members, hours-long promotions, six-month hardware lead times[00:14] The Question Behind the Question: Separating the symptom from the cause before committing to any solution[00:16] The Silence in the Room: Running impact mapping, setting a revenue goal, and asking "who's your supporter?" to a team used only to taking orders[00:19] A Businessman, Not a Technical Guy: How connecting marketing, inventory, and logistics reframed Kim's sense of his own role[00:20] The Conjunction Role: Sending clients to DDD Taiwan and letting them discover the value of collaborative modelling for themselves Guest: Kim Kao Hosts: Andrea Magnorsky, Andrew Harmel-Law, Kenny Schwegler

    They Knew the Answer Before They Understood the Problem

  5. May 26

    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

    We Spent Years Improving the Wrong Thing

  6. May 12

    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

    Everyone Had an Opinion But Nobody Changed Their Mind

  7. Apr 28

    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

    Why Drawing the Same System Reveals Different Architectures

  8. Apr 14

    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

    When Method Wars Hide the Real Problem
See All (15)

About

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.

Information

You Might Also Like