I don’t hold on to anything, don’t reject anything; nowhere an obstacle or conflict.

Layman Pang

How to make architecture decisions

• ⚖️ Embrace Trade-offs — Architectural decisions are rarely about finding a “perfect” solution, but rather understanding and choosing the best set of compromises — or the “least bad” option — for your specific context and priorities. As the author notes, “Every decision has a downside.”
• 📝 Structured Approach is Key — Effective decision-making involves a deliberate process: clearly defining the problem you’re trying to solve, exploring multiple viable options (aim for at least three), and evaluating them against well-defined criteria, principles, and non-functional requirements.
• 📜 Document Your “Why” — Utilize Architecture Decision Records (ADRs) to capture not just what was decided, but critically, why it was decided, including the alternatives considered and the rationale for the chosen path. This provides invaluable context for the future and helps avoid “repeating past mistakes.”
• 🧠 Acknowledge Biases & Seek Input — Be aware of personal and team biases (like familiarity, “shiny object syndrome,” or sunk cost fallacy) and actively seek diverse perspectives to challenge assumptions. While consensus isn't always the goal, collaborative input leads to more robust decisions.
• 🔄 Decisions are Reversible (Sometimes) — Understand the “reversibility” of a decision. Some choices are easily undone (two-way doors), while others are very costly to change (one-way doors). This should factor into the rigor of the decision-making process.

Stop Team Topologies

Finally, a critical view (well, not so much)!

• 🛑 Critique of Rigid Application — The author argues that Team Topologies are often applied too prescriptively — like a “dogmatic blueprint” — rather than as a flexible set of patterns, leading to suboptimal outcomes.
• 🌊 Focus on Flow and Principles — Instead of strictly adhering to the four team types, the emphasis should be on core principles like optimizing for flow, Conway’s Law, and managing cognitive load — using Team Topologies as a “lens” rather than a rigid classification system.
• 🗣️ Potential for Silos — A dogmatic implementation can inadvertently create new communication overhead and artificial boundaries between teams, hindering collaboration and the “actual path of value delivery” rather than improving it.
• 🧩 Misunderstanding and Oversimplification — The article suggests that the nuances of concepts like “Enabling teams” or “Complicated Subsystem teams” can be lost, leading to misapplication where these become bottlenecks or just abstract labels without solving underlying issues.
• 🤔 Context is King — The piece advocates for a more contextual approach, adapting organizational design to specific needs and problems, rather than forcing an organization to fit into the Team Topologies framework as if it were a “silver bullet.”

Strategy & Decisiveness

• 🧠 Strategy as a Decision Filter
  • A well-defined strategy acts as a crucial filter — simplifying complex choices by providing clear criteria for what to say “yes” or “no” to.
  • It helps to avoid getting bogged down in options — by focusing attention on what truly matters for long-term goals.
• 💡 Decisiveness is More Than Speed
  • True decisiveness isn't just about making decisions quickly — it's about making good quality decisions efficiently, which a solid strategy enables.
  • The article differentiates between thoughtful, strategy-backed decisiveness and mere “performative decisiveness” — or acting quickly without sufficient grounding.
• ⏳ The Hidden Cost of Indecision
  • Often, the cost of indecision — such as missed opportunities, market irrelevance, or team paralysis — can be far greater than the risk of making a slightly imperfect but timely decision.
  • A “wait and see” approach can be detrimental — especially in fast-moving environments.
• 🚪 Understanding Decision Reversibility
  • A key theme is the importance of categorizing decisions as either “one-way doors” (consequential, hard to reverse) or “two-way doors” (easily reversible).
  • This distinction allows for different approaches — more deliberation for “one-way doors” and quicker, iterative action for “two-way doors”.
• 🚀 Bias for Action, Guided by Strategy
  • Strategy should empower a bias for action — especially for reversible decisions, rather than aiming for perfect information which can lead to “analysis paralysis”.
  • The goal is to have enough information to make a strategically sound decision — not all possible information.
• 🎯 Strategy Fuels Confident Action
  • A clear strategy provides the necessary conviction and framework — allowing leaders and teams to act decisively even when faced with uncertainty.
  • It’s not about eliminating all risk — but about understanding it and moving forward with a clear “North Star”.

Organizations are distributed systems

• 🌐 Organizations as Networks
  • The article posits that organizations fundamentally operate like distributed systems — consisting of interconnected nodes (individuals, teams) that communicate and coordinate.
  • This analogy helps to understand inherent complexities — such as communication overhead and potential points of failure.
• ⏳ Latency and Bandwidth in Communication
  • Information flow within an organization experiences latency (delays) and has bandwidth limitations — just like network traffic.
  • Misunderstandings and delays are natural byproducts — much like packet loss or network congestion.
• 🔗 Conway's Law as a System Architecture Principle
  • A key observation is the relevance of Conway's Law — “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.”
  • This means the organizational structure directly impacts — and often dictates — the architecture of the products or systems it builds.
• 🔄 Consistency Challenges (Shared Understanding)
  • Achieving a consistent view or shared understanding across an organization (like data consistency in distributed databases) is a significant challenge.
  • Different teams or individuals may have outdated or conflicting information — leading to inefficiencies or errors.
• 🚦 Coordination and Synchronization Overheads
  • Just as distributed systems require mechanisms for coordination and synchronization (e.g., locks, consensus algorithms) — organizations need processes and structures for alignment.
  • Meetings, planning sessions, and reporting structures are organizational equivalents — and they come with their own overhead.
• 🚧 Fault Tolerance and Resilience
  • The article implies that organizations, like distributed systems, need to be designed for fault tolerance — people leaving, teams being reorganized, or miscommunications occurring are inevitable “failures”.
  • Resilient organizations can adapt and continue functioning — despite these disruptions.
• 🧩 Modularity and Bounded Contexts
  • The idea of breaking down complex problems into smaller, manageable, and loosely coupled parts (like microservices or domain-driven design's bounded contexts) is crucial for organizational scalability and agility.
  • This reduces cognitive load and communication complexity — by defining clear interfaces and responsibilities.

Principal Engineer Roles Framework

• 🌟 Defining Principal Engineer (PE) Impact
  • The article emphasizes that Principal Engineers are defined by their impact and influence — rather than just deep technical expertise in isolation.
  • Their role transcends individual contribution — focusing on significantly elevating the technical capabilities and outcomes of larger groups or the entire organization.
• 🧭 Strategic Technical Leadership
  • PEs are expected to provide strategic technical direction — identifying and championing long-term technical visions, often looking 2-5 years ahead.
  • This involves anticipating future challenges and opportunities — and guiding the organization to prepare for them.
• 🗺️ The "Framework" – Pillars of Expectation
  • The article (implicitly or explicitly, depending on its exact structure which I'm recalling from common PE frameworks) likely outlines key pillars for PEs such as:
    • Technical Depth & Breadth: Mastering complex areas and understanding broader systems.
    • Execution & Delivery: Driving complex projects to completion, often by orchestrating others.
    • Mentorship & Guidance: Growing other engineers and elevating the team's technical bar.
    • Communication & Influence: Articulating complex ideas clearly and influencing diverse stakeholders.
    • Ambiguity & Problem Solving: Thriving in uncertain situations and tackling the hardest problems.
• 🤝 Cross-Functional Influence and Collaboration
  • A significant aspect of the PE role is the ability to influence and collaborate effectively across teams, departments, and sometimes even with external partners.
  • They act as technical ambassadors and connectors — bridging gaps and aligning technical efforts.
• 🌱 Mentorship and Force Multiplication
  • Principal Engineers are "force multipliers" — their work enables many other engineers to be more effective and productive.
  • Mentoring senior engineers and setting technical standards are key ways they achieve this leverage.
• 💡 Navigating Ambiguity and Driving Innovation
  • PEs are often tasked with the most ambiguous and challenging technical problems — those without clear solutions.
  • They are expected to drive innovation — by exploring new technologies, methodologies, and approaches to solve critical business problems.
• 🗣️ Exceptional Communication Skills
  • The ability to communicate complex technical concepts to both technical and non-technical audiences is paramount.
  • This includes writing clear documentation, delivering compelling presentations, and leading effective technical discussions.

That’s all for this week’s edition

I hope you liked it, and you’ve learned something — if you did, don’t forget to give a thumbs-up, add your thoughts as comments, and share this issue with your friends and network.

See you all next week 👋