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

Common Mistakes of New Engineering Managers

ochronus.online

Post reply on HN
Print view View original

201–210 of 224 posts

Re: Common Mistakes of New Engineering Managers

#201

Post by eecks »

yaml-ops-guy wrote: post #95
gfodor wrote: post #65

1. Become an engineering manager 2. Stop coding 3. Do well for a few years until you become out of touch 4. Watch your team stop respecting you on technical subjects because you’re behind the times and too rusty but don’t know it so look foolish and are ignored when you give suggestions, which radically undermines your relationships with them as well as your ability to lead 5. Watch as your role morphs from a manager…

2b) Start coding again because your superiors promote you to management but treat you like you’re still an IC and ask why you haven’t contributed any points to the latest sprint while actively shutting you out of the kinds of discussions and decisions an EM would be making in most other orgs—-while somehow simultaneously asking you to also be the bearer of frequently changing and poorly communicated business prioriti…

Can we start a support group?

Re: Common Mistakes of New Engineering Managers

#202

Post by Viliam1234 »

binarytox1n wrote: post #117
bzzt wrote: post #87

Earlier quoted context omitted.

I don't doubt that it's possible. Except from having these creepy "one-on-ones" and review meetings, I have no idea what the engineering manager is even doing all day, never seen any transparency around this. "attending meetings" is what they say, but what meetings and why, I have no idea. Nothing is delivered and nothing comes out of it, I really think it's a bullshit job. "Sets tone, handles career growth, shieldin…

One on one meetings are not "creepy" - they are a chance to have an open conversation about your goals; your concerns; and anything else that needs to be discussed about your career, the organization, etc. Do you know what the sales people in your organization do? What about the legal department? Procurement? HR? Your lack of knowledge is not evidence. "lol, do some coding instead"? And what should I code? How do you…

> One on one meetings are not "creepy"

Actually, who decides this, and how?

I mean, I understand why 1:1 are considered necessary, but I still get the creepy vibe. It's probably mostly my introversion speaking, but this is honestly how I feel about it.

> conversation about your goals; your concerns; and anything else that needs to be discussed about your career

What goals exactly? We do sprint planning every spring, plus all that backlog refinement and other stuff.

Long-term goals? Well, they don't change that often (that's what "long-term" means). Neither does my career. So having this kind of debate once or twice a year would be quite enough.

Re: Common Mistakes of New Engineering Managers

#203

Post by sanderjd »

ghaff wrote: post #181
sanderjd wrote: post #70

Earlier quoted context omitted.

I think this is about right, but one sticking point I've found is: what kind of employee is the project manager? Who do you hire, what is the career trajectory? There is a temptation to have them be a manager, because hey, manager is in the name! But having gotten over that, there is a version of the job that is essentially entry level work; what you describe of managing the tickets and all the stuff is just not very…

Project/program management is probably one type of position that almost has to lead to people management at some point. Basically operational roles that have project/program management (folks) among others reporting to them. In other words, having overall responsibility for projects of smaller or larger size.

Yep, agreed, which is once again why you get managers doing the project management; a lot of them cut their teeth there.

Re: Common Mistakes of New Engineering Managers

#204

Post by Aeolun »

yaml-ops-guy wrote: post #139
ImprovedSilence wrote: post #124

Earlier quoted context omitted.

I agree here to that this is the exact issue. I will also add though that I think there is another dimension as well. I think much perceived middle manager "incompetence" stems from middle management juggling direction/pressure/expectations from senior management, and the realities of the program and the engineers. The best managers are capable of managing expectations from above while keeping their team shielded fro…

How have you found success balancing these things? It’s been my experience that managers of the first group eventually become unintentional members of the second group, even despite their best efforts to maintain productivity of their subordinates with intentional prioritization and grooming exercises because the business wants that new feature yesterday, and not getting it means lost revenue, angry customers and neg…

> not getting it means lost revenue, angry customers and negative performance reviews

Staying in exactly the same place won’t affect revenue, customers or performance reviews at all. It’s when people work under the mistaken assumption that they have to increase at all costs that you have a problem.

Re: Common Mistakes of New Engineering Managers

#205

Post by Aeolun »

humanlion87 wrote: post #188
gfodor wrote: post #141

Earlier quoted context omitted.

Yeah I think this just shows the trade-offs. The path forward for your manager here is to grok they need to turn the dial, at least in their relationship with you. What I reject is the idea that the dial needs to be dialed all the way away from coding, especially permanently, or that doing so is not without immense costs. It certainly makes the job of a manager harder when you are forced to reckon with the fact that…

I agree with you that I don't want my manager to completely stop coding (especially if it is something they like a lot). I just want them to realize that there are higher priority items on their list of things to-do. And spend at least some amount of time figuring out how to help their reports grow. Also, this depends on the experience level of a manager's reports as well. If all of them are quite experienced and hav…

> And spend at least some amount of time figuring out how to help their reports grow.

I hear this an awful lot, but either as a manager or IC, I have no idea what it means.

From my perspective, if you leave me alone to do my thing and don’t interrupt me with random shit all the time, I’ll grow naturally. But the manager doesn’t have to be involved in this beyond shielding me from the bullshit, so I guess people are talking about something different.

Re: Common Mistakes of New Engineering Managers

#206

Post by Aeolun »

gopalv wrote: post #143
PragmaticPulp wrote: post #76

Earlier quoted context omitted.

> unless you happen to have been born with natural leadership skills (you probably haven’t) Leadership skills are important, but I disagree that leadership is something you’re either born with or not. Leadership can be taught, learned, and practiced. The real issue is that a lot of people who are pushed or drawn into management roles don’t actually like managing or leading. Some are pushed into management because the…

> Some are pushed into management because they’re the most competent IC on the team. So Plato's Republic describes how this comes about since ancient times, I wrote something a bit more detailed[1] about it. But here's the TL;DR - the punishment is that he who refuses to rule is liable to be ruled by one who is worse than himself. And the fear of this, induces the good to take office, not because they would, but beca…

This is definitely true for me. I cannot imagine wanting to inflict some of the managers I’ve had on the members of my team. Better me than the chance of someone worse (and I’m pretty bad, I just judge the chance of someone worse taking it up if I stop to be higher).

Re: Common Mistakes of New Engineering Managers

#207

Post by alistairSH »

iAmAPencilYo wrote: post #178
alistairSH wrote: post #61

Earlier quoted context omitted.

I just left a team that was structured similarly. It was a pleasure managing them. Team members were: - Manager (me), BA - managed backlog and some project management (actual title was principal dev, but she wanted a role change), 2x senior developers (both capable of architectural work), 2x developers, 2x test engineers, 0.5 Product manager (they report through their own branch of the org chart and cover several rel…

What does BA stand for? Thanks.

Business Analyst.

Re: Common Mistakes of New Engineering Managers

#208

Post by yaml-ops-guy »

eecks wrote: post #201
yaml-ops-guy wrote: post #95

Earlier quoted context omitted.

2b) Start coding again because your superiors promote you to management but treat you like you’re still an IC and ask why you haven’t contributed any points to the latest sprint while actively shutting you out of the kinds of discussions and decisions an EM would be making in most other orgs—-while somehow simultaneously asking you to also be the bearer of frequently changing and poorly communicated business prioriti…

Can we start a support group?

I’ll bring snacks

Re: Common Mistakes of New Engineering Managers

#209

Post by TheColorYellow »

sanderjd wrote: post #70
iandanforth wrote: post #53

I will disagree with one point. Neither eng managers nor tech leads should be doing project management. It is a unique skill and worth having someone explicitly in charge. They should own the structure of requirements docs, story breaktown, ticketing, jira processes, etc. While they may be somewhat technical they are more ensuring consistency and quality of process without burdening devs. The best team composition I…

I think this is about right, but one sticking point I've found is: what kind of employee is the project manager? Who do you hire, what is the career trajectory? There is a temptation to have them be a manager, because hey, manager is in the name! But having gotten over that, there is a version of the job that is essentially entry level work; what you describe of managing the tickets and all the stuff is just not very…

Agree with this point completely.

Ideally it seems as if you'd want someone with administrative capabilities and focus but with enough understanding of the tech and business side that they're able to understand context and conversation.

Problem is, although its easy to find administratively capable resources who you can pay a decent salary to retain, the minute you require them to understand broader context the incentive structure changes as this is inherently more work.

To me that is why Product Managers who's focus is a single product should also take over administrative tasks on that project. It gives them an opportunity for "field time" as stated by another poster as well.

Re: Common Mistakes of New Engineering Managers

#210

Post by binarytox1n »

Viliam1234 wrote: post #202
binarytox1n wrote: post #117

Earlier quoted context omitted.

One on one meetings are not "creepy" - they are a chance to have an open conversation about your goals; your concerns; and anything else that needs to be discussed about your career, the organization, etc. Do you know what the sales people in your organization do? What about the legal department? Procurement? HR? Your lack of knowledge is not evidence. "lol, do some coding instead"? And what should I code? How do you…

> One on one meetings are not "creepy" Actually, who decides this, and how? I mean, I understand why 1:1 are considered necessary, but I still get the creepy vibe. It's probably mostly my introversion speaking, but this is honestly how I feel about it. > conversation about your goals; your concerns; and anything else that needs to be discussed about your career What goals exactly? We do sprint planning every spring,…

The two people in the meeting decide it. I'm sure if either of them are creepy then you will end up with a creepy meeting. Otherwise it's just a professional meeting with an agenda and a desired outcome, like any other.

If you have no goals that's your failing, not the meeting's. If you lack the imagination to see where you want your career to go or the introspection to see where it's headed then, again, your fault - not the meeting.

Questions I get in my one on one's with people who care and are going places: -Why is the organization failing at x/y/z? How can I make that better? Is it worth fixing? -I am having trouble accomplishing e/f/g goal - I've hit q/r/s roadblock. What do you recommend I do about this? -I want your job, how can I change what I am doing to get me closer to what you do?

I also use them to get information I need from these people: -How is your team doing? Is anyone under/overvalued? -Are your commitments on track? -Is there anything I can do to make you or your team more effective?

I mostly have these meetings monthly. A month is long enough for things to change. 6 months is too long - too many things have changed, too many have been forgotten.

Post reply on HN