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

151–160 of 224 posts

Re: Common Mistakes of New Engineering Managers

#151

Post by gfodor »

Xylakant wrote: post #149
gfodor wrote: post #142

Earlier quoted context omitted.

If you work in an organization where such meetings are the norm, please share what led to such a magical place. I've heard Amazon is such a place but I'm very skeptical. My general presumption based upon years in the industry is that by far the majority of scheduled, large block meetings are not worth the opportunity cost of having them. Effective meetings don't come from an individual transforming normally ineffecti…

> My general presumption based upon years in the industry is that by far the majority of scheduled, large block meetings are not worth the opportunity cost of having them. I entirely agree with you here - I disagree with the notion that "managers" (should) like those meetings any more than other folks. Most large block meetings are ineffective, the more effective ones have a strict agenda and someone moderating them…

Point taken - I think to drill into my point more is that very few meetings are objectively "pointless" - and managers are much more likely to see a meeting as having "value" than the engineers, in part because of the effect I mention where their jobs are defined by meetings, not in spite of meetings. (Sometimes this is not the case, eg a manager may see the latent value of literally just having two people in the same room together and talk to one another who would otherwise not, for political purposes, that the engineers cannot understand.)

To cut it in the other direction, your average testing engineer will have a much harder time agreeing with the idea that most of your test suite is useless and should be thrown out, even if it is useless, because to do so would be to admit that their entire job is less credible as a concept if it is true.

Re: Common Mistakes of New Engineering Managers

#152

Post by bzzt »

cryptica wrote: post #42

I disagree about 'Still doing much technical work' being a problem. The author incorrectly infers that a manager writing code is going to take away developers' freedom. It's the opposite. The way I manage developers is I design the system into small projects with separate concerns and which can be easily integrated together. With the participation of the team, we discuss and iterate over the design of interfaces betw…

This is the winner right here, this is the manager who will get the most things done and deliver the most business value. This team would run in circles around a whole department of snowflakes. Focusing on being efficient at getting the actual job done, not wasting time on bullshit like figuring out how to have the perfect "one-on-one" to "make people happy". People on a team like this will be happy because they have a high level of purpose, craftmanship and impact.

Re: Common Mistakes of New Engineering Managers

#153

Post by Xylakant »

gfodor wrote: post #151
Xylakant wrote: post #149

Earlier quoted context omitted.

> My general presumption based upon years in the industry is that by far the majority of scheduled, large block meetings are not worth the opportunity cost of having them. I entirely agree with you here - I disagree with the notion that "managers" (should) like those meetings any more than other folks. Most large block meetings are ineffective, the more effective ones have a strict agenda and someone moderating them…

Point taken - I think to drill into my point more is that very few meetings are objectively "pointless" - and managers are much more likely to see a meeting as having "value" than the engineers, in part because of the effect I mention where their jobs are defined by meetings, not in spite of meetings. (Sometimes this is not the case, eg a manager may see the latent value of literally just having two people in the sam…

I disagree that a managers job is (or should be) defined by "meetings". A mangers job is to facilitate certain aspects of shared work, for example alignment on goals, ensuring availability of resources (financial, time, expertise, ...), recognizing and possibly removing obstacles. Meetings are one tool that can be put to use, but they are not an intrinsic goal. The same holds true for a good QA engineer - their goal is not writing a test suite. The same should hold true for a programmer - the code is not the goal. Removal of useless code is a good thing. However, there are people that fail in all of these professions - I've seen enough coders that write complex code for the love of complex code, DevOps folks self-managing kubernetes where a simple virtual machine would have been sufficient and managers hiring people just to increase the headcount of their department and increase their perceived standing.

Re: Common Mistakes of New Engineering Managers

#154

Post by samvher »

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

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

Do you have recommendations for how to go about 6?

I've been moving into a more manager-like role and your list makes me a bit worried, though I was already considering this to be somewhat temporary. So far it's been a valuable experience though (harder than I thought).

About 2 - I actually really enjoy relationship building. However, if you have issues like nepotism or problems around equity in the organization, I think it can be really hard to have to work with people who make decisions that you find distasteful. That's the main thing that makes me miss the solitude of coding.

Re: Common Mistakes of New Engineering Managers

#155

Post by gfodor »

Xylakant wrote: post #153
gfodor wrote: post #151

Earlier quoted context omitted.

Point taken - I think to drill into my point more is that very few meetings are objectively "pointless" - and managers are much more likely to see a meeting as having "value" than the engineers, in part because of the effect I mention where their jobs are defined by meetings, not in spite of meetings. (Sometimes this is not the case, eg a manager may see the latent value of literally just having two people in the sam…

I disagree that a managers job is (or should be) defined by "meetings". A mangers job is to facilitate certain aspects of shared work, for example alignment on goals, ensuring availability of resources (financial, time, expertise, ...), recognizing and possibly removing obstacles. Meetings are one tool that can be put to use, but they are not an intrinsic goal. The same holds true for a good QA engineer - their goal…

I don't think implying that QA engineers being biased in favor of having unnecessary automated tests is the same thing as saying that QA engineers have a goal of writing tests. It's just the nature of the beast. My point is jobs inherently favor artifacts or actions which (perhaps ceremoniously) justify their existence, and often resist attempts to remove such things since they've integrated those things as core to their job function (even if their motives and goals are in fact not to create those artifacts.)

Re: Common Mistakes of New Engineering Managers

#156

Post by durzagott »

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…

"Leaders aren't born, they're made" [1]

[1] https://coachingforleaders.com/

Re: Common Mistakes of New Engineering Managers

#157

Post by airhead969 »

Completely agree with these points.

It's absolutely unreasonable and unrealistic to be an engineering manager and a technical lead. Management is a full-time job consumed mostly by minutia and bureaucracy (mandatory meetings and paperwork) so that the team doesn't have to deal with it.

I'd add:

6. Defend the team, especially pushback unreasonable, untenable changes from on high.

7. Peter principle: title doesn't assure greater competency. Don't micromanage experts. Seek their knowledge, opinions, be curious, and ask questions.

8. Go-giver and mentor. Always help staff grow their careers, confidence, and capabilities, wherever that takes them.

9. Be helpful to the team and its individuals without being annoying. Replace that crap printer that wastes everyone's time. Fix that door that maintenance ignores. Whatever it takes. Go above and beyond, especially when it's crunch time.

Re: Common Mistakes of New Engineering Managers

#158

Post by alistairSH »

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.

Yup. And it's not limited to software/tech. The local police department has the same problem with patrol/beat officers - many of the good ones were promoting into desk jobs because their salaries capped out. IIRC, they ended up creating a new tier of patrol roles on top that corresponded, income-wise, with the first or second level management.

Re: Common Mistakes of New Engineering Managers

#159

Post by kingkongjaffa »

lentil wrote: post #32

I've been an engineering manager for a couple of years. I'm still expected to do 50% engineering and 50% people management. As the article describes, it is a struggle to do both well. I don't see this responsibility split changing in my current role. I do often wonder what it would be like to be 100% people focused, and whether or not I would miss engineering too much. When my role first changed, I was very intimidat…

This advice is the same as what is given in https://www.manager-tools.com/get-started

Their concept is based on the idea that the key activities of all managers should be primarily focused on one on ones, feedback, coaching, and delegation.

If you do all 4 well then you will be able to grow your direct reports career and help them to better align their output with their career goals and also what the business needs them to deliver.

Re: Common Mistakes of New Engineering Managers

#160

Post by kingkongjaffa »

nobodyandproud wrote: post #52
lentil wrote: post #32

I've been an engineering manager for a couple of years. I'm still expected to do 50% engineering and 50% people management. As the article describes, it is a struggle to do both well. I don't see this responsibility split changing in my current role. I do often wonder what it would be like to be 100% people focused, and whether or not I would miss engineering too much. When my role first changed, I was very intimidat…

I’m in the same boat. In the span of two years, my ability to even review code and spot simple mistakes has rotted (I’ve coded for many years; I was pretty good at it). Meanwhile my team size has doubled, and I’m left feeling I’ve bitten off more than I can chew. These days I feel I’ve made a mistake. Even one-on-ones feel rote.

The agenda for one on ones should be driven by each direct report!

If your meetings are stale ask them to start setting the agenda. The time is for them, let them take the lead.

As a basic format, try 15minutes for them , 15minutes for you

The time for them should be whatever they want.

The time for you should be about directing them to what they should do next, understanding if they have roadblocks, giving feedback, identifying opportunities for coaching, and thinking about their long term progression.

Post reply on HN