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

171–180 of 224 posts

Re: Common Mistakes of New Engineering Managers

#171

Post by airhead969 »

mattbk1 wrote: post #146
fatnoah wrote: post #85

Earlier quoted context omitted.

>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 they’re the most competent IC on the team I think this is spot-on. People, for whatever reason, view management as the next step of a career when it's actually a career change. Yes, it's in the same domain, but it's a totally different job. I've done th…

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.

Re: Common Mistakes of New Engineering Managers

#172

Post by ska »

ghaff wrote: post #91
alistairSH wrote: post #63

Earlier quoted context omitted.

Folks generally get bombarded to manager because there’s no career ladder That's a pretty serious organizational flaw. At my employer, we have a well-define architect path that ends with "Technical Fellow" which on the job matrix is parallel with director-level management. As a developer, I see 4 basic career tracks. Developer-track - caps out at principal developer, thought most people in this role are capable of ar…

>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 is some career track that makes sense for IC focused technical people to stay in throughout a normal career.

Re: Common Mistakes of New Engineering Managers

#173

Post by teddyh »

varjag wrote: post #25
SteveNuts wrote: post #24

Earlier quoted context omitted.

Can you give an example of what you mean by input from non stakeholders?

Depends on the org structure. In the one I was, architects were siloed off from the projects in a parallel sub-unit in the department, making it a bit of an ivory tower. They would issue design and scope decrees without facing any schedule pressures themselves. It took me a while to realize that most of my managing peers were quietly* ignoring them, delegating the actual decisions to the team. (*) As in, amend them t…

The Magician of the Ivory Tower brought his latest invention for the master programmer to examine. The magician wheeled a large black box into the master’s office while the master waited in silence.

“This is an integrated, distributed, general‐purpose workstation,” began the magician, “ergonomically designed with a proprietary operating system, sixth generation languages, and multiple state‐of‐the‐art user interfaces. It took my assistants several hundred man years to construct. Is it not amazing?”

The master raised his eyebrows slightly. “It is indeed amazing,” he said.

“Corporate Headquarters has commanded,” continued the magician, “that everyone use this workstation as a platform for new programs. Do you agree to this?”

“Certainly,” replied the master, “I will have it transported to the data center immediately!” And the magician returned to his tower, well pleased.

Several days later, a novice wandered into the office of the master programmer and said, “I cannot find the listing for my new program. Do you know where it might be?”

“Yes,” replied the master, “the listings are stacked on the platform in the data center.”

— The Tao of Programming, chapter 7.3 (Geoffrey James, 1987)

Re: Common Mistakes of New Engineering Managers

#174

Post by ip26 »

PragmaticPulp wrote: post #79
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…

Do you really enjoy having 3 different managers to report to? All of whom have 3 different projects they’re dealing with? IMO, it’s better to have a 1:1 ratio of managers to teams. A 3:3 ratio is a recipe for endless meetings and communication overhead. 1:1 and 3:3 have the same number of employees, but 1:1 eliminates all of the communication overhead because there’s only 1 manager per team instead of 3. In my experi…

I don't think the IC's have 3 managers in this arrangement. The product manager & engineering manager work together in a customer-provider relationship, while the project manager acts as a sort of facilitator and metrics collector, & doesn't hold direct authority over the IC's.

Re: Common Mistakes of New Engineering Managers

#175

Post by gen220 »

halfmatthalfcat wrote: post #66
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…

Can I just throw in a wrinkle, I'm what could be described (from this list) as an Engineering Manager and Tech Lead. I architect and implement solutions while also doing all the traditional managerial duties. I feel like I've been eaten alive lately on HN that this arrangement isn't possible and you cannot do both well, but I beg to differ.

Sometimes the interests of the TL contradict the interests of the EM. Circumstances like those are usually brought on by strong budget or roadmap constraints.

Usually, people in your position will systematically wear one hat at the expense of the other, leading to long-term retention or code quality problems.

It's a delicate balancing act, that isn't easy for most people to pull off. It's not impossible, I've seen it done well. But it's a lot easier when "times are good", and you are not consistently tested by hard decisions where the EM and TL hats would disagree.

Re: Common Mistakes of New Engineering Managers

#176

Post by holoduke »

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…

Too pessimistic. Many ways of having a successful and happy live. You can teach, mentor or become an advisor. You can also start your own company. Or you can find something entirely different in a different industry. Going up career wise isn't the goal you should pursuit

Re: Common Mistakes of New Engineering Managers

#177

Post by gfodor »

airhead969 wrote: post #169
gfodor wrote: post #129

Earlier quoted context omitted.

I don't agree with this. I enjoy management and coding. However, when I'm in a manager role, I consider contributing with coding to be an essential part of the job, to maintain my ability to lead the team with credibility, truly understand what their job is like, and differentiate myself relative to other managers, who by and large have bought into the narrative they can't and shouldn't try to code. This cuts directl…

A lot of technical leads who become managers assume they're doing a good enough job on the management side and that they have to master every technical detail, when the truth is they're only convincing themselves that their split allegiances, attention, and priorities aren't a problem of trying to work two jobs. An engineering manager who was technical, listens to their staff, and delegates can still be respectable a…

You've clearly stated an opinion, but not an argument. You've also smuggled in the claim that an engineering manager who ships stuff is performing two jobs. I argue that engineering managers who cannot ship stuff are performing half a job. (I don't really, but you can see why this is a fallacy in both directions: it's an argument around definitions.)

Your opinion is the same on made in the article and is the consensus view. To me, the consensus view is there for a lot of reasons, one of which is that it's a common anti-pattern for formerly technical engineers to become managers and let themselves get drawn into the code at the cost of management. In all things, balance. The other, more general anti-pattern is to see a failure mode and then presume the diametrically opposed opposite is the global optimum. If engineers are prone to be bad at management because they get sucked into building stuff, then whatever benefits may come from that should to be ignored: they should abandon it altogether. (This is a common error in other domains, like the canards "ideas are nothing execution is everything", "you should never pick stocks, and only invest in index funds", etc.)

It also turns out it's much easier to believe that engineering managers who ship code are worse managers, because it means that you can feel good about deciding you're going to stop coding: you're doing it to do your job better. You already have so little time anyway. But what if it turns out being able to ship stuff actually helps you in being a manager? Now it's harder: you have to decide where to draw the line. And so, it's a much more difficult thing to come to terms with since it means there are no easy choices and you actually have to live with the fact you are always going to suck at this in one way or another.

I argue that, all other things being equal, having the ability to ship with the team makes you a better manager. The question is if that is true or not, and if so, at what point does the trade-off stop making sense to maintain that ability. Creating false hypothetical situations like "setting up an arbitrary HA database" doesn't prove much of anything about the actual, local, domain knowledge I'm referring to that you get by continuing to perform IC-like work alongside the team you manage.

Re: Common Mistakes of New Engineering Managers

#178

Post by iAmAPencilYo »

alistairSH wrote: post #61
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 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.

Re: Common Mistakes of New Engineering Managers

#179

Post by airhead969 »

gfodor wrote: post #177
airhead969 wrote: post #169

Earlier quoted context omitted.

A lot of technical leads who become managers assume they're doing a good enough job on the management side and that they have to master every technical detail, when the truth is they're only convincing themselves that their split allegiances, attention, and priorities aren't a problem of trying to work two jobs. An engineering manager who was technical, listens to their staff, and delegates can still be respectable a…

You've clearly stated an opinion, but not an argument. You've also smuggled in the claim that an engineering manager who ships stuff is performing two jobs. I argue that engineering managers who cannot ship stuff are performing half a job. (I don't really, but you can see why this is a fallacy in both directions: it's an argument around definitions.) Your opinion is the same on made in the article and is the consensu…

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.

Re: Common Mistakes of New Engineering Managers

#180

Post by gfodor »

airhead969 wrote: post #179
gfodor wrote: post #177

Earlier quoted context omitted.

You've clearly stated an opinion, but not an argument. You've also smuggled in the claim that an engineering manager who ships stuff is performing two jobs. I argue that engineering managers who cannot ship stuff are performing half a job. (I don't really, but you can see why this is a fallacy in both directions: it's an argument around definitions.) Your opinion is the same on made in the article and is the consensu…

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 consider an engineering manager's responsibilities will be to maintain the velocity, mental health, and general happiness of their reports. People who argue about the role a person has and what they ought to focus on based upon their designated title, or in this case derive it in the opposite direction, to me, are mistaking the map for the territory.

Also, if you think I'm writing this to defend my ego, you ought to become a psychologist since you are able to read minds over the internet.

Post reply on HN