Live data from Hacker News

Mistakes as a new manager

terriblesoftware.org

151–157 of 157 posts

Re: Mistakes as a new manager

#151

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…

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.

Re: Mistakes as a new manager

#152
post #151

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

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.

Re: Mistakes as a new manager

#153

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…

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.

Re: Mistakes as a new manager

#155

Earlier quoted context omitted.

Sounds annoying. Maybe if he'd asked one person to explain instead of the whole team? How big is the team if I can ask? > AND a hefty handful of other people where EM regurgitated what we had explained to him. Is that him trying to show he's doing something useful? How many people does he manage btw?

The explanation party was maybe 4 or 5 people. The "retro" was 10+ people (almost 20 on calendar but I don't think everyone actually attended). > Is that him trying to show he's doing something useful? That is certainly what it looked like to me > How many people does he manage btw? About 10.

I wonder if, in this case, 10 is too few, and it'd been better with a technical person and manager at the same time? Maybe everyone manages themselves pretty well?

Tech Lead Manager maybe? But I'm guessing. https://www.developing.dev/p/tech-lead-manager-tlm-roles

Re: Mistakes as a new manager

#156

List is toi short. I’d add: Posture. Everyone wants to be the benevolent manager, especially if there is enough money for everyone, and especially in these times where collaboration and positive management are touted. But you have to keep a carrot and a leash on the employees. My first employees got a 33% raise the first year things were good. Long story short: None of them are here anymore and we’re still scrambling…

I have to admit I initially hired a few Papered Posers, and it was a mistake to pay them 2.4x higher than market rate to ensure the project would reach conclusion on schedule. The lessons we learned: 1. "Manage or be managed...": your first lesson is people will try to manipulate those in positions of authority regardless of competency. i.e. the idea of "goodwill" being the true core product can escape the irrational…

Hi,

I’m coming here a few days later and I would like to thank you for the feedback and reflection. My impression is there are two styles:

- Restless: Hire and fire as fast as possible until you work with the right people, be tough. Could be positive if you can spell out the rules of success very clearly, with 100% reliability.

- Patience: Hire and train until people fulfill your needs. Run the risk of charlatans. Sometimes even good people end up slacking off because they aren’t motivated by the trust and the absence of the carrot and the stick. But you have the satisfaction of caring about people’s wellbeing. Which they most probably abuse, and they’re probably not even happy in this situation.

It’s Christmas so I’m having hard times firing 2 non-performing people who may just happen to need more time to ramp up than I estimate. January’s coming up soon.

Re: Mistakes as a new manager

#157

Earlier quoted context omitted.

I have to admit I initially hired a few Papered Posers, and it was a mistake to pay them 2.4x higher than market rate to ensure the project would reach conclusion on schedule. The lessons we learned: 1. "Manage or be managed...": your first lesson is people will try to manipulate those in positions of authority regardless of competency. i.e. the idea of "goodwill" being the true core product can escape the irrational…

Hi, I’m coming here a few days later and I would like to thank you for the feedback and reflection. My impression is there are two styles: - Restless: Hire and fire as fast as possible until you work with the right people, be tough. Could be positive if you can spell out the rules of success very clearly, with 100% reliability. - Patience: Hire and train until people fulfill your needs. Run the risk of charlatans. So…

Indeed, often it is a tough call, but sometimes even the best talent cannot overcome the inertia of seniority. I have witnessed folks:

* deploy the wrong stack due to existing team skill issues, than the maintenance sinks time and resources away from the project

* hit unclear project goals leading to constant distractions, and entrenched policies dominate design back into garbage

* have informal testing in random situations developers never get to see

* break the testing repeatability loop, so bugs never get properly resolved

If one only has 2 staff left, than they are likely doing 8 jobs 8 times less efficient than one expects.

Best of luck =3

Post reply on HN