Live data from Hacker News

Mistakes as a new manager

terriblesoftware.org

71–80 of 157 posts

Re: Mistakes as a new manager

#71

Earlier quoted context omitted.

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…

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!

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.

Re: Mistakes as a new manager

#73
post #70

Earlier quoted context omitted.

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.

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.

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?

Re: Mistakes as a new manager

#74

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

[dead]

Re: Mistakes as a new manager

#75

Earlier quoted context omitted.

That's not what empathy means.

I’m meaning in the sense of ‘ruinous empathy’ https://www.radicalcandor.com/faq/what-is-ruinous-empathy/

Thank you for the link. I like saying "confront with compassion" for the upside of empathetic honesty.

Re: Mistakes as a new manager

#76
post #18

Delegation -> This is 1000% the hardest thing to do. You need to let go and trust your people. Where’s my dopamine? -> Your success is the teams' success. When they are doing well, you are doing well. Quality over quantity -> Yes. The level of engagement -> Your job is to support the team - blockers are your problem, not their problem. Fight to remove blockers. That's your job. Managing perception -> Which leads into…

Where’s my dopamine? -> Your success is the teams' success. When they are doing well, you are doing well. It's hard to get a dopamine hit of a second-order signal though. When you're a developer there's a strong linkage between the work you complete and results. If you write code for a new feature, you get to see it take shape on your screen. When your team reaches a milestone, you see where you contributed and can o…

[dead]

Re: Mistakes as a new manager

#77
The worst is having a manager who thinks he's great, but is actually disloyal and shit. Not sure how best to deal with that situation other than to ignore and eventually move on... If they'd be willing to admit their failing and improve, that would be awesome. Asking for a friend.

Re: Mistakes as a new manager

#79

Earlier quoted context omitted.

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

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?

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.

Re: Mistakes as a new manager

#80
As a (former) manager of a department in a design school, I defined three managerial imperatives:

1. Get rid of old, dead wood. Given that our program is scaffolded, with each course building upon the preceding, A single low performing lecturer can bring down the quality of an entire program. Don’t trust student feedback when identifying such people. They favour nice lecturers over effective ones. Getting rid of low performing team members in a university can be a low process. It can sometimes be quicker to find programs they would be happier/more productive in, and engineer a transfer.

2. Hire effective new blood. Well duh, I hear you say. Finding good new hires can be a difficult task. For those who I really wanted to hire, I did my research on who they were and what they might want, and tried to show them that I was willing to build a nest for them.

3. Have a vision of what the department should be. This vision requires constant maintenance and should always consider input from the team.

Post reply on HN