But the cases where we have the most conflict aren't those in which I'm reviewed or questioned, but in which I'm reviewing or questioning something about the other engineer. As an example -- there was recently an incident that resulted in a global outage for three hours due to a bad code change. The root cause was related to his change, which enabled another change to break the code. Users had to report this to us -- we didn't have alerts. The impact would directly affect growth and revenue, but in ways we can't quantitatively determine.
I said we should do a post-mortem, add an integration test that would prevent recurrence, and add an alert -- the other engineer vehemently pushed back, claiming that it was another team's fault, since the code was shared with them, and pushed for another action item that wouldn't improve our operational stance. The other engineer has never worked in an operationally excellent team, whereas I have -- any other engineer who has would see a post-mortem as obvious. I think the opposite that you describe is the case; the other engineer still sees himself as effectively 'the lead', and wants to prove it, so is vulnerable and sensitive to loss of status or criticism.
Overall I don't think what you've described is actually the real story. Several engineers both on the team and off the team have had complaints about this engineer, and the same thing happened with the previous lead, who was much more experienced than either of us. One engineer was distressed enough that it really should've warranted going to HR, which I suggested to my manager, who didn't follow through out of fear of it reflecting poorly on him, which is really unfortunate. I was brought into the team exactly because my style of leadership isn't top-down, brusque, or imposing -- I made it clear from the start my intention wasn't to unseat the other engineer as 'lead', and deliberately tried to make a lot of space for him to have ownership and growth and put him back on the promotion track.
You don't have to take my word about this, but the intention of my post is to get advice. My main goal isn't to solidify my performance or status -- I'm already comfortably trusted and performing well. My goal is not to come into work with a high risk of conflict and stress each week, and needing to contort myself to avoid this. What would your advice be if I am representing the truth?
My advice would be 1) to not phrase decisions as suggestions, 2) motivate/justify with hard facts ("an outage occurred, we are having a meeting to discuss causes/mitigations"), 3) if post-mortems are perceived as publicly assigning blame, it can't work and the culture is wrong, and 4) never motivate decisions by identity ("my background is fancier than yours so get in line") which might be happening implicitly if decisions aren't sufficiently grounded in details and facts.
I was about to write the same thing. TS, if you feel strongly about the need for a post-mortem analysis then it is: "We WILL do a post-mortem analysis, and you WILL analyze root cause issues and you WILL help me write a report about the incident. It has the highest priority." It is not: "We should do a post-mortem analysis, you guys agree it is a good idea?" TS comes of as wanting to lead by persuasion, which imo very often doesn't work.