5 ms·
Nobody should be crucified either in public or in private. But correcting mistakes and making it explicit to the whole team what the problem was and how we'll m
by vasco 3y ago
Nobody should be crucified either in public or in private. But correcting mistakes and making it explicit to the whole team what the problem was and how we'll minimize the chances of reocurring is best done in front of the team. Everyone learns together, and most importantly, they see how you react to mistakes. They won't be afraid to talk about their mistakes if they see your normal reaction. It'll also feel less bad because now everyone is aware that everyone makes one every once in a while.
Create a culture where nothing is a personal attack and performance is just what it is, instead of something to be ashamed of.
In school all the kids get all their grades publicly, you don't get public grades if you do good and private grades if you do bad on the exam. And somehow we're all here and understood that it was what it was. The problem is that it was done as a "crucification".
Shouting and blaming and being an ass to someone are wrong to do either in private or in public.
- brightlancer 3y ago> Nobody should be crucified either in public or in private. Serious reprimands need to happen in private. We can use euphemisms or severe language, but sometimes people need to be told, "You fouled up, you were careless, you were indiscriminate, and your reckless mistake cost the company more money than you make in a year, which may cost someone ELSE their job because of budget cuts." Always remember that your foul-ups could cost someone their life or their livelihood. This isn't kindergarten. Adults need to be told honestly about the damage they caused.
- IggleSniggle 3y agoHuh. In my schooling experience, all grades were quite private unless someone shared!
- vasco 3y agoWoah! I just assumed this is how it worked everywhere. I might just need to re-think my whole stance and look this up. Thanks for sharing, I never thought to question it.
- zestyping 3y agoThe following case is interesting because it might fall in the space between what various folks on this thread consider acceptable. An engineer on my team once merged a change that created a security vulnerability, without review. We didn't have any real users on prod yet, and the potential impact was small. But I was still angry because I had given explicit instructions (speaking as the tech lead and the one with the most security experience) that all changes had to go through code review for security issues. I responded with an email message that was visible to the whole team (about 5 people). I knew it would sting, but I also wanted everyone to know that this was an important line not to cross, because at some point in the near future we did hope to have real users. I wrote, approximately, "You merged this change without review, and that's not okay. I explicitly told you not to do that. As a result, we now have a security vulnerability. Don't ever do that again." I am paraphrasing from memory, but the tone was not too far off from this: stern, direct criticism without personal attack. At the time, I held myself to a simple standard of communication: stating facts and criticising actions (even bluntly) was acceptable; any criticism of personal attributes was unacceptable. The engineer in question was very hurt and angry with me, and our working relationship was difficult for many weeks after that. Was I the asshole here? What's your standard of communication, and what would you do, from the point of view of the tech lead or as the engineer?
- vasco 3y agoI think writing "you merged" rather than,"we don't do this" would be a bit better. Also not acknowledging that there were no users yet, so impact wasn't there actually, but it would be if it happened later, was also important to acknowledge as the lead. In general I'd write a similar thing, just speaking of the team, and not overplaying the impact. If you had no users it was no problem, that's the truth. But it would be a problem in the future so you want the team to know and practice safety. People tend to be upset if you hype it more than it is, even an little, and it comes across as you just wanting to be right for rights sake. And generally we/team/process focused language is better than "you fucked up". Why did you even have merges enabled without reviews? It's more your process failure than that guy. That being said I work in full remote with many different cultures so I have an "international average". If this was a fully Russian team or some such even what you wrote was too soft in my experience and you actually need to be very clear or they think it's nothing.