I never understood the "correct in private" stance. How can others learn who did not do the mistake? The argument to have critique in private only is probably because of ego and honor culture where people feel personally attacked in topics where it's not about them at all but about the actions they have taken in a professional context with rules and expectations.
But I fully agree on not talking to the manager, but praising in the full team instead.
"Correct" is the key word, I think it is important to make sure that people feel not attacked and your take on it is mostly correct but this is mostly in context of opinions and nit-picking. Actual failures need to be owned publicly.
I think a missing element in what I said is that I also fully believe that if I fail at something, it is my responsibility to inform the team rather than wait for someone else to levy blame. ("My apologies, I realized I misread the ticket and wrote the logic expecting X when it should be expecting Y." or "I created the typo there, I'm sorry, will fix by XX AM.") If the team works in that context, then you don't need to correct in front of the team as the person who failed would inform others and use it as a learning moment for all. This also kills the ego problem a little.
I also think failures tend to be systematic in nature and are rarely owned by a single person once you get to the bottom of the 5 "whys". We use Github BATS in PRs now, this fully killed the whole rubber duck of shame culture in our engineering division. While someone breaking the build used to be a singular responsibility, now it is a shared responsibility of the reviewer and tooling and nobody else's build gets broken by bad code. It is easy to blame the person who wrote the code but that excuses those that create the systems and culture.
I think correcting in private makes sense if also paired with a no-blame oriented retro after the fact for everyone to know what happened and to brainstorm about preventative measure in the future.
Those are two separate discussions. Even if I do something dumb and am rightly blamed for it, we can still have a retro to discuss process improvements that would make it harder for that mistake to happen again in the future.
This is what I had in mind, thank you for putting it into better words that I could.
Taking responsibility for messing up is important and part of personal growth. Having the team be aware of an issue and then together develop a way to avoid that issue in the future is huge.
I had a boss who told me that when something like this happened, it was usually an issue with a system in place. Merged bad code that shouldn't have gone to production? We need to improve review processes and testing. Production server outage after system dependencies changed? We need a more accurate staging environment and testing process for our infra.
That mindset was so great to learn and I fully embrace it still.
Teams should introspect at a group level. That’s not controversial or relevant.
Unsolicited individual feedback has the potential to cause harm and an outside observer (you) can’t know the situation. So the safe and respectful move is to simply ask first. It costs nothing, your feedback is heard, and no harm is done.
But I fully agree on not talking to the manager, but praising in the full team instead.