5 ms·

> “I’ve noticed quality issues in your code recently that’s resulted in some rollbacks. Can we talk about how we can address that?” This is just about the lazi

> “I’ve noticed quality issues in your code recently that’s resulted in some rollbacks. Can we talk about how we can address that?” This is just about the laziest and least trustworthy language possible to use. Your reports aren't going to know what they don't know and are just going to become paranoid and work slower. The code quality will likely not improve from a conversation prompted this way. This is also a continuous process, not a magic high stakes meeting. If you're in charge you should see patterns in the code reviews and know what their knowledge gaps are causing these issues. They're looking to you for help if you're the one bringing this up in the first place. If that's too time consuming or over your head you should not be a manager. Leverage your own knowledge and use mentorship to avoid conflicts with your reports and the improved productivity will please the people above you as well. You aren't giving anyone what they need by merely communicating requirements. Your job is to fulfill those requirements with the team you have.

piterrro 2y ago
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.
- jimberlage 2y ago
  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?
  - whoknowsidont 2y ago
    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.
    - AgentOrange1234 2y ago
      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.
      - bryanrasmussen 2y ago
        >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.
- dakiol 2y ago
  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)
  - alsetmusic 2y ago
    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.
diatone 2y ago
I’m sure you mean well but reading GP’s post I’m convinced that the laziest and least trustworthy language to use is actually, “you’re sloppy.” Good idea to think in systems and figure out how to lift the quality of the team but it’s okay to give direct feedback. Especially if the feedback is like GP’s in that it kicks off a constructive conversation, which iiuc is exactly what your final sentence there is waxing on about… Edit; to be clear I’m suggesting to not aim to avoid conflict. Certainly don’t stoke it for no reason but there is a healthy kind of conflict and how it is engaged with, which builds trust, deepens human relationships, and leads to growth for everyone involved. Psychological safety etc
- sublinear 2y ago
  Ok fair. Some devs do not respond well to advice and consider it just as condescending. Most I've worked with aren't like this though. Yes, we should use our own judgement. My response is based on my own experiences with management that are incapable of moving the needle on anything, rarely have any constructive input, and ultimately cause their team to either quit or be fired. Then they themselves get pressured to quit. It's very obvious to devs when someone delegating couldn't even do the work themselves or would do an even sloppier job. It's one thing to expect higher performance, but quite another to demand it while spending all day in meetings giving limp wristed handshakes and bullshitting their way through every question they get from anyone. I understand that it's already hard enough to hire good devs let alone promote one into management. I'm suggesting how an organization goes about making and promoting those people from within. This industry cannot go on like this. I don't care if someone isn't perfect when I hire them, but I do care that everyone wins.
- YZF 2y ago
  Maybe it means the manager assigned work to someone junior that was beyond their capabilities? I suggest the manager has a talk with themselves along these lines: "I've noticed you've assigned Jimmy to work on improving the scalability of the widget producer. In retrospect this was beyond where Jimmy is right now in his journey as a software engineer. Let's reflect on this incident and try to make sure that we have people working on things that help them grow but don't put them in a position where they don't have the experience to do the job right and also to realize they don't have that experience". Seriously though, I don't think there's "healthy conflict". There are healthy relationships where you can someone they're full of it without it being an insult or you can discuss how to write better software without it being perceived as a personal insult. An environment where people want to grow, are curious, are friendly, and just talk about how to do things better. Once you're in "conflict" territory it's something else. Unfortunately in most organizations you actually do have to get into conflict territory to impact change but I don't see that as a positive thing, just a negative that is a fact of life. EDIT: This "I noticed blah" pattern is what's taught in formal management training as a method of giving feedback. I know because I've done those. The problem is that wrapping negative feedback in some formulaic pattern is transparent and doesn't work. So the person receiving this immediately strips away your formula and hears the negative feedback. I know that's what I do when someone uses those tools on me. The way forward is not to use those tools but to engage in a true positive way and foster a positive atmosphere. A smart person already knows there's a problem when their code got rolled back. The discussion shouldn't be about their performance "issue" but just about assigning people jobs they can handle and giving them tools and support to that right. There are exceptions when there are more complicated things going on, but the way this is handled when people have good intentions and are motivated is to generally keep helping them stay motivated and have good intentions even when they make mistakes.
the_clarence 2y ago
This sounds so stupid. I'm sorry but feedback is already given in PRs. This kind of feedback is just a bad idea IMO. Focus on growth and areas of improvements. Your reports often already know what they should focus on, and they are on their own journey of time management. The only lever you have as a manager is to add or remove pressure. The only help you can give is through mentoring or therapy/coaching.
jimberlage 2y ago
> “I’ve noticed quality issues in your code recently that’s resulted in some rollbacks. Can we talk about how we can address that?” That’s the first step in fixing the quality issues, not an end state. Reports don’t know what they don’t know, so step 1 is to get their ideas on how to fix quality issues.
SkyPuncher 2y ago
It really depends on how you communicate with your team and the level of physiological safety you have. I work on a team where this would be a "matter of fact" means of having this conversation. Nobody on the team would bat an eye at someone else telling them this or their manager telling them this. We all know we're extremely good at our jobs and we all know that even the best of us have issues from time to times. Every, single, one of us would prefer to have this conversation upfront, before it becomes a spiraling issue that results in termination. That being said, I've also worked on teams where I'd be sending my resume out the moment I've heard those words.
paulddraper 2y ago
Huh? This is precisely the way to have that conversation.
Cpoll 2y ago
I'm willing to give them the benefit of the doubt, there's a tendency to write like that when you certainly wouldn't say it like that. It doesn't help that it's an example. In a real meeting, it might be more like "the email bug last week was a big problem. I'm not trying to blame you, but it can't happen again, so what happened?" But I'm also inclined to agree with you. If your strategy to maintain quality hinges on people not messing up, you'll have a bad time.
- localghost3000 2y ago
  Heh. Thanks for this. I am a bit disheartened about how much the arbitrary example I made is getting picked apart vs the actual point I was trying to make. It is what it is. HN gonna HN and all that lol. Blameless culture is very important. You need psychological safety. Maybe I should have picked something else as an example like rudeness or something. Ah well.
localghost3000 2y ago
I mean look, it was an arbitrary example I gave and not a very good one apparently. The bulk of these comments are all focusing myopically on that which is a bummer as it distracts from the point I’m trying to make. Managers need to be willing to have hard conversations and most new ones don’t. I believe strongly in a blameless culture when it comes to bugs and such. The example I gave doesn’t really honor that. I can’t edit it unfortunately. I do stand my my larger point however.

piterrro 2y ago

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.

jimberlage 2y ago
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?
- whoknowsidont 2y ago
  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.
  - AgentOrange1234 2y ago
    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.
    - bryanrasmussen 2y ago
      >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.
dakiol 2y ago
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)
- alsetmusic 2y ago
  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.

diatone 2y ago

I’m sure you mean well but reading GP’s post I’m convinced that the laziest and least trustworthy language to use is actually, “you’re sloppy.” Good idea to think in systems and figure out how to lift the quality of the team but it’s okay to give direct feedback. Especially if the feedback is like GP’s in that it kicks off a constructive conversation, which iiuc is exactly what your final sentence there is waxing on about… Edit; to be clear I’m suggesting to not aim to avoid conflict. Certainly don’t stoke it for no reason but there is a healthy kind of conflict and how it is engaged with, which builds trust, deepens human relationships, and leads to growth for everyone involved. Psychological safety etc

sublinear 2y ago
Ok fair. Some devs do not respond well to advice and consider it just as condescending. Most I've worked with aren't like this though. Yes, we should use our own judgement. My response is based on my own experiences with management that are incapable of moving the needle on anything, rarely have any constructive input, and ultimately cause their team to either quit or be fired. Then they themselves get pressured to quit. It's very obvious to devs when someone delegating couldn't even do the work themselves or would do an even sloppier job. It's one thing to expect higher performance, but quite another to demand it while spending all day in meetings giving limp wristed handshakes and bullshitting their way through every question they get from anyone. I understand that it's already hard enough to hire good devs let alone promote one into management. I'm suggesting how an organization goes about making and promoting those people from within. This industry cannot go on like this. I don't care if someone isn't perfect when I hire them, but I do care that everyone wins.
YZF 2y ago
Maybe it means the manager assigned work to someone junior that was beyond their capabilities? I suggest the manager has a talk with themselves along these lines: "I've noticed you've assigned Jimmy to work on improving the scalability of the widget producer. In retrospect this was beyond where Jimmy is right now in his journey as a software engineer. Let's reflect on this incident and try to make sure that we have people working on things that help them grow but don't put them in a position where they don't have the experience to do the job right and also to realize they don't have that experience". Seriously though, I don't think there's "healthy conflict". There are healthy relationships where you can someone they're full of it without it being an insult or you can discuss how to write better software without it being perceived as a personal insult. An environment where people want to grow, are curious, are friendly, and just talk about how to do things better. Once you're in "conflict" territory it's something else. Unfortunately in most organizations you actually do have to get into conflict territory to impact change but I don't see that as a positive thing, just a negative that is a fact of life. EDIT: This "I noticed blah" pattern is what's taught in formal management training as a method of giving feedback. I know because I've done those. The problem is that wrapping negative feedback in some formulaic pattern is transparent and doesn't work. So the person receiving this immediately strips away your formula and hears the negative feedback. I know that's what I do when someone uses those tools on me. The way forward is not to use those tools but to engage in a true positive way and foster a positive atmosphere. A smart person already knows there's a problem when their code got rolled back. The discussion shouldn't be about their performance "issue" but just about assigning people jobs they can handle and giving them tools and support to that right. There are exceptions when there are more complicated things going on, but the way this is handled when people have good intentions and are motivated is to generally keep helping them stay motivated and have good intentions even when they make mistakes.

the_clarence 2y ago

This sounds so stupid. I'm sorry but feedback is already given in PRs. This kind of feedback is just a bad idea IMO. Focus on growth and areas of improvements. Your reports often already know what they should focus on, and they are on their own journey of time management. The only lever you have as a manager is to add or remove pressure. The only help you can give is through mentoring or therapy/coaching.

jimberlage 2y ago

> “I’ve noticed quality issues in your code recently that’s resulted in some rollbacks. Can we talk about how we can address that?” That’s the first step in fixing the quality issues, not an end state. Reports don’t know what they don’t know, so step 1 is to get their ideas on how to fix quality issues.

SkyPuncher 2y ago

It really depends on how you communicate with your team and the level of physiological safety you have. I work on a team where this would be a "matter of fact" means of having this conversation. Nobody on the team would bat an eye at someone else telling them this or their manager telling them this. We all know we're extremely good at our jobs and we all know that even the best of us have issues from time to times. Every, single, one of us would prefer to have this conversation upfront, before it becomes a spiraling issue that results in termination. That being said, I've also worked on teams where I'd be sending my resume out the moment I've heard those words.

paulddraper 2y ago

Huh? This is precisely the way to have that conversation.

Cpoll 2y ago

I'm willing to give them the benefit of the doubt, there's a tendency to write like that when you certainly wouldn't say it like that. It doesn't help that it's an example. In a real meeting, it might be more like "the email bug last week was a big problem. I'm not trying to blame you, but it can't happen again, so what happened?" But I'm also inclined to agree with you. If your strategy to maintain quality hinges on people not messing up, you'll have a bad time.

localghost3000 2y ago
Heh. Thanks for this. I am a bit disheartened about how much the arbitrary example I made is getting picked apart vs the actual point I was trying to make. It is what it is. HN gonna HN and all that lol. Blameless culture is very important. You need psychological safety. Maybe I should have picked something else as an example like rudeness or something. Ah well.

localghost3000 2y ago

I mean look, it was an arbitrary example I gave and not a very good one apparently. The bulk of these comments are all focusing myopically on that which is a bummer as it distracts from the point I’m trying to make. Managers need to be willing to have hard conversations and most new ones don’t. I believe strongly in a blameless culture when it comes to bugs and such. The example I gave doesn’t really honor that. I can’t edit it unfortunately. I do stand my my larger point however.