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.
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 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 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.
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
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.
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.
One generalized example I've seen. Jimmy proposes to make a change that assumes all Foos in production have been replaced with Bars, and will cause an outage if that's not so. Reviewer A says "hey, this seems risky - are you sure the Foos are gone?" "Yes, I'm sure, there's no way that there could be any Foos left". When it turns out that he didn't really check and there were some Foos left, your options are:
* Frank and conflict-laden conversation with Jimmy. By all means say it nicely, but the bottom line is that you can't maintain a collaborative culture if reviewers can't trust the things Jimmy certifies to be true. The underlying unhealthiness might be that it's too hard to verify production state, or that Jimmy isn't competent enough to do it, or that Jimmy is just lazy. You'll have to engage in some conflict to find out.
* Put Jimmy in a penalty box, where everyone knows they can't give him the normal level of trust and need to double check his work. (Won't Jimmy notice, and won't you then have to give him the same conflict-laden conversation? Probably.)
* Let Jimmy run around wrecking things until his relationship with the team is so compromised he's forced to transfer or quit.
Having seen managers pick all three options, the first seems clearly best to me.
We don't expect people to be perfect. Everyone will occasionally make mistakes. I would not frame it as a loss of trust.
If the answer is no then I agree there's a problem that needs to be root caused. Maybe the root cause is Jimmy had a fight with his spouse, or didn't get enough sleep. Maybe Jimmy just can't do the job we're asking him to do.
Beyond that there are process questions to be asked. Don't you have some sort of staged deployments? dev/stage/prod? The reviewer that was concerned about whether Foos are gone - why was he concerned? Is there an easy way to check that?
I wouldn't say there's never a situation for difficult conversations. But usually those are not the right tool for the job. Jimmy is completely aware (presumably) that he said no Foos are left, and that when his code merged the remaining Foos caused an outage, and that his change had to be rolled back to recover. He is a responsible and trusted member of the team. How does he own up to that? What is your culture? If he is not responsible nor trusted than eventually he'll not be there and that's something to be reinforced positively and understood by a high performance team. It's just my experience that if you're at a point where you're playing those games then it usually isn't going to result in a positive outcome. Those tools are not appropriate for high performance teams in high performance organizations. Maybe they are in different organizations.
EDIT: In the military for example it is common to reinforce what people need to do via some sort of punishment. The difference is that you got people who possibly don't want to be there in the first place and in general you don't fire soldiers. That method sort of works but it doesn't really produce the kind of environment a lot of us would like to be in and there's always conflict between fear of punishment and taking initiative.
I would also say there are other things that can be done in this scenario, including a culture of postmortems, where you review the incident as a team and brainstorm ways of avoiding it in the future. This can be tricky to be done in a truly blameless way but if done right can act as a positive reinforcement. In general it's better that peer pressure and culture are the mechanisms that drive people vs. managerial action simply because the manager can't be everywhere all the time. The manager drives that culture.
"you're sloppy" is too personal.
"this is not to the standard what I would expect" with reasons is factual, if, having been on the receiving end of, harsh. But it should not be done publicly.
"This has to be changed because it will break" (on a PR) is perfectly fine.
"This wasn't even run through linter, please don't drive folks to force push hooks" can be 3rd person passive aggressive (e.x. I'm not advocating for them but others want a series of hooks that is just...too...much...) but potentially factual.
"This .cs file was 2500 lines. You were given a choice but instead you chose violence" is something that was very very hard to not reword into something more polite when a PR wanted to add another 2600 lines. At the very least turn it into a more constructive "This .cs file is already 2500 lines. We need to stop the violence and refactor the class per-business-aspect."
I like that last example, because it shows some very subtle differences in how the same information can be communicated while severity/importance is still pretty dang clear.
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.
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.
This is precisely the way to have that conversation.
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.
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.
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.
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.
If "bad code" can make it to production it's usually the fault of the system as a whole, not the author.
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.
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?
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.
Only if the report doesn't already know it. But they probably do. It doesn't seem likely to me that the report would be in the dark about why the rollbacks happened. And if they already know it, it's better to let them ask for help than to tell them up front that you, their manager, know that their code quality is an issue. Give them a chance to identify the issue themselves first.
Sounds like this mistake:
> > avoiding hard conversations with your reports.
And hoping that things will get better soon. But:
> > Sadly it is the single biggest cause for dissatisfaction
that can also be among others in the team, who have to deal with the rollbacks.
One could say that the scenario as described in the post I originally responded to, by localghost3000, doesn't make sense, yes. If there have already been multiple rollbacks, and this is the first conversation you as a manager are having about them with this report, then you as a manager have already messed up by not addressing the issue sooner.
But that just makes it even more of a problem to lead with language like "quality issues in your code", implying that all the responsibility lies with the report, and none of it lies with you, the manager. The approach I described, where you focus first on the objective fact, that the rollbacks happened, and on how to keep them from happening again, avoids that.
Even if they do, mentioning that everyone is rejecting their code and asking why they think that is, when you know full well the answer, is classic passive aggression and more condescending than just stating the obvious situation (again, not saying it literally needs to be in the same breath like the sentence I quoted).
That's not what "rollbacks" means. "Rollbacks" means other people accepted their code, let it get into production, and then an issue surfaced that forced the change to be rolled back, and this happened multiple times. So at a minimum, there have to be other people besides this particular coder who made mistakes, multiple times.
If other people rejected their code multiple times in code review, the problem wouldn't be "multiple rollbacks", it would be "multiple rejections in code review", and yes, in that situation you have a much better case for being up front about "quality issues in their code", since the process itself is working and highlighting that specific issue.
> you know full well the answer
If you are operating on the belief that only this particular report bears responsibility for "multiple rollbacks", then I think you do not "know full well the answer". You are ignoring the fact that other people had to let this poor quality code get into production in order to have rollbacks happen. You are also ignoring your own responsibility as a manager (as the sibling post to yours by cutemonster pointed out) to address issues like this before they result in multiple instances of a problem with production code (see my response to the sibling post I just mentioned).
We're not just talking about someone who has code quality issues. We're talking about someone who has code quality issues that have resulted in multiple rollbacks. Even if they weren't bright enough to spot that their code quality contributed on their own, they're going to hear about it from other people who had to get involved in the rollbacks.
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.
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.
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.
"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?
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.
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.
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.
To your point about being in the trenches I think maybe you’re extrapolating too much from that. Any manager who is any good is of course right there alongside their team in said trenches.
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?
If your words and tone sound nice, they can still be mean, doubly so.