You're faced with conflicting ideas on system design. How do you navigate towards the best solution?

To navigate conflicting ideas in system design: - Clarify the Problem: Ensure everyone agrees on the problem and requirements. - Evaluate Trade-offs: Weigh each idea against factors like scalability, cost, and complexity. - Encourage Open Dialogue: Bring constructive discussion to uncover key insights. - Prototype if Needed: Use quick prototypes or experiments to test ideas. - Align with Business Goals: Choose the solution that best meets business objectives. - Document Decisions: Record the rationale for future reference. - Iterate if Necessary: Be open to refining the design as new information emerges.

Don't forget to consider where the input is coming from. Do certain stakeholders input hold more weight than others? For example, is the customer always right, or is there a chance they are asking for things they don't fully understand? Are there members providing input that have significantly more experience or knowledge than others? Should this be factored into consideration, or are all inputs considered equal? Perhaps they are all considered equal at first, but at some point, consideration should be given to the level of influence assigned to each input.

When faced with conflicting ideas on system design, gathering input from all stakeholders is crucial. It helps in understanding different perspectives, uncovering potential trade-offs, and identifying common goals. This collaborative approach ensures that all viewpoints are considered, which can lead to a more well-rounded and effective solution. To navigate towards the best solution, prioritize open communication, assess the feasibility of each idea, and focus on aligning the design with the project’s overall objectives. By synthesizing diverse inputs and fostering a constructive dialogue, you can make informed decisions that balance various needs and drive the project forward.

I like splitting requirements into functional and non-functional requirements: - Functional - what are the core use cases the system needs to deliver? What are the experiences we want to provide the users? - Non-functional - what are the performance, latency, scalability characteristics of the system? These will often dictate how we approach the design of the system as much as the functional requirements. For example: latency may require regionalization, availability may lead to consistency tradeoffs, durability will require replication, etc.

I second Gil's thought. Based on my experience, the most important thing is to identify whose consensus is important or can be a value add for whatever you are trying to solve and for other teams/ team members it can more like an FYI or raise if they see any major red flag. Once this culture is established in the team, chances of everyone feel valued of their opinions will increase where it matters most while others still not missing out as you are still sharing the information to everyone. At last, getting consensus from everyone all the time will not only slow the feature release that may impact business but also can reflect as a indecisive characteristic of your team/org/individual based on the role you are playing .

Why would a consensus be required for each idea? The way I see it, consensus can lead to indecision. Have an expert own decisions in their space. They should collect feedback from others but they make the call in the end.

In corporate or any business, going ahead with mutual consensus is expected is best strategy. Not all team start with agreement. But developing consensus on certain decisions requires good leadership. To start with both side of idea should be discussed with broad mind. Taking polls, demo, survey result, etc are some techniques to bring consensus.

Depending on the team makeup, consensus may be difficult to achieve at times. If this is the case, a leader will need to step up to make final decisions. Ensure that this leader is very capable and accomplished in the System you are designing. I see messages to the effect of leaders don't have to know everything, which is true, but you better be pretty skilled to be making final decisions when your team is having difficulties finding consensus.

This stage is essential. Users and other devs won't know what works and what doesn't without testing assumptions. Assumptions are necessary but there are always things that go wrong or aren't what you and your team believe to be true. Rough out the most questionable items to test first before committing to full blown development.