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.

1. [00:01] The Legacy Trap: Setting the stage for a workshop to replace a 20-year-old system facing end-of-life support.
2. [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.
3. [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.
4. [08:00] Emotional Safety in Modeling: Understanding why experts cling to complex legacy numbers as a form of job security and identity.
5. [13:00] The Facilitator’s Dilemma: Navigating the tension of facilitation when you cannot refer to an aligned goal because one doesn't exist.
6. [16:00] Delivering the "Ground Truth": The consultant's responsibility to present uncomfortable findings to leadership to drive organizational alignment.
7. [19:00] Aligning on Intent: How to prepare mentally to ensure you are solving the right problem for the business success.

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

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.

1. [00:02:50] Conference Driven Development: The danger of throwing buzzwords like Microservices, DDD, and Kubernetes at a problem without understanding the context.
2. [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.
3. [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."
4. [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.
5. [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.
6. [00:25:00] Riding the Elevator: Why stakeholder communication—translating technical complexity for different audiences—is the number one skill for aspiring architects.

In this episode of Stories on Facilitating Software Design and Architecture, we are joined by Paul Rayner, a seasoned consultant and expert in Domain-Driven Design and EventStorming. Paul shares a candid "war story" from his time as a tech lead that completely changed how he views leadership and influence. He recounts a well-intentioned refactoring session where he publicly critiqued a team member's code, aiming to teach better practices. The result was unexpected and severe: the developer felt shamed by the experience and quit shortly after.

This experience served as a harsh wake-up call about the "unseen authority" leaders wield and how easily the "blast radius" of our actions can damage team psychological safety, even when our motives are pure. Paul opens up about the "dominant blindness" that often affects technical leaders—where we fail to see how our rank amplifies our words, turning a simple suggestion into a crushing directive.

We dive deep into the power dynamics of technical leadership, exploring why simply having the "right" technical solution isn't enough. The conversation covers how to move from "fixing" people's work to facilitating their growth, why resistance should be treated as a valuable resource rather than an obstacle, and how methods like EventStorming can help externalize conflict.

Key Learning Points:

1. The Gap Between Intent and Impact: Why "I meant well" is never a sufficient excuse when a team member feels alienated or embarrassed by your actions.
2. Dominant Blindness: How leaders often underestimate the heavy weight of their rank and the pressure it puts on colleagues, especially when navigating contractor-employee dynamics.
3. Resistance is a Resource: Instead of pushing harder against pushback, view it as a signal to understand the underlying fears, threats, or misunderstandings driving the resistance.
4. Challenging Mental Models: Recognizing that when you criticize code, you are often challenging the deep-seated mental models and hard work of the person who wrote it.
5. Externalizing the Problem: How using visual tools like sticky notes (e.g., in EventStorming) can shift the focus from "me vs. you" to a collaborative discussion about the problem on the wall.

In software architecture, there is often a difficult tension between enforcing best practices and allowing teams the autonomy to learn through experience. One of the most common pitfalls in Event-Driven Architecture is the confusion between meaningful Domain Events and mere technical noise. When a team insists on the "easy way," is it better for an architect to block them or let them proceed into a potential disaster?.

In this episode, we are joined by Krisztina Hirth, Staff Engineer at PayFit and a longtime Virtual DDD co-organizer. Krisztina shares a candid story about a high-throughput team that insisted on publishing technical JSON logs rather than proper domain events because they didn't want to "mess up" their clean repository. Rather than forcing her will in a one-hour meeting, Krisztina made the calculated decision to let the tigers roam: she allowed the team to fail so they could learn the lesson empirically.

This conversation dives deep into the patience required for true socio-technical change. We explore why "going fast is often just wrong" and how a failure that generated 90% useless noise eventually led to a robust RFC process and a company-wide understanding of Domain-Driven Design. As Krisztina puts it, sometimes what looks like a mistake is actually just an "asynchronous domain modeling session" that takes eight months to complete.

3. Key Discussion Points

[00:01:00] The Trap of Technical Events: Krisztina recounts a debate with a team that viewed events as "technical JSON" sent to messaging, ignoring the business importance required for a true Domain Event.

[00:02:00] The "Clean Code" Fallacy: The team's resistance stemmed from a belief that adding domain logic would "mess up" their clean repository—an argument that left the architect speechless.

[00:03:00] Tigers vs. Mice: Utilizing a quote from George Box, Krisztina explains her decision to prioritize the long-term learning opportunity over the immediate technical correctness of a single service.

[00:04:00] The Cost of Noise: The team's implementation resulted in 90% of their published messages being filtered out as noise by other teams, highlighting the waste of "easy" implementation.

[00:06:00] From Failure to Process: How the team owned their mistake, presented their learnings to the company, and helped establish a standardized LFC (RFC) process for defining future events.

[00:17:00] Asynchronous Domain Modeling: Reframing a long-term failure and recovery period as a necessary, extended modeling session that aligns the team with the architecture.

[00:15:00] The Goal isn't "Being Right": A heuristic for architects—if your primary goal is to prove you are right, you are likely wrong. The goal must be shared understanding and doability.

In this episode of "Stories of Software Architecture and Design," hosts Kenny (Baas) Schwegler and Andrea Magnorsky welcome back guests Elena and Pete to discuss the challenges of managing team autonomy when an architect disagrees with a decision.

Pete, who discussed this topic at QCon, shares his perspective on dealing with decisions made by teams that he felt were incorrect.

1. Architect's Dilemma and Self-Reflection: Pete shared his challenge when teams made decisions he disagreed with, stressing the need for the architect to first reflect on whether their own feedback was persuasive and to remove emotional attachment from the outcome.
2. Building Accountability and Skills: The discussion covered the difficulty when teams lack the "harder skills" for questioning , emphasizing that Architecture Principles are key for guidance, especially regarding cost , and that the architects' role is critical for supporting teams to build accountability and trust.
3. Decisions Across Boundaries: The team tackled the issue of decisions affecting multiple teams (i.e., "context wars") , confirming that a key tool is the Context Map (from DDD) to promote autonomy and that dealing with this requires facilitating communication.
4. Granularity of ADRs: A challenge was the differing frequency and size of Architecture Decision Records (ADRs) across teams. The consensus was to encourage teams to write ADRs, even small ones that don't need the formal advice forum , as long as they find their right flow and document impactful decisions.

Welcome to a new episode where we share stories from the field. For the first time, we're thrilled to welcome guests to the show!

This week, we're joined by Elena Stojmilova, Technical Lead at Open GI, and Peter Hunter, Technical Architect at Open GI, alongside our Hosts Andrea Magnorsky and Kenny (baas) Schwegler. Elena shares her personal journey and lessons learned from implementing a decentralised decision-making process within her team at Open GI, including the shift to autonomous teams and the introduction of Architectural Decision Records (ADRs).

Elena provides a candid look at the challenges and triumphs of moving from a software engineering focus to taking on full architectural decision-making authority.

1. Decentralised Decision-Making: The necessary move to create independent, autonomous teams and empower Technical Leads to make architectural decisions.
2. The Mindset Shift: Moving from a coding focus to considering the broader impact of decisions, including cost and system-wide effects.
3. The Power of Support: The crucial importance of technical and soft skills guidance when transitioning into a new leadership role.
4. Architectural Decision Records (ADRs): The process introduced to formalise decisions, helping guide the team and ensuring accountability.
5. Navigating the Advisory Forum: The challenge of managing many strong opinions initially, and the evolution toward receiving more constructive advice.
6. Facilitating Advice: The techniques used to manage opinionated discussions, including asking questions to uncover the reasoning behind feedback.
7. Cultural Change: How the process promoted a culture of knowledge sharing between teams and the need for architects to adapt their role from "broadcasting" to facilitating.

The episode explores the tension between necessary on-the-spot decision-making during a software incident and subsequent organizational governance. Andrea’s story sets the scene: a colleague makes a critical, correct decision under pressure, only to have a later, higher-level investigation reverse it without adequately addressing the systemic issue that caused the incident, leading to frustration and burnout. We then further discuss how organizations—whether centralized or decentralized—often struggle with decision paralysis and the human consequences of chronic underinvestment in long-term fixes. The conversation emphasizes that true decentralized architecture requires not only empowering individuals to act but also leadership allyship and robust, non-weaponized processes to support and record their actions.

The core of the governance solution lies in documenting decisions effectively and creating a culture of learning over blame. To avoid "decision paralysis" and preserve the historical context, the hosts advocate for recording critical choices using Architectural Decision Records (ADRs). A key principle is that these records should be immutable; any subsequent change must be documented as a new, superseding decision rather than reopening the original. Furthermore, decision-making health can be assessed both quantitatively (by measuring flow and reversal rates) and qualitatively, by including sense-making questions about team readiness and feelings toward the decision, drawing on insights from practitioners like Rebecca Wirfs-Brock. This approach transforms governance from a bureaucratic bottleneck into a feedback loop that highlights deeper systemic failures.

1. Immutable Decisions: Decisions recorded in ADRs must be treated as read-only history. Reversals or changes should always be documented as new, superseding decisions to prevent "decision paralysis."
2. Leadership Allyship: Managers should use their political capital to support and empower the team's expert decisions, acting as facilitators and advocates rather than simply taking over.
3. Systemic Focus: Governance must move beyond validating individual actions to addressing the root causes of repeated incidents and failures to prevent team burnout.
4. Decision Metrics: Measure the health of the decision-making process both quantitatively (number of decisions, time to decide, rate of reversals) and qualitatively (team's emotional readiness/frustration).

In this episode Andrew Harmel-Law, Kenny (Baas) Schwegler, and Andrea Magnorsky discussed the difficulties of facilitating software architecture decisions, particularly when teams are hesitant to take responsibility. Kenny shared his experience at a growing company that needed to choose a new front-end framework (Vue or React) to scale from 8 to 115 developers. His goal was to empower the team to make a democratic decision, but they were mostly junior to mid-level developers who were uncomfortable with the accountability of a major choice.

The discussion highlighted several methods for navigating this kind of indecision:

1. Ask for consent: When the team felt too uncomfortable to decide, Kenny asked for their consent to make the decision himself. This approach still involved them in the process, and he ultimately chose React.
2. Support the decision: After making the decision, Kenny asked the team what they needed to get on board with it. The developers requested training, which was then arranged. This practice, also known as "disagree and commit," ensures that even if people don't agree with a decision, they are given the necessary resources to follow through with it.
3. Create a safe environment: People are often afraid to make decisions because of the potential for future negative consequences. Andrew pointed out that an architect can act as a "proxy" for the team, taking on the accountability to protect them.
4. Understand Governance and Accountability: Andrea emphasized the importance of clarifying who is responsible for a decision. A good governance framework provides checks and balances to prevent bad decisions