Benjamin Cane
Portrait of Benjamin Cane
Benjamin Cane
November 11, 2026
architecture
Two colleagues discussing a diagram on a chalkboard wall
Photo by Vitaly Gariev on Unsplash

The hardest part of being a decision-maker is looking at a problem objectively.

Everyone has biases, and the closer you are to a problem, the harder it can be to recognize your own.

When you’re responsible for making architectural or technical decisions, part of your job is recognizing those biases and challenging them.

Sometimes that means stepping back and looking at the problem from a different perspective. You might discover that the solution you’ve been advocating isn’t actually the best one.

Over the years, I’ve found a few techniques that help me look at problems more objectively.

1. Assume Positive Intent

Often, when making a technical decision, you’ll have two or more sides championing different solutions to the same problem.

People have various motivations, but I’ve found it beneficial to assume positive intent. It makes it easier to put yourself in their shoes and see the problem from their perspective.

Maybe they have a certain capability and a strategy for it that conflicts with your proposal. Maybe they see constraints or requirements that you don’t see from your perspective.

Understanding why someone holds an opinion helps you determine whether their perspective has merit and what you may need to explain or solve for.

Understanding someone’s motivations doesn’t mean agreeing with their position. It means understanding the context that led them there.

2. Find the Flaws in Your Preferred Solution

If you have a proposal in the mix, a great way to look at it objectively is to dig into its flaws deliberately.

Every solution has trade-offs. Taking the time to identify the downsides of your preferred approach helps you challenge your assumptions.

This step works even if you’re not proposing a solution and are purely mediating a decision.

When you look at different options, you will usually gravitate toward one or two. Spend extra time finding the flaws in those solutions.

You may find that your initial bias caused you to overlook important aspects of the problem.

3. Find the Best Argument for the Alternatives

Just like you spent time thinking about the benefits of your preferred solution, spend extra time thinking about the positives of the alternatives.

But don’t just identify a few benefits. Challenge yourself to explain why another solution might actually be the better choice.

  • What requirements does it satisfy better?
  • What constraints does it handle more effectively?
  • What tradeoffs might make it preferable to your original proposal?

Forcing yourself to make a strong argument for the alternative can reveal assumptions you haven’t challenged.

And sometimes, you might discover that the alternative really is the better solution.

4. Recognize That Multiple Solutions Can Work

Often, when I see teams strongly debating a technical decision, it’s because both teams have a solution that works.

The conversation becomes less about whether the solutions work and more about which one is optimal. These can be difficult decisions because either approach could technically work.

But naturally, you want to choose the best one; as engineers, we're wired to optimize.

When you find yourself in this situation, revisit the requirements.

  • What problems are we actually trying to solve?
  • What constraints do we need to account for?
  • What might we need from this solution in the future?

Sometimes, after going through this exercise, you’ll find one option is clearly better.

Other times, you’ll find that both solutions meet the requirements and the differences aren’t significant enough to justify continued debate.

A viable solution isn’t necessarily the optimal solution. But finding the optimal solution isn’t always worth the cost of continued debate.

5. Run Through What-If Scenarios

One way to evaluate how a solution might hold up in the future is to run through what-if scenarios.

  • What if traffic increases tenfold?
  • What if a dependency becomes unavailable?
  • What if we need to support another region?
  • What if the requirements change?

By creating realistic scenarios and evaluating each option against them, you can often discover which solution provides a better foundation for the future.

But keep those scenarios realistic.

You can always invent a hypothetical situation that makes a particular solution look better or worse.

The goal isn’t to design for every possible future.

It’s to understand how each option handles the scenarios that are likely to matter.

6. Write It All Down

One of the most effective ways I’ve found to look at a problem objectively is to write everything down. Write down the problem, capture the requirements and the constraints, and explain them in a way that anyone reviewing the decision can understand.

Then document the different solutions.

  • What makes each option good?
  • What are the downsides?
  • How did they perform against your what-if scenarios?
  • What assumptions are you making?

Sometimes the simple act of writing everything down gives you a new perspective. You may discover gaps in your reasoning, assumptions you haven’t validated, or trade-offs you hadn’t fully considered.

Writing down your reasoning doesn’t just help others understand the decision. It helps you challenge your own thinking.

Final Thoughts

Making technical decisions is hard, especially when multiple viable solutions and strong opinions come from every side.

If you’re the decision-maker, take the time to explain your reasoning. Not everyone will agree with the outcome, but understanding how you reached your conclusion makes it easier for others to accept the decision.

And if you’re participating in the decision, recognize that sometimes the outcome won’t be your preferred solution.

That doesn’t necessarily mean it’s the wrong one. If the solution meets the requirements and the differences come down to preferences or acceptable tradeoffs, sometimes the right thing to do is disagree, commit, and move on.

The goal isn’t to prove your solution is right. It’s to make the best decision for the problem you’re trying to solve.

Discuss on LinkedIn Newsletter Back to all posts

More to Read

  • November 4, 2026 Microservices can work for low-latency workloads—if you design for it performance
  • October 28, 2026 Production bugs happen. Fix the gap, not just the bug. engineering
  • October 21, 2026 A timeout doesn’t mean an operation failed. It means you don’t know the outcome. reliability
  • October 14, 2026 Sometimes the biggest contributor to latency isn’t processing or network time. It’s waiting for work to start. performance
  • October 7, 2026 System Design pro-tip: force yourself to create a viable second design. architecture

Practical engineering notes by Benjamin Cane.