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:
- Keep challenging the decision
- 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.