Live data from Hacker News

Common Mistakes of New Engineering Managers

ochronus.online

181–190 of 224 posts

Re: Common Mistakes of New Engineering Managers

#181

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…

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.

Re: Common Mistakes of New Engineering Managers

#182

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…

It's impossible to overstate how much I agree with the need for a separate project management role. Project management is the biggest distraction I have from the "things only I can do" and the biggest morale and time suck. I don't have advice to give because I haven't solved my lack-of-project-management problem, but I sincerely believe I could be much more effective if this was off my plate.

As things grow, you really have to move from ad hoc processes/tracking/etc. to something more systematic that someone needs to own.

Re: Common Mistakes of New Engineering Managers

#183

Earlier quoted context omitted.

Those are the same problems. Managers flailing when there is too much work and not enough time means that there is not enough management capacity. Not often called out because the short term effects of managers not existing are minimal, where as without engineers work stops. Long term without managers work continues but the value tends toward zero.

Frankly, personal anecdotes disagree. I don't need managers breathing down my neck because they aren't capable of resolving the issue, and end up overcommunicating with the customers, reinforcing behavior in customers to continuously ask for information instead of realizing the harm they are doing. "Two days" means "two days", no matter how many times you ask for a progress update or try to push it to one day. Qualit…

This is, in my opinion and experience, the main gist of the problem. Management work doesn't take full time and people get bored or scared they can lose their jobs if someone finds they didn't do much. So you end up with a lot of synch meetings, one-on-one's, backlog refinement meetings, weekly reviews etc.

And now most of the managers have a calendar full of meetings to coordinate projects with other managers that after that they meet with their teams to get feedback/answers they need to go back to the project meeting and tell other managers that tell their teams... If they were not managers but developers or engineers with technical knowledge, they would save a ton of time (and team's time) and solve most of the issues in a couple of sessions.

But most managers will disagree because they cannot see how the "difficult technical problems they helped solving" were not so complex in the first place... when you put together the people who knows about the code/projects/systems.

Re: Common Mistakes of New Engineering Managers

#184
post #136

Earlier quoted context omitted.

Don't sell yourself out for money unless you need to. Figure out the amount of money you would like to make then if your at not getting paid that at CurrentCo go find a darling SV company, unicorn, or a FAANG+Microsoft and switch to an IC role at one of those companies and get paid better. Going into management for money is a terrible reason to become a manager... Unless of course your goal is executive management...…

You're sort of arguing though that, if you don't want to go into management, you should become an extraordinary IC (or just accept you'll get paid less money).

But that's true almost everywhere unless you become a consultant/freelancer (but then you are now running a business and have to find customers)

Re: Common Mistakes of New Engineering Managers

#185

Earlier quoted context omitted.

I was pushed into it because they needed a supervisor in that position. I might be a decent leader from a technical standpoint, but not a good manager after a year into it.

Yep. It doesn't scale well. Technical lead != technical manager. It's also myopic because it's two jobs and two completely different professions.

What is a technical manager?

Re: Common Mistakes of New Engineering Managers

#186
post #180

Earlier quoted context omitted.

Sandbagging. Also an opinion. You're being inconsistent and defending your ego rather than being open to the bigger picture. Then you're a technical lead and a technical manager; don't conflate the two as the only possible configuration.

I replied elsewhere a longer form argument, in the form of concrete examples, why I feel being able to ship code confers benefits to engineering managers. I'm not going to argue about titles. Titles are useful for internal political signalling and are basically minimally-transferable cultural norms, but less useful for determining how to best take care of your responsibilities. For the purposes of this discussion I c…

Then why are you writing? Why are you unable to interact without respect and curiosity but with adversarial hostility? Are you going to escalate to name-calling since you don't have an argument, only rationalizations to reinforce your worldview or the inability to consider approaches outside of your own? Maybe curiosity and self-reflection would help improve the quality of your conversations rather than promoting a religious doctrine through snide defensiveness.

Re: Common Mistakes of New Engineering Managers

#187
post #136

Earlier quoted context omitted.

You're sort of arguing though that, if you don't want to go into management, you should become an extraordinary IC (or just accept you'll get paid less money).

But that's true almost everywhere unless you become a consultant/freelancer (but then you are now running a business and have to find customers)

Sure. Absolutely nothing specific to tech. In fact, many big tech companies have a much better IC career ladder, mostly but not entirely for engineers/devs, than non-tech companies do. Sales is the main exception I can think of.

Re: Common Mistakes of New Engineering Managers

#188
post #141

Earlier quoted context omitted.

I would like to add my perspective as an IC who is reporting to a technically-focused manager. I feel frustrated that my manager does not spend even 10% of the time they spend coding on coaching/guiding/giving feedback to me. I feel that part is more important aspect of being a manager compared to churning out code. I understand the need to keep on top of the codebase, especially when coding is something you really l…

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 have clear goals regarding their career, the manager does not have to spend much time on career coaching. They can focus most of their time on coding. But if that is not the case, then they'll have to balance their time accordingly.

That's a good point you make regarding intentional vs unintentional. This point had not occurred to me earlier. After thinking about it though, I am confident that its not applicable for my scenario :0. I will have this in mind for future situations so that I don't come to wrong conclusions.

Re: Common Mistakes of New Engineering Managers

#189
post #172
post #91

Earlier quoted context omitted.

>That's a pretty serious organizational flaw. I agree that "no career ladder" is a serious flaw. That said, it's not uncommon that, in terms of money anyway, IC tracks tend to cap out at lower levels than management tracks even if there is a well-defined IC track.

> t's not uncommon that, in terms of money anyway, IC tracks tend to cap out at lower levels than management This is pretty natural, at least in a big organization. At some point your IC tracks almost always have less impact. There are weird corner cases sure, but not enough that you can't deal with individually. But that's ok; Almost every manager isn't going to eventually be C-level either. What's important is that…

There are weird corner cases sure, but not enough that you can't deal with individually.

I think that's where a lot of organizations fail. Take the "Technical Fellow" I mentioned earlier. This is the "weird corner case" - a technical IC who is capable of contributing strategically but has no interest in management.

The people in this role generally have ~20 years in industry and most have advanced degrees. They're some of the smartest people I know. They have the people skills to manage, but little interest (or rather, prefer to stay purely technical). Without the technical fellow role, they would have likely moved into management after 10-15 years and moved into director positions, at a loss to the company. Or, they'd dead end as senior devs at a lower salary and not have a voice with senior management.

My employer has 3500 employees (across all BUs). There are fewer than 10 technical fellows.

Re: Common Mistakes of New Engineering Managers

#190

Earlier quoted context omitted.

I would like to add my perspective as an IC who is reporting to a technically-focused manager. I feel frustrated that my manager does not spend even 10% of the time they spend coding on coaching/guiding/giving feedback to me. I feel that part is more important aspect of being a manager compared to churning out code. I understand the need to keep on top of the codebase, especially when coding is something you really l…

Technical leads should be helping ICs. It doesn't always have to be the manager in particular.

I think it depends on how each org or company defines its team structure and the responsibilities of the different roles. We don't have a separate tech lead role in our team.

Even so, wouldn't a tech lead be focused only on technical aspects. Say if I want feedback on some customer interaction I had or maybe regarding a meeting I ran, it is not the role of the tech lead to do so I think.

Post reply on HN