7 ms·

This misses the single biggest mistake every new manager makes: avoiding hard conversations with your reports. If you start managing folks you were recently in

This misses the single biggest mistake every new manager makes: avoiding hard conversations with your reports. If you start managing folks you were recently in the trenches with this can be VERY hard. These are your comrades after all! You want them to like you. It’s all very natural. Sadly it is the single biggest cause for dissatisfaction I’ve seen on a given team. Being unwilling to give honest, direct feedback results in underperforming teams and unhappy reports. It’s counterintuitive but very important to get right as a manager. The big “AHA!!” moment for me was when I realized you need to speak to behaviors and outcomes not character. So instead of “you’re sloppy” you say something like “I’ve noticed quality issues in your code recently that’s resulted in some rollbacks. Can we talk about how we can address that?”. Involving them in the solution and explaining why it matters. It makes all the difference and folks ironically respect and like you more for it.

steerpike 2y ago
100% agree with this. I would say that the other highly likely mistake new managers make is trying to code their way out of problems. It makes sense, right? Previously when you're an IC and a project ran into issues you could just "code harder" and get through it, but that's rarely the right solution when you're a manager and will likely exacerbate the problem itself if you disappear into the trenches trying to code your way through a critical path. Your role is no longer primarily solving coding problems it's solving people problems.
- anotheracc88 2y ago
  Indeed. Purposefully stay off the critical path! Do coding that helps you keep up with what people are talking about. Not coding that is urgent!
  - ad_hockey 2y ago
    I made that mistake as a new manager by picking up a small but important task in an area I knew well. I thought it would help unblock the team, but I didn't realise I was about to go into three days of back to back meetings. After the third stand-up in a row of reporting zero progress I sheepishly reassigned the ticket to someone else, and didn't make that mistake again. Refactors, doc fixes, low priority bug fixes, and tech debt are all fair game for managers to pick up. I do think it's important to keep your hand in.
- osigurdson 2y ago
  If you are not going to add anything technically, you should probably have 20+ reports.
  - diatone 2y ago
    It depends!
bobsomers 2y ago
Completely agree. This is excellent advice.
roenxi 2y ago
I got the impression that when he says "couple of years" he's talking about the low-end of the word couple. The other thing in the article that jumps out is the conclusion where he says that a team that is shipping and happy is enough to be crushing it. That isn't really enough in my experience. There are 3 questions - is the team happy? Are they shipping? Is what they are shipping valuable? - and I've seen a lot of new managers are so overwhelmed that they forget about number 3 and a fair chunk of people end up unemployed because sooner or later the bean counters figure out that the team isn't actually productive. This article, overall, doesn't identify achieving excellent outcomes as something he got wrong at first. I suspect either he is a natural manager or it is a mistake that is still being made. Probably the latter based on the other mistakes identified. The journey I've seen usually goes from lost -> controlling external perceptions of success -> oh I need to actually succeed and it isn't what I thought.
- choppaface 2y ago
  > Is what they are shipping valuable? That’s indeed critical, but most Director-level managers and below have very little control of how well the business model serves the OKRs. Yes the OKRs need to be achieved and help make the business work, but e.g. if the business model’s margins are just too tepid or if the VC’s expected revenue growth (exponential?) will never actually realize, then there is really zero material value to the shipped product. Hence the focus on a happy team that’s shipping, because at least that provides some technological value. And build a network you can bring to your next gig—- because that’s what gets you the next job. There are rare cases where a team might discover a new business model or impress a whale customer, and then the business model fundamentally changes. Yes there is risk the “bean counters” or CFO / COO office will want to cut the cord (especially now tech hiring is in a recession). But tech moves fast; those bean counters will likely end up owning shares of a zombie in the next 5-7 years. And their game is to cash out, not build a future. And if the business model actually works, then keep at those OKRs and everybody should win. Good business models are where stupid can succeed; the team has the right levers.
brailsafe 2y ago
I agree with the sentiment and importance of addressing these things, or dealing with conflicts in-general, but I disagree with the tone somewhat and disagree with the notion that you're not in the trenches with them, but it depends on what trenches means to whoever it's relevant to. I feel like many new managers know they'll need to deal with this, but never developed their abilities prior to being a manager, and don't realize that just because the conversation happens, doesn't mean it produces valuable outcomes, breeds respect, or means anyone will like the way you approached it, or even that you were as vulnerable or honest as you thought you were. Every manager I've had that used your example quote—almost verbatim—went on to be incredibly passive-aggressive, because they're trying too hard not to actually create conflict, they want to be liked more than they care about the result, they don't have that much innate confidence, or like the author of the article suggested, they want to see the results they would have produced when they were an IC, and haven't yet learned how to guide autonomy and relinquish a certain amount of control. These are perhaps the traits that led them to keeping their IC job all those years. These people would turn 1-on-1s into 45 mins of beating around the bush, trying to get me to reveal myself as having insufficiently met the unspoken criteria they've been having internal anxiety attacks about, and maybe in the last few minutes when there's no room left for pushback they'd conjure the answer they wanted to hear and set that as the benchmark. This failure on their part predictibly bled into other interactions and created toxicity and resentment, they couldn't yield control, and they couldn't have a real discussion that involved more than themselves manifesting as their overbearing mother waiting for their kid to implicate themselves for some petty wrongdoing. They couldn't clearly communicate priorities, or timelines, or requirements, and were starting in their new job with a skill issue of their own. They hadn't adapted to the role or developed a good personality for it, and apparently lacked an ability to reflect on their behavior or communication style. I don't mean to extrapolate too far from this or in-turn attack you in any way, it's just a small quote, but in the past it's been telling. "Can we talk about code quality issues" doesn't just avoid a character trait, which I agree should should never be the target, it leans into vague, soft, meek, intentionally indirect language that just creates undue anxiety and establishes an ambiguous context for whatever the problem might be, and was a dishonest pretext for for downstream attribution of fault, since they couldn't accept the possibility that the problem might be upstream (which it wasn't always, but if it had been, they weren't going to address it then). In these situations, sometimes I was struggling with purely my own productivity, having a bad couple weeks, but otherwise it was some other issue they weren't willing or able to genuinely help me with. Do your best to be humble, learn to delegate and try to trust people, avoid thinking about character traits but don't avoid direct (and clear) language, and accept that your perception might be inaccurate. Get as far away as necessary from the dreaded "just checking in" or "is there anything we can do to improve (your problem)" as possible. What if their code is suffering because of noise in the office or someone's depressed because they're having relationship issues? What if it's because you keep coming over to their desk unannounced and asking diverting their attention? If you can do that, you're on a good track. Edit: it's worth noting that the underlying assumption in all of my comment is that people and their reasons and issues are often different, and likewise how they respond to this language may be different, and as such many might actually love the quoted phrases because they aren't imposing, and a good manager will do their best to communicate with people in a way that accepts that a variety of ways to address conflict is the right move, and sometimes less imposing language is viable.
crowcroft 2y ago
I have found that company culture has the biggest impact on junior managers. It sets the expectation for them the most because they don’t have any actual ability yet. Overly empathetic companies end up with terrible junior managers because they can’t have any real direct conversations. Tough and demanding companies I have seen fair much better because no one can hide from tough conversations for too long.
- hackable_sand 2y ago
  That's not what empathy means.
  - crowcroft 2y ago
    I’m meaning in the sense of ‘ruinous empathy’ https://www.radicalcandor.com/faq/what-is-ruinous-empathy/ https://www.radicalcandor.com/faq/what-is-ruinous-empathy/
    - hackable_sand 2y ago
      Thank you for the link. I like saying "confront with compassion" for the upside of empathetic honesty.
    - deleted 2y ago
      [deleted]
hackable_sand 2y ago
These are the marks of a passive-aggressive and adversarial manager who would sell their team out from under them.
- localghost3000 2y ago
  This is literally the opposite of passive aggressive. That’s my entire point!! You have to be direct with people so the know where they stand. That applies to what they’re doing well on also. As for the “sell out” statement… I have no idea how you got that out of what I said. Sounds like maybe you had some bad managers?
  - hackable_sand 2y ago
    That camaraderie should have been built up in the trenches. They must trust you enough to be honest, otherwise they are not your comrades. If your words and tone sound nice, they can still be mean, doubly so.
pdonis 2y ago
> I’ve noticed quality issues in your code recently that’s resulted in some rollbacks I would tend to even leave out the first part of that phrase. Focus on the actual objective measure: the rollbacks. They happened, and the goal is to figure out how to not have them happen in the future.
- xandrius 2y ago
  Yeah, code quality is marginally important if whatever QA/UAT process allowed that code to go to production. If "bad code" can make it to production it's usually the fault of the system as a whole, not the author.
  - nrclark 2y ago
    I have mixed feelings about this. For the most part, I think "you can't bolt on quality after the fact" is true. Code reviews and CI/CD automated-tests are helpful, but can never be thorough enough to catch every mistake that a low performing developer might make. If that developer causes enough problems over time, that is absolutely something that their manager can and should address.
    - xandrius 2y ago
      I'd think about actioning the individual only if it was exactly the same issue every time (how did the same issues manage pass time and time again, didn't we learn anything as a team?). Otherwise I'm more in the mentality that breakages are a great way to improve internal flows against (inevitable) failures. I think the real problem would be when a developer cannot manage to get any code into production (e.g. Code stuck in PR for weeks) but once the rest of the team and our systems approve it then they have proven their worth. Also, if developer X's code keeps passing code reviews, CI/CD, QA and UAT, and it's not the fault of the systems in place, I would ask myself what kind cutting edge stuff are they working on?
- quietbritishjim 2y ago
  I disagree, at least in this case. In the comment you're replying to, the new manager is technical and familiar with the codebase, and can assess that the reason for the rollbacks is a genuine quality issue. This is useful information, and if you leave it out then you leave your report partially in the dark, wondering if the rollbacks are happening for some other reason (I can think of plenty). I'm not saying it needs to literally be in the first sentence or phrased exactly like that, but I don't think that's what they meant anyway. Rather, you do need to be upfront about it instead of alluding to the problem without giving away what you actually think.
antman 2y ago
"I have noticed you ate brutalizing your subordinates and that has increased quality and output but I know it is not sustainable and the team is going to crash" any ideas how to communicate it are welcome
- NhanH 2y ago
  What's wrong with saying what you typed above verbatim? It is a fairy standard scenario and your wordings probably have been said in one-on-one millions of times. You need to follow up the sentence with "what's next", since the scenario does not have a simple solution (the manager can tone down the demand, but then output and quality goes back to where is was and we have to deal with that). But now that is more about the work itself rather than communication
  - antman 2y ago
    That is how I said it, but there was no joint understanding of what I predicted about the future.
sublinear 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?” 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.
beryilma 2y ago
> I've noticed quality issues in your code recently... Why is it always the report who is the source of the problem and not the manager? How about "I've created a toxic work environment and put my reports under a lot of stress. And I have not given them any opportunities to grow and learn new skills. I am planning to do better..." Words that will never come from the mouth of a manager. Have a hard conversation with yourself first before blaming the reports.
- LanceH 2y ago
  Articles aren't written for reports, or at least the advertising on those articles are directed at the managerial and above level.
  - cutemonster 2y ago
    Yes, and s/he did actually say: "Can we talk about how we can address that?" rather than "Can we talk about what you can stop doing wrong" (Although maybe does sound a little little bit in that direction?) Maybe the answer is "Too much stress and deadlines"? And it's the manager's fault? What's something even more neutral to say, that leaves the possibility that it's the managers "fault" more open?
interludead 2y ago
Navigating hard conversations is arguably the crucible for new managers

steerpike 2y ago

100% agree with this. I would say that the other highly likely mistake new managers make is trying to code their way out of problems. It makes sense, right? Previously when you're an IC and a project ran into issues you could just "code harder" and get through it, but that's rarely the right solution when you're a manager and will likely exacerbate the problem itself if you disappear into the trenches trying to code your way through a critical path. Your role is no longer primarily solving coding problems it's solving people problems.

anotheracc88 2y ago
Indeed. Purposefully stay off the critical path! Do coding that helps you keep up with what people are talking about. Not coding that is urgent!
- ad_hockey 2y ago
  I made that mistake as a new manager by picking up a small but important task in an area I knew well. I thought it would help unblock the team, but I didn't realise I was about to go into three days of back to back meetings. After the third stand-up in a row of reporting zero progress I sheepishly reassigned the ticket to someone else, and didn't make that mistake again. Refactors, doc fixes, low priority bug fixes, and tech debt are all fair game for managers to pick up. I do think it's important to keep your hand in.
osigurdson 2y ago
If you are not going to add anything technically, you should probably have 20+ reports.
- diatone 2y ago
  It depends!

bobsomers 2y ago

Completely agree. This is excellent advice.

roenxi 2y ago

I got the impression that when he says "couple of years" he's talking about the low-end of the word couple. The other thing in the article that jumps out is the conclusion where he says that a team that is shipping and happy is enough to be crushing it. That isn't really enough in my experience. There are 3 questions - is the team happy? Are they shipping? Is what they are shipping valuable? - and I've seen a lot of new managers are so overwhelmed that they forget about number 3 and a fair chunk of people end up unemployed because sooner or later the bean counters figure out that the team isn't actually productive. This article, overall, doesn't identify achieving excellent outcomes as something he got wrong at first. I suspect either he is a natural manager or it is a mistake that is still being made. Probably the latter based on the other mistakes identified. The journey I've seen usually goes from lost -> controlling external perceptions of success -> oh I need to actually succeed and it isn't what I thought.

choppaface 2y ago
> Is what they are shipping valuable? That’s indeed critical, but most Director-level managers and below have very little control of how well the business model serves the OKRs. Yes the OKRs need to be achieved and help make the business work, but e.g. if the business model’s margins are just too tepid or if the VC’s expected revenue growth (exponential?) will never actually realize, then there is really zero material value to the shipped product. Hence the focus on a happy team that’s shipping, because at least that provides some technological value. And build a network you can bring to your next gig—- because that’s what gets you the next job. There are rare cases where a team might discover a new business model or impress a whale customer, and then the business model fundamentally changes. Yes there is risk the “bean counters” or CFO / COO office will want to cut the cord (especially now tech hiring is in a recession). But tech moves fast; those bean counters will likely end up owning shares of a zombie in the next 5-7 years. And their game is to cash out, not build a future. And if the business model actually works, then keep at those OKRs and everybody should win. Good business models are where stupid can succeed; the team has the right levers.

brailsafe 2y ago

I agree with the sentiment and importance of addressing these things, or dealing with conflicts in-general, but I disagree with the tone somewhat and disagree with the notion that you're not in the trenches with them, but it depends on what trenches means to whoever it's relevant to. I feel like many new managers know they'll need to deal with this, but never developed their abilities prior to being a manager, and don't realize that just because the conversation happens, doesn't mean it produces valuable outcomes, breeds respect, or means anyone will like the way you approached it, or even that you were as vulnerable or honest as you thought you were. Every manager I've had that used your example quote—almost verbatim—went on to be incredibly passive-aggressive, because they're trying too hard not to actually create conflict, they want to be liked more than they care about the result, they don't have that much innate confidence, or like the author of the article suggested, they want to see the results they would have produced when they were an IC, and haven't yet learned how to guide autonomy and relinquish a certain amount of control. These are perhaps the traits that led them to keeping their IC job all those years. These people would turn 1-on-1s into 45 mins of beating around the bush, trying to get me to reveal myself as having insufficiently met the unspoken criteria they've been having internal anxiety attacks about, and maybe in the last few minutes when there's no room left for pushback they'd conjure the answer they wanted to hear and set that as the benchmark. This failure on their part predictibly bled into other interactions and created toxicity and resentment, they couldn't yield control, and they couldn't have a real discussion that involved more than themselves manifesting as their overbearing mother waiting for their kid to implicate themselves for some petty wrongdoing. They couldn't clearly communicate priorities, or timelines, or requirements, and were starting in their new job with a skill issue of their own. They hadn't adapted to the role or developed a good personality for it, and apparently lacked an ability to reflect on their behavior or communication style. I don't mean to extrapolate too far from this or in-turn attack you in any way, it's just a small quote, but in the past it's been telling. "Can we talk about code quality issues" doesn't just avoid a character trait, which I agree should should never be the target, it leans into vague, soft, meek, intentionally indirect language that just creates undue anxiety and establishes an ambiguous context for whatever the problem might be, and was a dishonest pretext for for downstream attribution of fault, since they couldn't accept the possibility that the problem might be upstream (which it wasn't always, but if it had been, they weren't going to address it then). In these situations, sometimes I was struggling with purely my own productivity, having a bad couple weeks, but otherwise it was some other issue they weren't willing or able to genuinely help me with. Do your best to be humble, learn to delegate and try to trust people, avoid thinking about character traits but don't avoid direct (and clear) language, and accept that your perception might be inaccurate. Get as far away as necessary from the dreaded "just checking in" or "is there anything we can do to improve (your problem)" as possible. What if their code is suffering because of noise in the office or someone's depressed because they're having relationship issues? What if it's because you keep coming over to their desk unannounced and asking diverting their attention? If you can do that, you're on a good track. Edit: it's worth noting that the underlying assumption in all of my comment is that people and their reasons and issues are often different, and likewise how they respond to this language may be different, and as such many might actually love the quoted phrases because they aren't imposing, and a good manager will do their best to communicate with people in a way that accepts that a variety of ways to address conflict is the right move, and sometimes less imposing language is viable.

crowcroft 2y ago

I have found that company culture has the biggest impact on junior managers. It sets the expectation for them the most because they don’t have any actual ability yet. Overly empathetic companies end up with terrible junior managers because they can’t have any real direct conversations. Tough and demanding companies I have seen fair much better because no one can hide from tough conversations for too long.

hackable_sand 2y ago
That's not what empathy means.
- crowcroft 2y ago
  I’m meaning in the sense of ‘ruinous empathy’ https://www.radicalcandor.com/faq/what-is-ruinous-empathy/ https://www.radicalcandor.com/faq/what-is-ruinous-empathy/
  - hackable_sand 2y ago
    Thank you for the link. I like saying "confront with compassion" for the upside of empathetic honesty.
  - deleted 2y ago
    [deleted]

hackable_sand 2y ago

These are the marks of a passive-aggressive and adversarial manager who would sell their team out from under them.

localghost3000 2y ago
This is literally the opposite of passive aggressive. That’s my entire point!! You have to be direct with people so the know where they stand. That applies to what they’re doing well on also. As for the “sell out” statement… I have no idea how you got that out of what I said. Sounds like maybe you had some bad managers?
- hackable_sand 2y ago
  That camaraderie should have been built up in the trenches. They must trust you enough to be honest, otherwise they are not your comrades. If your words and tone sound nice, they can still be mean, doubly so.

pdonis 2y ago

> I’ve noticed quality issues in your code recently that’s resulted in some rollbacks I would tend to even leave out the first part of that phrase. Focus on the actual objective measure: the rollbacks. They happened, and the goal is to figure out how to not have them happen in the future.

xandrius 2y ago
Yeah, code quality is marginally important if whatever QA/UAT process allowed that code to go to production. If "bad code" can make it to production it's usually the fault of the system as a whole, not the author.
- nrclark 2y ago
  I have mixed feelings about this. For the most part, I think "you can't bolt on quality after the fact" is true. Code reviews and CI/CD automated-tests are helpful, but can never be thorough enough to catch every mistake that a low performing developer might make. If that developer causes enough problems over time, that is absolutely something that their manager can and should address.
  - xandrius 2y ago
    I'd think about actioning the individual only if it was exactly the same issue every time (how did the same issues manage pass time and time again, didn't we learn anything as a team?). Otherwise I'm more in the mentality that breakages are a great way to improve internal flows against (inevitable) failures. I think the real problem would be when a developer cannot manage to get any code into production (e.g. Code stuck in PR for weeks) but once the rest of the team and our systems approve it then they have proven their worth. Also, if developer X's code keeps passing code reviews, CI/CD, QA and UAT, and it's not the fault of the systems in place, I would ask myself what kind cutting edge stuff are they working on?
quietbritishjim 2y ago
I disagree, at least in this case. In the comment you're replying to, the new manager is technical and familiar with the codebase, and can assess that the reason for the rollbacks is a genuine quality issue. This is useful information, and if you leave it out then you leave your report partially in the dark, wondering if the rollbacks are happening for some other reason (I can think of plenty). I'm not saying it needs to literally be in the first sentence or phrased exactly like that, but I don't think that's what they meant anyway. Rather, you do need to be upfront about it instead of alluding to the problem without giving away what you actually think.

antman 2y ago

"I have noticed you ate brutalizing your subordinates and that has increased quality and output but I know it is not sustainable and the team is going to crash" any ideas how to communicate it are welcome

NhanH 2y ago
What's wrong with saying what you typed above verbatim? It is a fairy standard scenario and your wordings probably have been said in one-on-one millions of times. You need to follow up the sentence with "what's next", since the scenario does not have a simple solution (the manager can tone down the demand, but then output and quality goes back to where is was and we have to deal with that). But now that is more about the work itself rather than communication
- antman 2y ago
  That is how I said it, but there was no joint understanding of what I predicted about the future.

sublinear 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?” 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.

beryilma 2y ago

> I've noticed quality issues in your code recently... Why is it always the report who is the source of the problem and not the manager? How about "I've created a toxic work environment and put my reports under a lot of stress. And I have not given them any opportunities to grow and learn new skills. I am planning to do better..." Words that will never come from the mouth of a manager. Have a hard conversation with yourself first before blaming the reports.

LanceH 2y ago
Articles aren't written for reports, or at least the advertising on those articles are directed at the managerial and above level.
- cutemonster 2y ago
  Yes, and s/he did actually say: "Can we talk about how we can address that?" rather than "Can we talk about what you can stop doing wrong" (Although maybe does sound a little little bit in that direction?) Maybe the answer is "Too much stress and deadlines"? And it's the manager's fault? What's something even more neutral to say, that leaves the possibility that it's the managers "fault" more open?

interludead 2y ago

Navigating hard conversations is arguably the crucible for new managers