Fully agree, quality is teams's effort and having a blameless culture where the team pushes for higher quality bar is essential. Chasing a single individual only makes sense when they have a track record of repeating the same thing multiple times - means they are not learning from their past mistakes.
Constantly pushing for higher quality is not healthy imo. You end up burned. I don’t want to be a high performer (I end up burned) and I don’t want to be a low performer either (end up fired). Something in between is something ICs shouldn’t be afraid of aiming to (unfortunately management doesn’t think like that and want to extract until the last drop of productivity from us)
Exactly. A steady pace is how one achieves longterm success. This is something that I learned after burning out. Do the job well, but don't kill yourself.
Out of curiosity, the OP’s language is “quality issues”, not “quality issue.” Why did you assume there wasn’t already a pattern of behavior implied there?
I'm not OP, but just by the way it was worded. It feels vague and grandstand-y. "I have noticed" is such a silly way to word what's happening here and it's hard not to imbue underlying meanings to it.
And then "can we talk about how we can address that." More vague, leading statements.
Speak to the facts. "The team / org had to roll back this release, the team does not think there is a process improvement that would have alleviated this problem, and the team relied on you to properly make this feature. Our exceptions of all team members is [...]"
Make it clear:
1. This is affecting the whole team (equally)
2. The team as a whole shares this perspective (it's not just the manager nitpicking)
3. There are consistent and vibrant standards that the entire team must adhere to
4. You are not meeting those standard(s) or necessary actions for success.
5. Offer what you think will fix the problem (if anything)
6. Make it clear this is their chance to agree/disagree
7. Continue to talk it out.
Honestly OP seems like a person who has struggled in his position as manager to properly speak to people, and instead of understanding why there was a struggle simply switched to more coded language.
Most people will see through it and react negatively.
I’m surprised by this and curious at the “team thinks” framing. What advantages do you see here?
I think I would much rather own the critique myself than say “the team thinks x.”
For context, I’d probably start with “what happened with that deployment that was rolled back?” and let them self-diagnose and share their perspective. By listening, I might learn there were extenuating issues, or I may see they are already aware of the issue.
If they’re able to critique their own work, I can agree and reinforce the whys. There’s no hostility and we can talk about what ideas we have for what we can do going forward.
If not, and I think we must do better, I can talk about my concerns, my expectations, and the consequences that I am worried about or frustrated by, and propose more prescriptive remedies.
>I’m surprised by this and curious at the “team thinks” framing. What advantages do you see here?
>I think I would much rather own the critique myself than say “the team thinks x.”
"the team thinks" means, well I went around and talked to everyone else about you before talking to you and they all say you suck! In short I don't think there would be an advantage to that.
