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

21–30 of 112 posts

Re: Engineering management lessons (2014)

#21

Post by freekh »

didibus wrote: post #8
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'd rather a manager who seems to care about me. Someone who is fair to the team, and shields us from the executive pressure. Someone that gives me challenging work which I could fail at, and recognises that I can fail and that it's ok if I do. Most of all, someone who dispays real appreciation for the value I add to the team. I honestly don't care if they code or not.

Second this a lot. In fact I am gonna steel exactly this and feed it back to my org

Re: Engineering management lessons (2014)

#22

Post by pweissbrod »

jkovacs wrote: post #13

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

Measure timeliness with respect to estimates. Measure the transparency in which they communicate the progress and focus of their work. Measure the clarity in their design and scoping. Measure what other developers say about their work in peer reviews. Measure how well their work runs in production, how many escalations and emergency bug fixes are needed?

Re: Engineering management lessons (2014)

#23

Post by user5994461 »

jkovacs wrote: post #13

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

It's never too late.

Re: Engineering management lessons (2014)

#24

Post by jeddf »

jkovacs wrote: post #13

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

Point 4 talks about knowing what everyone is working on, I think just from that a good manager with technical competency can discern underperfomers.

Re: Engineering management lessons (2014)

#25

Post by biztos »

Having just spent a couple weeks on a pretty hard engineering problem, after having done more "architecture" stuff for quite a while, I would definitely add one thing to the Do's:

* Protect your engineers' attention.

As a manager you are the primary firewall between the world of distraction and the world of getting shit done. Most places these days have institutionalized some amount of distraction -- the various recurring "ceremonies" -- but anything beyond that, it's essential that the manager can protect the engineers from being distracted when they're working on hard problems.

(I've been pretty lucky in this regard throughout my career, but now that part of my job is to live among the distractions it's really been driven home.)

Also:

> You’re the one who makes hiring and firing decisions. Everything that happens on your team is your responsibility.

This is, to put it gently, not quite true in larger organizations.

Re: Engineering management lessons (2014)

#27

Post by dom0 »

jkovacs wrote: post #13

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

If you require metrics to determine whether an employee is productive in a team, then that is a red flag (to me) that you need to communicate more. Talking to people is a far better way to find issues than looking at metrics.

I'm highly sceptical of managers that are focused on measuring metrics.

Re: Engineering management lessons (2014)

#28

Post by Avalyst »

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…

Programming is a skill just like management. I would argue that if you spend 5% writing and 95% reading you won't be maintaining that skill.

If you come from a strong technical background when first promoted (Being the go-to expert on the team or similar) then you can probably keep the respect of the team for a while but eventually others will rise to fill the gap (After all there is 95% of a rockstar programmer's time missing in the team). At that point your comments on code reviews will mostly be seen as micro management.

I would say that there are two ways to go about it, either fully trust your developers and let them develop and review their own code or stay as an active member of the team, doing as much coding as you can fit into your schedule. Which route you pick of course depends on the workload of managerial duties.

Re: Engineering management lessons (2014)

#29

Post by jt2190 »

biztos wrote: post #25

Having just spent a couple weeks on a pretty hard engineering problem, after having done more "architecture" stuff for quite a while, I would definitely add one thing to the Do's: * Protect your engineers' attention. As a manager you are the primary firewall between the world of distraction and the world of getting shit done. Most places these days have institutionalized some amount of distraction -- the various recu…

> Protect your engineers' attention.

Can you elaborate on "attention", and what does "protecting" it look like? (I've seen this reasoning used to keep developers out of requirements gathering, for example.)

Re: Engineering management lessons (2014)

#30

Post by afarrell »

pweissbrod wrote: post #22
jkovacs wrote: post #13

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

Measure timeliness with respect to estimates. Measure the transparency in which they communicate the progress and focus of their work. Measure the clarity in their design and scoping. Measure what other developers say about their work in peer reviews. Measure how well their work runs in production, how many escalations and emergency bug fixes are needed?

> Measure timeliness with respect to estimates

What if you have an employee who doesn't know how to do software estimation? Do you know of ways to teach people how to do estimates or resources/habits they can follow to learn how to estimate how long tasks will take?

I ask this as someone who has only received the advice "go with your gut and triple it." There is a book by Steve McConnell on estimating larger projects but nothing out there on estimating things within a week.

Post reply on HN