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. Oct 13

    Forty People Stood in a Room and Nobody Was Allowed to Speak

    We say we want teams to own their decisions. But what happens the moment you actually hand people the pen, and they discover how uncomfortable that is? Two weeks into a new role, Yves Hanoulle, who calls himself a “creative collaboration agent” rather than an agile coach, was working with a group of about forty people split into four colour-named sub-teams. Then an internal customer said any team could pick up a feature, except the yellow one. Yves stopped all work and ran a retro. The group quickly agreed on three teams instead of four, and spent a lot of energy blaming his boss and his absent predecessor for the original split. After lunch, Yves and his boss cleared every chair and table out of the biggest room in the building, and Yves explained the rules: “I would help you make decisions, but I would not make decisions for you.” Walk around in silence, form three circles, and stop moving when you’re happy. Twenty minutes in, the loudest critic of the original decision pointed at Yves and said: “You should decide.” Yves said no, and reminded him of his own words that morning. What followed was a day of dynamics nobody had spoken about: a cluster of French-speaking colleagues who wouldn’t move, two people who physically blocked a third from joining their circle, a colleague in tears who was then welcomed with open arms, and the two most senior people choosing to split up. They finished at four o’clock with not a line of code written, and Yves believes they delivered more that sprint than if they had carried on. This conversation explores what it means to decide how to decide without deciding the outcome. We dig into why people say “I hate this decision” when they really mean “I want someone to blame”, what removing speech makes visible, why a co-facilitator mattered, and the question Yves admits he never fully answered: what do you do with the truth a good exercise surfaces? Key Discussion Points [00:01] Anything But the Yellow Team: An internal customer rules out one team, and Yves stops work to run a retro where the blame lands on his boss and predecessor[04:00] Chairs Out, Mouths Closed: Booking the biggest room, clearing the furniture, and the rules for walking in silence into three circles[06:00] “You Should Decide”: The loudest critic asks Yves to make the call, and Yves hands the morning’s complaint straight back[08:00] Language, Mentoring and a Blocked Circle: A French-speaking cluster in a Dutch-speaking group, and two people closing ranks on a third[12:00] Refusing the Checklist: Why Yves wouldn’t let forty people agree team criteria up front, even though they hated him for it[14:00] Deciding That We Decide: Andrew on the narrow but real authority of choosing how a decision gets made[24:00] Making Space: The colleague in tears, a five-minute chat with the boss, and a circle that opened up[29:00] The Signal Nobody Followed Up: Andrea asks what Yves did with the block, and why a day like this leaves a facilitator exhausted Guest: Yves Hanoulle Hosts: Andrew Harmel-Law, Andrea Magnorsky, Kenny Schwegler

    Forty People Stood in a Room and Nobody Was Allowed to Speak

  2. Sep 29

    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

    Everyone Agreed on the Standard and Nobody Used It

  3. Sep 15

    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

    Nobody Asked Her to Organise a Community of Practice, So She Did It Anyway

  4. Sep 1

    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

    Someone Went on Holiday and Handed Over a Laptop Full of Scripts

  5. Aug 18

    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

    They Told Her She Needed Grey Hair to Run the Workshop

  6. Aug 4

    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

    The Team Had Four Services. They Were Actually One

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

  8. 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
See All (30)

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