TechnologyScienceSocial SciencesBusinessManagement

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.

Play

Open in

24 episodes
fortnightly
Avg 26 min
English

Episodes 24

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.

#29
September 29 · 26 min
Everyone Agreed on the Standard and Nobody Used It
We tend to assume that if the people who will live with an architecture standard help create it, adoption takes care of itself. Invite the teams, let them design the process, give everyone a voice, and the standards will be theirs. Wouter Lagerweij tells the story of an organisation where that assumption did not hold. A large company grown through mergers and takeovers, where "no one can tell us what to do" had quietly turned into "no one is actually telling anyone what they're doing." The ask was sensible: standardisation and a common architecture, coming from the teams. Technical leads self-selected into the sessions, ADRs were written, debated and ratified, and everyone had an opinion. Half a year later, the standards were parked on a website and practically nobody was using them. Not even the teams whose own members had written them. The moment it became undeniable was a sprint planning session. On the backlog: a technical improvement implementing one of those standards. There was a document, example code, a production service already using it, and the author, a former teammate, explicitly offering to help. The team's answer: "Yeah, we don't know. We're gonna postpone it to the next board." This conversation, with Suzanne Lagerweij joining in, explores why doing all the right things still didn't produce the change. We dig into how a process built so that everyone has their say can end with nobody feeling they own the outcome, why consent is not consensus, why the technical lead is not always the person who moves a team, and why Wouter believes the missing ingredient was not more process but people whose only job is to keep the energy on one change until it lands. Key Discussion Points * [00:02] Standardisation From the Teams: A merged organisation where autonomy has become "nobody tells anyone anything" asks for a common architecture built by the teams themselves * [00:05] Parked on a Website: After half a year of ratifying ADRs, the standards sit unused, even by their authors, and the process gets seen as a "distributed ivory tower" * [00:07] "Postpone It to the Next Board": Documentation, example code, a production service and a willing author, and the team still defers the work * [00:08] Pulling Every Lever: Easier adoption, wider representation and explicit leadership permission fall flat, while defect-only sprints actually deliver * [00:13] Nobody Owned It: Not even the people in the room felt the standards were theirs, and Suzanne asks whether technical leads were the teams' informal leaders * [00:16] Too Much Room to Object: A process designed so everyone has their say, design by committee, and the difference between consent and consensus * [00:22] One Change, Real Slack: What Wouter would do differently, from landing a single standard to sending in people whose only job is to raise the energy * [00:24] More Emotional Than Cognitive: Connecting the "because" to what teams care about, and why a dashboard is not the change **Guests:** Wouter Lagerweij, Suzanne Lagerweij **Hosts:** Kenny Schwegler
- Transcript
#28
September 15 · 23 min· Video
Nobody Asked Her to Organise a Community of Practice, So She Did It Anyway
Most organisations have a community of practice that nobody actually wants to attend. It sits in the calendar every two weeks, a handful of people talk, and the rest stay silent. Suzanne Lagerweij has a simple explanation for why: people don't feel like they matter there. Why would anyone go the extra mile if they go unnoticed? Suzanne brings a background in psychology and social work, including working with troubled teenagers in group homes. She sees clear parallels with software teams: stubborn people you can't order around, where nothing moves until you understand what they need. At her current client, AI adoption consisted of exactly one thing: an Excel sheet where a few early adopters logged their experiments. There was no direction and no support, and nobody was listening. So Suzanne, brought in to coach a very difficult team, organised an internal AI conference that nobody had asked for. Management said yes, but mostly worried about the hours lost from the roadmap. About 100 people came to the first edition and 150 to the second. Alongside the conference she started a biweekly AI café: a demo, a conversation and a freshly baked cake. She refused to make it hybrid, because "if you want to have an actual community that works, people have to be together." Her own team went from being the problem team to being the department's AI frontrunners. Not everything moved, though. Management loved the energy, right up to the point where they realised they were part of the problem. Suzanne proposed a questionnaire to understand where developers were on the learning curve. It came back longer and mandatory, with everyone summoned to a meeting to fill it in. "Well, that's not how it works." This conversation explores what it takes to build a community people actually want to be part of. That means making invisible work visible to the people who can support it, and recognising people as individuals. It also means finding successors before you leave, and being honest about why you're doing it when it isn't your job. Wouter Lagerweij joins in to connect the mandatory survey to Goodhart's law, with token spend as the new lines of code. As Suzanne puts it: if you don't, then who does? Key Discussion Points [00:01] From Group Homes to Lifeless Chapters: Suzanne's background in social work, and why communities of practice become just another meeting when people feel unnoticed [03:45] The Spreadsheet Was the Strategy: AI adoption amounts to an Excel sheet of experiments, so Suzanne organises an internal conference nobody budgeted for [05:00] A Stage, Not a Finished Product: Convincing reluctant speakers that a session is a story, and bringing management in to see what's really happening [07:00] Cake, Demos, and No Hybrid: The biweekly AI café that turned a problem team into frontrunners, and why Suzanne insisted people be in the room [10:00] Management as Part of the Problem: Managers who liked the movement, but not what it revealed about them [13:30] If You Don't, Who Does?: Why communities collapse when the organiser leaves, and the effort of finding people to carry it forward [15:00] Making People Change Makers: Small steps, visible value, and Wouter on appreciation and recognition as the basics that make people feel important [19:00] The Mandatory Questionnaire: Measuring productivity versus understanding the learning curve, and why enforced participation breaks the instrument Guest: Suzanne Lagerweij (with Wouter Lagerweij) Host: Kenny Schwegler
- Transcript
#27
September 1 · 43 min· Video
Someone Went on Holiday and Handed Over a Laptop Full of Scripts
We spend a lot of design effort on how data gets into a system — the forms, the validation, the transactional database quietly recording everything in neat rows. We spend far less on how it comes back out. And when the person who needs a weekly report is a loss prevention officer rather than a software engineer, "just use the API" turns out to be no answer at all. In this episode, Andrea Magnorsky and Kenny Schwegler are joined by Kat Hempstalk, a data and AI professional who has been doing machine learning "since before it was cool." She brings what she calls "a bit of a tragic tale" from her time as head of data and AI at a company handling retail crime reports. Before she arrived, the company had solved the export problem by hiring a graduate to write Python and SQL scripts and email spreadsheets to customers by hand. It worked — until that person went on holiday and literally handed their laptop to a colleague so the reports could keep going out. An engineer eventually received that laptop, thought "this is a bit scary," and added a little automation: a Windows VM, scripts synced through GitHub, scheduled tasks, files dropped into blob storage. The manual button-pressing stopped. The underlying problem just got faster to reproduce. Within a few years, three or four people spent their days copy-pasting scripts into 200 bespoke customer reports — reports that turned out to be five or six shapes wearing different hats. Collapsing them was the easy part. Telling customers their format was about to change, when the customer success team said "No, I'm out — I don't wanna give the customer bad news," was not. This conversation is about where data engineering and software engineering stop talking to each other, and what leaks through the gap. We dig into invisible contracts (a column heading is an API), why the order you migrate customers in is an architectural decision that cost this team a year, what embedding data people into software teams actually requires, and Kat's discovery that most of the customers fighting to keep their scheduled email had never once opened it. Key Discussion Points [00:01] A Bit of a Tragic Tale: Kat introduces the retail crime platform — reports go in easily, and getting them back out was never designed [00:03] Your Users Know Excel, Not APIs: Why loss prevention experts don't want a programmatic endpoint, they want a spreadsheet [00:05] The Laptop Handover: The graduate goes on holiday and passes the laptop along so the reports keep flowing [00:06] "A Bit of Automation" Becomes Load-Bearing: A Windows VM and scheduled tasks make the problem faster to reproduce, not smaller [00:07] Three People Copy-Pasting Scripts: 200 custom reports, an unhappy analyst team, and customers waiting months to add a column [00:11] The Query That Came Back Too Fast: Moving to a data warehouse, and the insights analyst who assumed the speed meant they'd made a mistake [00:13] Two Hundred Reports That Were Really Five: Consolidating into templates — and why that's a conversation problem, not a technical one [00:19] The Emails Nobody Opened: Customers insisting on scheduled reports they'd never clicked, because they wanted reassurance, not data [00:24] "No, I'm Out": Customer success refuses to deliver bad news, so the data team has to own the conversation [00:26] The Order You Migrate People In: Starting with friendly customers built momentum, but the resistant ones set the pace for everyone [00:29] A Column Heading Is a Contract: Customer-defined attributes reordering spreadsheets, and moving to nested JSON so nothing downstream breaks [00:34] Clear Fences Make Good Neighbours: Andrea on the boundary between data and software teams, and Kat on embedding people across it [00:39] What Goes With the Person, What Stays: The handover conversation they skipped, and the systems that broke silently as a result [00:42] Collaboration in the Agentic Era: Why the people best at sharing context and contracts are also the people getting the most out of coding agents Guest: Kat Hempstalk Hosts: Andrea Magnorsky, Kenny Schwegler
- Transcript
#26
August 18 · 35 min
They Told Her She Needed Grey Hair to Run the Workshop
Most facilitation advice starts the moment people walk into the room. Prepare your flip charts. Sort the chairs into some reasonable configuration. But Katie Clark brought two stories that are deliberately not about what happens during a workshop — they're about everything that happens before it, and around it, and especially what happens when there's more than one facilitator in the mix, with wildly different experience levels and organisational standing. In the first story, Katie is fresh out of university on a massive enterprise R&D transformation, increasingly frustrated that nobody understands the data in a very old, very enterprise-y system. She spends far too long with an enterprise architect staring at database schema wallpapers. Her suggestion — "Can we just ask the people working on this today?" — gets two unexpected responses. Her stream lead physically walks her to the next building, introduces her to the people she's about to invite, asks whether they're willing to spend the time, and only then sends the invitation. And she gets told: this is a good idea, but you need someone with more grey hair to help facilitate, to make sure you're taken seriously. Katie, who had a hairdresser appointment coming up, offered to solve the problem herself. Years later — still no grey hair — Katie is in a leadership role, formally accountable for a project spinning a new subdomain out into its own service. This time the workshop belongs firmly to the team. She isn't running it, she has to ask permission to attend, and she's only allowed to join ninety minutes in. So all her influence happens beforehand: coffee chats, one-on-ones, iterating the agenda with subgroups, working out what a realistic goal before lunch actually looks like. When she finally slips into a corner chair, she reaches for a marker, asks which arrows point where, slides sticky notes towards the loudest person in the room, and deploys the line that becomes the afternoon's running joke: "Oh my gosh, that's such a great point. It might even deserve to be on a sticky note." This conversation is about the invisible half of facilitation — the pre-work Andrew calls "rolling the pitch." We get into ageism cutting in both directions, why Katie now asks for a co-facilitator even when she doesn't need one, delegating chunks of facilitation to participants (chief Elmo officer, anyone?), using the IKEA effect on your own agenda, and why lunch is the most underrated boundary in workshop design. Key Discussion Points [00:01] Zigzagging Between Business and Tech: Katie on refusing to be put in a Venn diagram, and why she didn't hide her soft skills well enough [00:03] Consent Before the Calendar Invite: Walking to the next building to meet participants in person before anything gets scheduled [00:04] "You Need Someone With More Grey Hair": Being told to borrow credibility at 25, and the hairdresser appointment that almost solved it [00:07] Not My Workshop: Leading from a corner chair when you're accountable for the project but the workshop belongs to the team [00:11] "It Might Even Deserve to Be on a Sticky Note": How a sarcastic aside turned into the group's own documentation discipline [00:15] Facilitation Tandems: Asking for a co-facilitator even when you don't need one, and why it's pair programming for workshops [00:20] Chief Elmo Officer: Delegating time-boxing, topic discipline and documentation to participants in a high-stakes session [00:22] Rolling the Pitch: Andrew names the pre-work — the coffees, the agenda iterations, the expectation management that stops one person wanting three hours of chat and another wanting fifteen ADRs [00:24] The IKEA Effect on Your Agenda: Using a bias deliberately, and being happy to call it whatever wording people are comfortable with [00:31] What Do We Want Before Lunch: Lunch as a natural boundary, and why the last sixty minutes of a seven-hour workshop won't save you Guest: Katie Clark Hosts: Andrew Harmel-Law, Kenny Schwegler, Andrea Magnorsky
- Transcript
#25
August 4 · 26 min· Video
The Team Had Four Services. They Were Actually One
We tend to trust diagrams. Four boxes, four arrows, four services — that feels like shared understanding. But when Vanessa Formicola started asking basic questions about a team's architecture, the boxes came apart in her hands. What the team called four services turned out to be four deployments of one codebase — the same code with different entry points, barely modularised, with the services quietly intercommunicating underneath the API calls that made them look separate. And this was a medical product. The team owned everything from the app entry point down to the core business algorithms, critical IP scattered across a system nobody could change safely. Vanessa describes herself as an engineering leader and a sociotechnical architect, which she explains like this: if you bring her a technical problem, she'll start poking around in your people issues, and vice versa. That instinct is the whole story here. The team wasn't incompetent — they were clever people in a high-growth environment that never gave them space to stop and ask what they actually owned. So rather than opening with a redesign proposal, Vanessa ran a series of workshops as the person in the room who didn't know anything. They mapped business capabilities, technical capabilities, and what she calls "real estate" — the stuff you own that has nothing to do with your domain. In parallel, she took ADRs into the company's weekly architecture forum. Only then did they draw a North Star. A year and a half of decoupling followed. Issue time halved. Sprint predictability improved by about 40%. But the outcome Vanessa values most isn't in those numbers, and neither is her most portable idea: the Social Decision Record. Same format as an ADR, but for organisational decisions — whose test strategy do we adopt, how do we share PR reviews, who lands which developer. In this team, there were more SDRs than ADRs. This conversation explores what that ratio tells us about architecture work, why "just tell me what to do" is a signal about the environment rather than the person, and how career frameworks and quarterly review cycles end up designing your architecture without anyone noticing. Key Discussion Points [00:01] Poking Around in Your People Issues: Vanessa on why no problem gets solved by looking only at technical architecture or only at organisational dynamics [02:00] Four Deployments, One Codebase: The discovery underneath the diagram — same code, different entry points, API calls that misled everyone [04:00] Capabilities, and the Real Estate You Didn't Ask For: Domain analysis that separates what you own, what you should own, and what you're just carrying [06:00] Bringing ADRs to the Forum: Shifting how decisions were communicated to the teams that depended on this one [07:00] If We Were Designing This Now: The North Star conversation, and separating the stable medical domain from feature-driven, BFF-style services [12:00] "Just Tell Me What to Do": Why this is disillusionment or fear rather than laziness — an organisational issue, not an architectural one [15:00] Twenty Lines, Not Twenty Pages: The RFC that would take three months, and why ADRs let people engage at the depth they want [22:00] Social Decision Records: Applying ADR rigour to organisational decisions — and why this team ended up with more SDRs than ADRs Guest: Vanessa Formicola Hosts: Andrea Magnorsky, Kenny Schwegler
- Transcript
#24
July 21 · 26 min· Video
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
- Transcript
#23
July 7 · 25 min· Video
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
- Transcript
#22
June 23 · 26 min· Video
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
- Transcript
#21
June 9 · 23 min· Video
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
- Transcript
#20
May 26 · 30 min· Video
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
- Transcript
#19
May 12 · 28 min· Video
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
- Transcript
#18
April 28 · 22 min· Video
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
- Transcript
#17
April 14 · 31 min
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
- Transcript
#16
March 31 · 24 min
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
- Transcript
#15
March 17 · 29 min· Video
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.
- Transcript
#14
March 3 · 21 min· Video
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
- Transcript
#13
February 17 · 23 min
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
- Transcript
#12
February 3 · 36 min· Video
When Everyone Agrees But Nobody Acts
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.*
- Transcript
#11
January 20 · 23 min· Video
Misaligned Expectations: When Goals Don't Align
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 [00:01] The Legacy Trap: Setting the stage for a workshop to replace a 20-year-old system facing end-of-life support. [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. [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. [08:00] Emotional Safety in Modeling: Understanding why experts cling to complex legacy numbers as a form of job security and identity. [13:00] The Facilitator’s Dilemma: Navigating the tension of facilitation when you cannot refer to an aligned goal because one doesn't exist. [16:00] Delivering the "Ground Truth": The consultant's responsibility to present uncomfortable findings to leadership to drive organizational alignment. [19:00] Aligning on Intent: How to prepare mentally to ensure you are solving the right problem for the business success. Resources Mentioned 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
- Transcript
#10
January 6 · 24 min· Video
Modernizing with Respect: Acknowledging the Best Intentions Behind Legacy Code
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 [00:02:50] Conference Driven Development: The danger of throwing buzzwords like Microservices, DDD, and Kubernetes at a problem without understanding the context. [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. [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." [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. [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. [00:25:00] Riding the Elevator: Why stakeholder communication—translating technical complexity for different audiences—is the number one skill for aspiring architects.
- Transcript

Showing 1–20 of 24 episodes