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.

• Decentralised Decision-Making: The necessary move to create independent, autonomous teams and empower Technical Leads to make architectural decisions.
• The Mindset Shift: Moving from a coding focus to considering the broader impact of decisions, including cost and system-wide effects.
• The Power of Support: The crucial importance of technical and soft skills guidance when transitioning into a new leadership role.
• Architectural Decision Records (ADRs): The process introduced to formalise decisions, helping guide the team and ensuring accountability.
• Navigating the Advisory Forum: The challenge of managing many strong opinions initially, and the evolution toward receiving more constructive advice.
• Facilitating Advice: The techniques used to manage opinionated discussions, including asking questions to uncover the reasoning behind feedback.
• 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.

• 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."
• 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.
• Systemic Focus: Governance must move beyond validating individual actions to addressing the root causes of repeated incidents and failures to prevent team burnout.
• 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:

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