Every team eventually meets someone who is certain. Certainty is useful when it is earned. It is expensive when it ignores a trail of failed attempts, the same pattern, the same outage shape, the same “it will be fine this time.”
I have worked beside people who talked over quieter engineers, dismissed incident data, and treated process as optional for themselves. The hard part is not being right. The hard part is staying professional while protecting the product from a method that has already lost, repeatedly.
What I do instead of matching ego
- Bring artifacts: timelines, metrics, previous postmortems, customer impact.
- Ask for a falsifiable plan: what would prove this approach wrong in two weeks?
- Propose a bounded experiment instead of a permanent architecture bet.
- Document decisions so the next outage has a paper trail, not folklore.
You will not convert everyone. Some people need the system to fail loudly one more time. Your job is to make sure the blast radius is small, the users are protected, and leadership can see the pattern without you turning into the office antagonist.
Respect is not obedience. You can respect a person and still refuse a failed method. That refusal is engineering, not attitude.
Key takeaways
What to remember
- Bring artifacts, not ego.
- Demand falsifiable plans.
- Shrink blast radius when certainty ignores history.
