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

Engineering management lessons (2014)

defmacro.org

Post reply on HN
Print view View original

11–20 of 112 posts

Re: Engineering management lessons (2014)

#11

Post by samlittlewood »

alexchamberlain wrote: post #2

Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.

A recipe for disaster is for a manager's code to wind up on the critical path, then become a blocker - bad code & bad management.

A possibly better approach is for managers to have a few side proejcts, scouting out potential risk reducing things, at a higher temperature, away from the main project. Great if one of them lands - no added problems if not. Also, if they land in the project, they are no longer the responsibility of the manager.

Re: Engineering management lessons (2014)

#12

Post by mpweiher »

manojlds wrote: post #5
alexchamberlain wrote: post #2

Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.

Where does it tell to not code?

In fact: "You have to write code to remain an effective tiebreaker, but that’s where your coding responsibilities end."

Just not "Personally fix bugs and ship features."

Re: Engineering management lessons (2014)

#13

Post by jkovacs »

Question: It says at point 8:

> Don't supervise the quality and volume of people’s work.

And I agree with the argument following that sentence. On the other hand, 2 points above that it says:

> Do enforce behavioral and performance standards. Fire bullies and underperformers.

So how else do I recognize underperformers without taking note of quantity and quality of people's output? Surely I can't just take someone else's word for it (and by the point a peer complains about this it's probably too late already anyway?).

Re: Engineering management lessons (2014)

#14

Post by watwut »

endymi0n wrote: post #7
alexchamberlain wrote: post #2

Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.

There's an easy way to accomplish this: Commit yourself to 95% reading of code and 5% writing. Through great code reviews, spread your knowledge through the company and make others as good as you. Has the added benefit of making the stack more homogenous. (I still code review 50% of all commits relating to the data model - SQL & API interfaces myself) Then about the 5% - this is high prio, high visibility fixes where…

Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.

Re: Engineering management lessons (2014)

#15

Post by pjmlp »

alexchamberlain wrote: post #2

Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.

I have about 30 years coding experience, never had a manager that was still writing code after earning the position, other than a few Office macros.

It was never an issue to us and they were always respected by the team, except for the few ones that never should have been managers to start with.

Any manager that wants respect from the team needs to support them, specially against stupid decisions from upper layers. Have good social skills and specially important, how to raise morale in darker times.

Knowing to code is irrelevant.

Re: Engineering management lessons (2014)

#16

Post by joshuaswaney »

The emotional side of management goes so much deeper than what's covered by this list. Develop a vision and a strong sense of purpose in your engineers and they'll develop a mindset of building the future instead of maintaining the present. Foster a "we're all in this together" atmosphere and your engineers will develop a fanatical drive for success - either we all succeed or we all fail, it's not every man for himself.

The deep emotional drive is also what causes startups to succeed where big companies fail, despite their massive resources.

Re: Engineering management lessons (2014)

#17

Post by watwut »

alexchamberlain wrote: post #2

Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.

I had great managers who did not coded and had respect. They managed politics out of department, managed to find good trade off between autonomy and controll, made decisions where the team could not.

Re: Engineering management lessons (2014)

#18

Post by kochthesecond »

pjmlp wrote: post #15
alexchamberlain wrote: post #2

Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.

I have about 30 years coding experience, never had a manager that was still writing code after earning the position, other than a few Office macros. It was never an issue to us and they were always respected by the team, except for the few ones that never should have been managers to start with. Any manager that wants respect from the team needs to support them, specially against stupid decisions from upper layers. H…

I agree, having good social skills and being good at moving things forward (often in a political landscape) is more important than coding skills.

Re: Engineering management lessons (2014)

#19

Post by jasode »

This is a fine list and there's nothing too controversial that people would disagree with.

That said, I only counted 6 items out of 44 that's specifically "engineering" related. (5, 7, 10, 12, 14, 15)

The other 38 bullet points are universal lessons that also apply to non-engineering managers such as a director of a creative team in an ad agency, or project supervisor of a construction crew, or a showrunner in charge of scriptwriters for TV episodes, etc. Empower your team and make decisions when necessary, etc.

Re: Engineering management lessons (2014)

#20

Post by kochthesecond »

kayoone wrote: post #9
alexchamberlain wrote: post #2

Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.

Engineering managers that also code a lot usually fall short on the managing part, at least in my experience. Imo it's better if they focus on building a great team, guiding the team in the right direction by doing code reviews and making the hard decisions and be somewhat of a shield between the devs and other internal or external stake holders. Sounds boring, but provides more value as a whole imo. It's also why i…

I recently quit a job where I was in practice the tech lead. I did probably 60% code reviews, and made sure the architecture as a whole kept moving towards a coherent view and quality. But it was boring as I don't particularly enjoy teaching new developers basics of coding production ready systems every few months, especially when tied down as a consultant for a government organization. I ultimately had very little to say in what tech we could deploy. I therefore decided to go somewhere I might get more freedom to build quality with a bit less politics.
Post reply on HN