DEV Community

Benjamin Cane
Benjamin Cane

Posted on • Originally published at bencane.com on

One of the toughest engineering skills to develop is accepting a decision you disagree with. ๐Ÿ˜–

One of the toughest engineering skills to develop is accepting a decision you disagree with. ๐Ÿ˜–

When you treat engineering as a craft, itโ€™s easy to get passionate about solutions. Strong opinions are a good thing โ€” many great engineers have them.

But you also need to know when to challenge a decision and when to accept it.

๐ŸŽฏ The Inflection Point

Every architecture review eventually narrows down to a few viable options. Maybe itโ€™s captured in an ADR, maybe through discussion, maybe through a decision-maker.

If your preferred option isnโ€™t chosen, you have two paths:

  1. Keep challenging the decision
  2. Accept it and support it fully

Knowing which path to take is a critical engineering skill.

๐Ÿ”ฅ When to Keep Challenging

My rule: Will this decision cause me to lose sleep โ€” figuratively or literally?

If the decision risks:

  • Breaking production
  • Waking you up at 2 a.m.
  • Introducing significant operational or security risks

Itโ€™s worth continuing the conversation.

And the best way to challenge is respectfully โ€” usually in a 1:1 with the decision-maker(s). This gives space for deeper context, trade-offs, and clearer alignment.

๐Ÿค When to Support a Decision You Disagree With

If the decision isnโ€™t dangerous โ€” just not your preferred optionโ€” itโ€™s time to commit. Many architectural choices have multiple valid options; one may be your preference.

In these cases, being a good engineer means supporting the direction chosen.

You can still improve the solution by suggesting micro-adjustments that reduce risk or enhance reliability without reopening the whole debate.

Sometimes, you will find that the chosen path was actually right. Donโ€™t worry, no one cares if you were right or wrong in the debate if you supported the implementation.

๐Ÿง  Final Thoughts

Sometimes decisions are mistakes. Thatโ€™s normal.

What matters is catching them early and being willing to revisit them once real-world data reveals new information. Implementation often teaches us things the whiteboard never could.

Just be careful not to over-index on finding every minor issue as a fundamental flaw in the solution.

Good architecture isnโ€™t about being right all the time. Itโ€™s about making informed decisions, supporting the team, and knowing when to push and when to commit.

Top comments (0)