Skip to main content

Software Design Review: How to Disagree Correctly

Software design reviews are a cornerstone of building quality software. They're where we catch potential problems before they become costly bugs, performance bottlenecks, or architectural nightmares. But what happens when you fundamentally disagree with feedback offered during a review? Disagreement isn’t a sign of a bad review or a weak engineer; it’s a natural part of a healthy, intellectually honest process. The how you navigate that disagreement, however, is crucial. After 15+ years in this field, I’ve seen enough reviews (and disagreements!) to know that disagreeing correctly is a vital skill for every engineering leader and team member.

This isn't about winning an argument. It’s about ensuring the best possible outcome for the project and fostering a culture of constructive criticism. Let’s break down how to navigate these situations with grace and effectiveness.

Why Disagreement Happens (and That’s Okay)​

Before diving into how to disagree, let’s acknowledge why it happens. Here are a few common scenarios:

  • Different Perspectives: Reviewers and owners often come from different areas of the system (frontend, backend, security, etc.). This naturally leads to varying priorities and interpretations.
  • Missing Context: Sometimes a reviewer doesn’t have the full picture. They might be unaware of constraints, tradeoffs already considered, or future plans.
  • Valid Alternative Solutions: Engineering is rarely about the right answer. Often, multiple solutions can achieve the same outcome, and a difference of opinion reflects a legitimate design choice.
  • Strong Opinions (and That’s Okay Too): Experienced engineers should have strong opinions, backed by experience. Those opinions will inevitably clash sometimes.

The key is to recognize that disagreement isn't inherently negative. It's an opportunity to explore options, challenge assumptions, and ultimately arrive at a better solution. Research consistently demonstrates that teams which embrace diverse perspectives and constructive conflict are more innovative and build higher quality products.

The "Listen-Clarify-Debate" Framework​

I've seen too many design reviews devolve into rushed decisions because the critical "Listen-Clarify-Debate" phase gets skipped. We jump straight to 'decision making', failing to engage in meaningful discussion, which misses the entire point. Here’s how to approach it:

  1. Listen Actively: This sounds simple, but it’s often the hardest part. Truly hear the reviewer’s concerns. Resist the urge to formulate a rebuttal while they're still talking. Take notes. Ask clarifying questions to show you're engaged.

  2. Clarify, Don't Challenge (Yet): Before you respond, ensure you fully understand the reviewer’s reasoning. Ask open-ended questions like:

    • "Could you elaborate on why you see that as a potential issue?"
    • "What specific scenario are you concerned about?"
    • "What alternative approach were you envisioning?" This demonstrates respect and uncovers potential misunderstandings. Often, clarification reveals that you actually agree on the underlying problem, even if you disagree on the solution.

  3. Debate Respectfully & Objectively: Now you can present your counterarguments. Frame your response in terms of tradeoffs, constraints, and potential consequences. Avoid language that sounds defensive or dismissive.

    • Focus on the Design, Not the Person: Instead of saying, "I disagree with your approach," say, "I'm concerned that approach might introduce X problem because of Y constraint."
    • Back Up Your Claims with Evidence: Explain your reasoning. Share data, examples, or relevant context.
    • Be Open to Being Wrong: The most valuable debates are those where both sides are willing to consider alternative perspectives.

Resolving Impasses: Documentation and Escalation​

Sometimes, despite your best efforts, you and the reviewer remain at odds. Here's how to handle it:

  • Escalate Strategically: If the disagreement is significant and impacts a critical design decision, involve a neutral third party – a senior engineer, architect, or tech lead – to help mediate. Don't escalate over minor points.
  • Document the Decision & Rationale: Regardless of who 'wins' the debate, clearly document the final decision and the reasoning behind it. This provides valuable context for future developers and avoids revisiting the same arguments. A simple bullet point in the design document can be incredibly helpful.

It’s also important to consider that junior engineers may feel less comfortable expressing dissenting opinions. As a leader, create a safe space for them to share their perspectives and actively solicit their input.

What if You Still Disagree? Follow-Up and Team Cohesion​

Sometimes a follow-up conversation can be helpful. If the review was particularly heated, or if you feel you didn't adequately explain your perspective, a one-on-one conversation can help clarify things. However, be mindful of the following:

  • Don't Re-litigate the Entire Debate: The goal isn’t to change their mind, but to ensure mutual understanding and maintain a positive working relationship.
  • Focus on Understanding Their Perspective: Ask them if anything you said in the review was unclear or if they have further concerns.

It’s crucial to remember that even if you disagree with a final decision, it's important to commit to supporting it and working together to make it successful. Undermining a decision after it’s been made can damage team morale and hinder progress.

Embrace the Discomfort: Growth Through Disagreement​

Ultimately, healthy disagreement is a sign of a strong engineering culture. It demonstrates that people are engaged, thinking critically, and willing to challenge assumptions. Embrace the discomfort, view disagreements as opportunities for growth, and focus on the shared goal of building the best possible software.