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

61–70 of 157 posts

Re: Mistakes as a new manager

#61

Post by choppaface »

roenxi wrote: post #21
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 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…

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

Re: Mistakes as a new manager

#62

Post by xandrius »

pdonis wrote: post #52
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 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.

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.

Re: Mistakes as a new manager

#63

Post by resonious »

brap wrote: post #20

I joined a new team as a manager and after 3 years was kindly asked to step down and become an IC. While there are many external factors to blame, I decided to do an honest postmortem with myself so I thought about these things a lot. As a line manager a huge mistake you could make (especially if you’re joining a new team) is not being technical enough. You may not write code anymore, but you are expected to know the…

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 explaining could've been spent just fixing the bug.

So I guess with the digging deep thing, be careful to not take up too much of people's time!

Re: Mistakes as a new manager

#64

Post by xandrius »

chasd00 wrote: post #7
TripleChecker wrote: post #5

Delegation was one I struggled with a lot in the early days. Even as the CEO, I was reluctant to give up my customer service responsibilities of manning the inboxes. Eventually, I understand that even if someone handled it only 80-90% as well, that would be much better for the company than having me do it.

Delegation is so hard, i struggle constantly and I'm technically a "Sr. Manager". When the project is up against deadline pressure, it's so tempting to do something yourself that only takes you a day vs delegating to someone else and they spin on it for 3 and screw it up at the end anyway. Inevitably you become the bottleneck when a wave of escalations or other management tasks come down the pipe but there's a pile o…

Sounds like there are some fundamental process/team issues going on. If a team cannot be trusted to deliver, superman always coming in to save the day shouldn't be the solution.

Re: Mistakes as a new manager

#65

Post by dyauspitr »

brap wrote: post #20

I joined a new team as a manager and after 3 years was kindly asked to step down and become an IC. While there are many external factors to blame, I decided to do an honest postmortem with myself so I thought about these things a lot. As a line manager a huge mistake you could make (especially if you’re joining a new team) is not being technical enough. You may not write code anymore, but you are expected to know the…

That’s the team leads job. The manager’s job is to manage the people. You are a babysitter or more akin to a teacher that has to stay out of the way of the kids doing things well and prevent the bad kids from ruining the class for everyone.

Re: Mistakes as a new manager

#66

Post by sublinear »

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

Re: Mistakes as a new manager

#67

Post by piterrro »

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…

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.

Re: Mistakes as a new manager

#69

Post by ad_hockey »

dowager_dan99 wrote: post #29
ryoshu wrote: 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…

Agreed. "Where's my dopamine" is the right way to describe it. As an IC I could find a bug, craft a test that reproduces it, write a fix, see the test go green, see the PR get approved and land... I'd get a little dopamine ping at each step. As a manager I'd have days where I had constructive 1:1s in the morning and maybe made a decision on some strategic or resourcing problem in an afternoon meeting. Of course I recognised that the work was not only valuable, but higher impact than just fixing a bug. But the direct hit in the pleasure receptors just wasn't there. I'd finish a day a like that and instead of feeling happy with my work, I'd just feel exhausted and not looking forward to the next day.

After a few years as a manager I switched back to the IC track. I sometimes wonder if my experience means I'm just hard-wired to be an IC, or if with more time and practice you can train yourself to get the dopamine feedback from management activities.

Re: Mistakes as a new manager

#70

Post by nrclark »

xandrius wrote: post #62
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.

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.

Post reply on HN