Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mistakes as a new manager

terriblesoftware.org

Post reply on HN
Print view View original

131–140 of 157 posts

Re: Mistakes as a new manager

#131

Post by SkyPuncher »

sublinear wrote: post #66
localghost3000 wrote: post #9

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 re…

> “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 cont…

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.

Re: Mistakes as a new manager

#132

Post by to11mtm »

diatone wrote: post #83
sublinear wrote: post #66

Earlier quoted context omitted.

> “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 cont…

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…

Depends on the overall rapport.

"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.

Re: Mistakes as a new manager

#133

Post by pdonis »

quietbritishjim wrote: post #81
pdonis wrote: post #52

Earlier quoted context omitted.

> 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.

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 need…

> 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

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.

Re: Mistakes as a new manager

#134

Post by dilyevsky »

jimberlage wrote: post #95
the_clarence wrote: post #89

Reading the comments here just makes me feel like managers are useless. This role doesn't have to exist. It's just fluff.

I worked at a company that emulated Valve’s hyper-flat structure on their engineering team, with 1 manager having 50 direct reports. That’s as close to a management-less structure as I can think of, since your manager can’t attend meetings or do 1:1s anymore. It’s great at the beginning. We started with a team of mostly self-motivated people and the lack of upward review made technical decision-making easy. Eventuall…

I have an opposite experience in one of my last gigs where hired management batted 50% mishire rate where people just didn’t do anything at all or worse shipped something that needn't to even exist of quality so bad that the project had to be scrapped. This was allowed to drag on for years.

Last I heard he eventually got rid of most of them when the company fell on hard times and had to do a bunch of layoffs. By that point the damage was already done and most good people have left or quite quit.

Imo it’s a common misconception that management doesn’t know who low performers are. In most cases they know even if the team is large, they just choose to ignore it for whatever political reasons

Re: Mistakes as a new manager

#135

Post by SpicyLemonZest »

YZF wrote: post #130
diatone wrote: post #83

Earlier quoted context omitted.

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…

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 p…

I wouldn't say that there's unambiguously healthy conflict, but there's definitely such a thing as unhealthy conflict avoidance.

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.

Re: Mistakes as a new manager

#136

Post by YZF »

SpicyLemonZest wrote: post #135
YZF wrote: post #130

Earlier quoted context omitted.

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 p…

I wouldn't say that there's unambiguously healthy conflict, but there's definitely such a thing as unhealthy conflict avoidance. 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…

I would first ask myself whether this an honest mistake that anyone could make. If the answer is yes then there's really no need for any conflict. I don't think you have to get into a conflict to find out.

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.

Re: Mistakes as a new manager

#137

Post by resonious »

diatone wrote: post #86
resonious wrote: post #63

Earlier quoted context omitted.

I'm an IC on a team full of seniors with strong domain knowledge that recently hired in an EM from the outside. In short, it was pretty bumpy and despite the guy being an ex engineer, his constant questions about how the system works were a huge drag. Maybe to him he was digging deep but to me it felt like my (and my teammates') work was blocked by his inability to grasp simple concepts. Like the time spent explainin…

How long are these Q&A sessions, would you say the work of ICs getting blocked isn’t worth having the manager be able to eg: advocate for that work upwards?

We recently had an hour long session in the middle of the day with the entire team dedicated to explaining to the EM what exactly happened during a recent incident (a fairly sophisticated attack - not a simple bug, to be fair). Then next week another hour long session with the entire team AND a hefty handful of other people where EM regurgitated what we had explained to him. Fine I guess, except I'm pretty sure most people in that "retro" meeting already knew way more about what happened than EM did. So ~40 minutes explaining something to people who did not need an explanation.

Re: Mistakes as a new manager

#138

Post by paulddraper »

sublinear wrote: post #66
localghost3000 wrote: post #9

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 re…

> “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 cont…

Huh?

This is precisely the way to have that conversation.

Re: Mistakes as a new manager

#139

Post by cutemonster »

pdonis wrote: post #133
quietbritishjim wrote: post #81

Earlier quoted context omitted.

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 need…

> 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 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…

Meanwhile, deployments keep getting rolled back?

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.

Re: Mistakes as a new manager

#140

Post by cutemonster »

LanceH wrote: post #116
beryilma wrote: post #96

Earlier quoted context omitted.

> 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 y…

Articles aren't written for reports, or at least the advertising on those articles are directed at the managerial and above level.

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?

Post reply on HN