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

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

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