We hit resistance in our architecture work, and what do we do? We explain more. We create another diagram, write another document, schedule another meeting to walk through the rationale. After twenty years of this pattern, Diana Montalion realized she was pushing the same rock up the sames hills—and it kept rolling back down and flattening her.
Diana shared this challenge with us in this installment of Stories on Facilitating Software Architecture and Design. It's a story about discovering that the instinct to explain more often makes things worse, and that designing experiences instead of explanations can create the architectural breakthroughs that months of talking never will.
The Realization at Kripalu
Diana found herself at a retreat center, taking a break from the exhaustion of constant explanation. The environment was predominantly female—the exact opposite of the tech spaces where she'd spent 25 years, often as the only woman in the room. More striking was how learning happened there: experientially, through movement and practice, not through endless discussion.
"In my day job, in my system science and software architect life, we don't have bodies really. We just talk to each other," she noticed. The contrast was sharp.
Then her phone pinged. The organizer of Domain-Driven Design Europe was asking about the workshop she'd proposed. The timing felt like the universe nudging her: what would she actually do differently?
Modeling the Patriarchy to Learn Systems Thinking
Diana and her training partner Matt Wynne designed a workshop around the iceberg model—a systems thinking tool that looks beneath surface events to the structures, patterns, and mental models that generate them. But they didn't frame it abstractly.
They asked participants to model a system that produces a specific outcome: 91.88% of software developers being male. Not to debate gender equality or bring their existing frames about it, but to actually work through how a system generates that result. Then they flipped it: design a system where you can't tell if someone's a software engineer just by looking at them.
"People come up with all kinds of things that I never even thought of before," Diana said. She's run the workshop four or five times now, learning something new each time. People engage because they're having an experience, thinking together about how something works. Not being told what to think.
Kenny mentioned he took the iceberg model back to his company and saw patterns emerge just by working through it. The format itself teaches.
The Miracle of Trying It
In her current role, Diana caught herself falling into the old pattern. Resistance to architectural change? Explain more. Make another model. Say more words. She recognized it this time and shifted.
"Let's just try it. Let's do this. Let's just try it."
The results surprised even her. People who were very resistant to particular changes had an experience of working with them, thought it through for themselves, and suddenly picked up the ball and ran with it. "That doesn't have to happen," she acknowledged, "but it's a win if people have the experience and then say, this isn't gonna work, Diana, and here are the reasons why."
Being wrong early—before you've spent significant time, energy, and money—is the goal. The experience surfaces whether the direction works much faster than explanation ever could.
Working Inside Uncertainty
Both Kenny and Andrea pressed on the uncertainty inherent in this approach. How do you deal with not knowing exactly what will happen in a workshop? How do you handle organizations that want guaranteed deliverables?
Diana's perspective: "There is only uncertainty. Everything else is delusion we're telling ourselves."
She's not interested in philosophical debates about this. Instead, she focuses on what the organization most wants—areas where they've already acknowledged complexity and uncertainty. She doesn't promise to solve problems. She promises to deliver important insight.
"When there isn't friction, when you can facilitate, you discover that facilitative leadership is way harder than just telling people what to do because you are uncertain too. You are experimenting too. You are vulnerable right along with them."
This requires consent. You can't trick people into experiential learning. If an organization demands complete certainty about workshop outcomes, Diana's honest: she doesn't know if she can work effectively in that environment. You need at least a little willingness to step into the unknown together.
Interrupting Patterns
Andrea picked up on something subtle in Diana's approach: she's not just facilitating people to articulate what they already think. She's listening for where thinking will go down the same familiar path—even when it seems like new thinking—and gently interrupting that pattern.
"Working with teams going from a CRUD monolith to asynchronous microservices is very challenging because our thinking is very tightly coupled. So when we build the microservices, we architect them to be tightly coupled."
The facilitator's role includes recognizing these cognitive patterns and creating space for different questions. But this requires a delicate balance. You need to understand enough about the direction to ask useful questions, but if you're just steering people to your predetermined answer, you might as well skip the facilitation and tell them what to do.
"It's a little bit like a flock of birds where you have to be grounded enough in the space to be flying with the flock while you're facilitating. If you're trying to marshal it, it won't work. If you're trying to control it, it won't work. But also if you turn off your brain and just flow with it, you're not actually adding the tension where it should go."
Unpacking the Dynamics
- The explanation trap scales with experience: Twenty years in, Diana was still defaulting to "explain more" when facing resistance. Seniority doesn't automatically break this pattern—you have to recognize it and consciously choose differently.
- Facilitation requires consent: You cannot trick people into experiential learning. If there's no willingness to step into uncertainty, facilitative approaches won't work. This means choosing your battles and focusing on areas where there's already acknowledgement of complexity.
- Experiences teach what explanations cannot: The iceberg model workshop taught systems thinking not through lecture but through the act of modeling. People discovered insights themselves rather than being told them. This sticks in ways explanation never does.
- Being wrong early is the goal: When people try something and discover it won't work—with clear reasons why—that's success. You learn before spending significant resources, and the team builds shared understanding of what doesn't work.
- Cognitive patterns shape architecture: Teams moving from monoliths to microservices often build tightly coupled microservices because their thinking remains tightly coupled. The facilitator's job includes spotting where familiar thought patterns will recreate familiar problems, even in apparently new contexts.
- Harder than command and control: When friction disappears, the real difficulty of facilitative leadership emerges. You're uncertain too. You're experimenting too. You're vulnerable alongside the people you're working with. This is genuinely more difficult than just telling people what to do.
The Science and the Art
Diana's closing thought brings together the listening, the pattern recognition, and the vulnerability: facilitation is both a science and an art. It's both deep listening and also "an energetic interruption of pattern in some way that is helpful."
When you catch yourself wanting to explain more, that might be the signal to design an experience instead. Not because experiences are always better, but because if explaining more hasn't worked yet, it probably won't work with another iteration. The breakthrough you're looking for might require actually trying something, together, and discovering what you learn.
Further Reading
- Book: Learning System Thinking: Essential Non-Linear Skills and Practices for Software Professionals (Diana Montalion), Learning Systems Thinking shows you how systems thinking can guide you through the complexity of modern systems. Through a series of practices and real-world scenarios, you'll learn to shift your perspective in order to design, develop, and deliver better outcomes.
- Book: The Corporate Tribe (Daniel Szuc, Yvonne Dittrich, et al.), The Corporate Tribe – Explores creating experiential "magic" in organizations via anthropological approaches, echoing Diana's shaman-like facilitation for wisdom in uncertain knowledge work[Transcript reference].
