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

31–40 of 112 posts

Re: Engineering management lessons (2014)

#31

Post by zackbloom »

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…

I personally believe in taking ownership of everything that happens. Learning how to work with others, get decisions made the way you think they should, how to get more resources from the org when you need them, etc are all skills. If you take ownership of them, even if failing there is not really your 'fault', you have the most opportunity to improve and end up where you want. No excuses.

Re: Engineering management lessons (2014)

#32

Post by exelius »

It's pretty simple: engineers are professionals. Professionals make mistakes, but are most effective when allowed to own up to them without consequences and learn from them.

In a good software team, a single developer's "big mistake" gets fixed by the whole team. I guarantee nobody on that entire team will make that same mistake; nor will they hold anything against the offending developer unless there's a pattern.

But in short, empowerment is the most effective leadership style in this environment. It's not appropriate for all employees (specifically newer folks who need a bit more hand-holding at first) but for professional workers like engineers, it's really the only way to go -- especially if you have senior technical employees who have decades more experience than their manager.

Re: Engineering management lessons (2014)

#33

Post by ooqr »

dom0 wrote: post #27
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.

This would be a pretty nerve-wracking position for an employee. Sometimes it takes a long time to hunt down a single-line change to the code to fix a bug.

Re: Engineering management lessons (2014)

#34

Post by tootie »

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'm currently managing projects on tech stacks I have no experience with. It's definitely a handicap but I can still do 90% of my job pretty effectively. I just felt on my team more.

One big thing I've learned is the manager should never take on big pieces of development. The other demands on your time mean that every task will take longer and you'll end up being a bottleneck.

Re: Engineering management lessons (2014)

#35

Post by tootie »

I guess it varies by company, but my job is more about managing the team's exposure to outside forces. I work with product and client teams to make sure we're delivering the right solution and we're promising something achievable. That's at least half my job.

Re: Engineering management lessons (2014)

#36

Post by xborns »

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.

Actually I somewhat disagree with that. I think they should code to some extent, but it doesn't scale in my experience. I lean to say #7 is a good point.

If the manager is required to complete the feature their "free" time is't the same as an engineer - read meetings/discussions. I manage two teams and when I first became a manager my instinct was to take tickets along with the team. Yet my other responsibilities came in play and made it harder for me to finish tickets I assigned to myself and others on the team waited.

I still code review and partake in high level design and some scripts here or there etc. but not mainline code that another engineer will depend on to be completed by xyz date.

The goal of a manager is to ensure the work pipeline and project trajectory are on path with the company needs while still taking time to learn new tech and skill-sets of the team. Of course most importantly protecting their time from distractions.

To move from manager upwards, building a great team that trusts each other and follows and ensures the team standards is crucial. If I am required for every decision or code review, then I become the bottleneck. Empowering other people and trusting their judgement was one of the harder leanings growing from manager upward.

Re: Engineering management lessons (2014)

#37

Post by FLUX-YOU »

jt2190 wrote: post #29
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.)

>I've seen this reasoning used to keep developers out of requirements gathering, for example.

That can be fair reasoning if you already have difficult work to do and your customers are noisy, disorganized, or inexperienced with developing requirements (think NYC window-shopping for features on someone else's credit card).

Re: Engineering management lessons (2014)

#38

Post by ransom1538 »

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.

Couldn't agree more. Engineering managers that have removed themselves from the ability to contribute will also lose touch with: design, build systems, architecture, qa, etc. At that point they are just a bad PM.

When I was a vp eng. what helped me the most was having ONE feature that I owned. I was forced to use the build system, go through qa, fight with design. It was never something massive, or hindered other groups, but if someone on the team bitched: "this framework sucks because.." -- I was able to jump in.

Re: Engineering management lessons (2014)

#40

Post by Terretta »

afarrell wrote: post #30
pweissbrod wrote: post #22

Earlier quoted context omitted.

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…

You can only estimate what's known.

If the problem is in fact known, your estimate will be the time to pull in a library from GitHub. If it's not to pull in a library, you're into unknowns.

Asking to estimate may work in aggregate if your 'gut' is good at assessing the amount of unknown your devs' face (e.g., 2x as much unknown work - multiply estimate by 3), but not in the specific. The specific amount of unknowns in a given task are unknown.

To translate a requirement into code will take exactly as long as it takes to discover and bridge the unknowns. You can't do anything about that, other than (a) change the requirement, or (b) change how much is known by the developer.

Post reply on HN