It is more easy: do your job right, but do not comment, fix or somehow improve work of your colleagues. Let them fail, aknowledge failure and only then come with fix, get all praise.
Never point to the possible issues at the code reviews, retirement refinements etc.
Let your junior colleagues fail on a schedule within the margin of error on your planning, but keep a close enough eye on them so you know how to bail it out if they can’t pull it together with a little extra time/guidance.
Okay — still give good code reviews, but if you let them face-plant a little on design, etc, then they get experience. And you don’t look dumb when it turns out they were right. But you do look like a hero when they’re struggling to get across the line, and you whisk in to fix it.
This is also just good practice in general. You learn through struggle, so giving juniors a safety net (when they don't know they have it), is a good way to get them up the curve.
That is naive take, you really think if you work hard on improving code, pointing out flaws, there will never be any issues?
In reality that I live, there is never enough time, if you have 3-4 team mates pumping features out, it is already impossible to prevent every problem and review every piece of code.
I don't have to be cynical about it, it just happens that issues will crop up over time and I am there to fix them and there is never enough time to prevent them up-front, because if you will try then you will never deliver anything. Ship fast and break things is maybe too far - but still shipping something beats not shipping ideal state.
We also don’t have bad releases but we had a new customer that added 100 users that used specific workflow that was working for years for other customers.
Those 100 users took performance to a crawl but we never seen it earlier because it was never used that way in that capacity.
Never point to the possible issues at the code reviews, retirement refinements etc.