Defending Previously Made Decisions: A Proven Approach
A guide for Engineering Leaders to defend their team's decisions.
Do you feel upset when:
someone questions a complex decision that shouldn't be questioned again?
a new manager forces you to change direction
If so, you're not alone. I know how frustrating it can be to reconsider past decisions, especially when you've put a lot of time and effort into making the original decision.
Today, I will share how you can manage such situations and defend your decisions, assuming they were reviewed & accepted at that time.
⚡️ 1. Watch your initial reaction
When someone new challenges past decisions, it is natural to feel uncomfortable and dismiss their concerns. I am not proud of it, but I have done it too. I used to think:
you are trivializing the problem
you don’t realize the nuances you are missing, so don’t jump to changing the decisions here.
Some people are not good at asking clarifying questions, so they sound like they are proposing a decision change. In such cases, I change the framing of their statement and ask - are you asking:
Why are we doing X instead of Y?
What factors did we consider, and did we evaluate the trade-offs?
The timing of the question may be wrong, but don’t be rude. Let them know that you will follow up later. For example, you are dealing with an incident, and someone asks an unrelated question at the moment. (Caveat: sometimes, those seemingly unrelated questions could matter)
🔄 2. Should you resolve this?
If you two cannot resolve the disagreement quickly, then you have two ways to proceed:
1. Resolving the disagreement is important. Do this.
If this is a new team member or a stakeholder who believes the decision needs to change.
If the original decision was made with partial information and is pending re-evaluation.
2. Resolving the disagreement is not worth the time/effort.
If they are not stakeholders, they are missing too much context and are unlikely to influence the direction.
If the cost of the wrong decision is low or easy to pivot in the future.
🕵️♂️ 3. Root cause
Complex disagreements stem from situations that have no easy answers. So, to find the root cause of the disagreement, you need to look at non-obvious places. Some dimensions to consider:
Weighing options differently?
Let’s say the problem has two subproblems—A and B. Someone who feels problem A is bigger may choose a different solution than the one who thinks B is bigger. You and that person may not realize this is the reason you disagree. You might defend your own solutions but not realize the reasons for disagreement.
Different past experience
Our past projects influence how we perceive new projects. So, someone who has done large-scale migrations before will err on the side of avoiding them. Conversely, someone tired of the current system’s problems may want to migrate away.
Risk-taking appetite
Let’s say your team is balancing a thin line between adding new customer features and improving reliability. The rush to add them can make things unstable, which in turn can affect customer relations. There may be no easy answer here.
What is an acceptable level of unreliability? Will you lose a customer because you can’t deliver the requested feature? Do you need more customers when you can’t handle the existing ones?
You and your team need to have an honest discussion about the balance. Set acceptable reliability thresholds upfront and use those to pivot over time.
⚖️ 4. (Re)Decide
Now that the two of you understand where you disagree, you must decide. Common dimensions to consider so that the (re-) decision is not wrong:
Ideal vs Practical
Ideally, your software should have no bugs and not fail under any overload. You should fix those gaps. But what if you have 100s of gaps? You don’t have the time to fix all of them!
That means you must prioritize what you will build real fixes for vs. where you will build “hacks.”
Sunken-fallacy syndrome
We have already spent months doing this, we can’t stop now. But are you ok doing this for another year(s)?
If your decision isn’t producing a good outcome, stop and pivot! There is no shame in stopping a project when it isn’t the right solution.
Not accounting for all factors.
What seems like the “right” technical solution on paper may not account for operational load, cost of change, and customer requirements. So, when you re-decide, don’t make the decision in isolation.
Also, if the change in decision has a marginal change in the outcome but has a huge cost, stick to the prevailing decision.
📄 5. Document to avoid future churn
While this debate is fresh, document it. That way, when the question comes up again, you just point people to it. Note, don’t just document the decision but capture the journey of the decision. Include:
How did you evaluate the trade-offs and the thesis behind the decision?
Capture the summary of any analysis/data used to decide.
Capture notes likes - which problem was weighed more, FAQs challenging the decision, etc.
How much instability is acceptable during rollout?
If the decision should be re-evaluated in the future, then when & after which milestone?
Parting Note
It is natural to get annoyed when complex decisions are challenged after a long time. Watch out for your reaction, and don’t be dismissive. Some disagreements are worth solving and require an intentional effort to resolve. Lastly, keeping an open mind will help you find better solutions.
🎤 Shoutout
Communicate like a Senior: Phrases used by the best leaders by
How to keep up with all the digital content by
The Sweet Spot Between Too Much and Too Little by
If you enjoyed this article, then hit the ❤️ button. It helps!
If you think someone else will benefit from this, then make sure to 🔁 share this post.