In this episode, Andrew Harmel-Law, joined by Andrea Magnorsky and Kenny (Baas) Schwegler, discusses "ghost decisions," which are fundamental architectural choices that are often undocumented, implicit, or even forgotten. These decisions can cast a long shadow, influencing everything from technology choices to team structures.

• Implicit Decisions: Andrew shares his experience with projects where he found that the most fundamental architectural decisions had already been made, often implicitly or as a result of legacy choices. These are often not explicitly architectural decisions, but rather things like the product being built or the team structure, which have a significant architectural impact.
• Reverse-Engineering ADRs: To address these "ghost decisions," one team Andrew worked with began reverse-engineering Architecture Decision Records (ADRs). They documented historical decisions, including the three different options they selected and the reasons why they were rejected at the time. This provided clarity on the original constraints and allowed the team to revisit decisions when the context had changed, such as a startup growing into a large scale-up.
• Documenting Disagreements: The episode also touches on the challenge of documenting the human factors behind decisions, such as conflicts and power imbalances. Andrew suggests using phrases like "
• adopted despite" or "rejected despite" in ADRs to acknowledge opposing viewpoints and ensure all perspectives are represented in the official documentation. This approach can help people feel acknowledged and provides valuable context for new team members.
• The "Telephone Game": Kenny highlights the dangers of relying on undocumented decisions, which can lead to a "telephone game" where information is distorted or lost as people join and leave the team. Without a clear record, it becomes difficult to understand why certain choices were made, making it harder to evolve the codebase.

In this episode, Kenny and Andrea discuss how to move from a blocking, "ivory tower" or hands-on architect role to a more facilitating one. They explore the importance of transparency as a first step in improving an organisation's approach to software architecture and design. The goal is to shift decision-making to the people who have the most information—the ones actually writing the software.

• Transparency is Key: It’s a great way to start improving things in any organisation. Documenting the decision-making process helps everyone understand why confident choices were made.
• The Problem with After-the-Fact Decisions: Writing down decisions only after they've been made is like writing unit tests after the code is finished. It’s more effective to document the process as it happens.
• Start Small with ADRs: Begin by writing Architectural Decision Records (ADRs) as a team or even with just one other person. You can start with a simple question like, "Should we use ADRs?".

Benefits of ADRs:

• Shared Mental Model: ADRs provide a clear, shared understanding of what was said and decided, reducing confusion and "hallway conversations".
• More Focused Meetings: Reviewing ADRs ensures everyone is on the same page, leading to more productive and less repetitive meetings.
• Explicit Decisions: ADRs make it clear who is responsible for a decision and its potential side effects.

Find a partner and begin writing ADRs for tough decisions in your project. Do it out in the open so others can see the benefits of the practice. This small, disciplined start can encourage others to follow suit, leading to broader adoption across the organisation.

In this episode, Kenny and Andrea dive deep into some really interesting problems we're seeing in software architecture & design right now. You know, how some people are still working in those "ivory towers," or even the "hands-on" folks are running into issues? We're trying to figure out some different ways to build better systems.