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

71–80 of 112 posts

Re: Engineering management lessons (2014)

#71

Post by sleazebreeze »

ooqr wrote: post #33
dom0 wrote: post #27

Earlier quoted context omitted.

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.

I believe it's the responsibility of the person hunting down that one-line change to communicate to their team what was involved with tracking that down. Everyone can learn from a single person's deep dive. An engineer shouldn't feel like they're doing something risky for their career by carefully working through a hard problem with unimpressive code results.

If the engineer can't convey why it took a week to find that one-line, they should work on their communication skills. A good manager can help set expectations for an engineer who has underdeveloped soft skills.

I just spent a week and a half tracking down a bizarre issue in a 3rd party library and filed a fix for it. It was simultaneously frustrating and fascinating, but I never once was worried that the team didn't support my effort because I kept the team in the loop during daily standups. I've also been lucky to have excellent managers who believe in letting the engineers work.

Re: Engineering management lessons (2014)

#72

Post by tensor »

theprop wrote: post #53

The single most important thing in engineering management is hiring only the best. The best have two key characteristics: strong technical skills primarily in aptitude but also in technical knowledge, and a great ego-less attitude. It's at least as important to test for ego than for technical skills. Most of our "engineering disasters" were related to lowering our bar for hiring. Some "engineering disasters", though,…

Everyone claims to "hire only the best." It's not a very meaningful statement and certainly doesn't help inform actions when it's what everyone tries to do already. Digging in more deeply, what does "best" even mean? The best among those already hired? The best among a pool of applicants? The best among companies in your domain? Among all domains?

At any organization there will be people of various skill levels. Does hiring the best mean you never hire juniors? It is the best at any given experience level? It might even be hard to compare some people. E.g. what if you have two people, both excellent, but excellent at slightly different things?

Rather than saying "hire only the best" I would perhaps instead suggest that you hire people who fit your culture and compliment your existing teams. A team that works well together, doesn't fight, doesn't get distracted, and is happy, is going to be efficient.

Or, another way to look at it is to consider the "Secretary Problem" [1]. When do you decide to hire someone considering that you can get a stream n people applying over time? You don't want to wait until the last person since n can be large and you need people now not in a year. The solution is to not hire the first n/e people, then pick the first person who you deem to be "the best" compared to the first 1/e people.

Hiring is complicated!

1. https://en.wikipedia.org/wiki/Secretary_problem

Re: Engineering management lessons (2014)

#73

Post by specialist »

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.)

Sometimes literally.

We had a "visionary VP" who'd visit the devs personally. I placed my desk at the entrance to our area, so that I could catch and block him (and others).

We had a basket of shiny toys (eg books about XP) to keep this VP amused, satisfied that we were sufficiently forward thinking enough.

For my part, I've always moved my devs closer to the customers, bypassing the internal hierarchy. More signal, less noise.

Re: Engineering management lessons (2014)

#74

Post by dismantlethesun »

Spooky23 wrote: post #70
sanderjd wrote: post #48

Earlier quoted context omitted.

It sounds like you've run into some bad apples, likely due to "promoted too early" syndrome, which is unfortunately pretty common. In my experience, code review by senior engineers is extremely valuable whether or not they're currently writing much code.

That's why coding managers is dumb. The army figured it out. The Officers are in charge, but the sergeants get shit done. In engineering, your leads/supervisors are the sergeants. Officer quality varies between complete shitbird and Julius Ceasar. Either way, the army marches.

Sound like tech leads are sergeants and project managers are officers.

Re: Engineering management lessons (2014)

#75

Post by [deleted] »

specialist wrote: post #73
jt2190 wrote: post #29

Earlier quoted context omitted.

> 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.)

Sometimes literally. We had a "visionary VP" who'd visit the devs personally. I placed my desk at the entrance to our area, so that I could catch and block him (and others). We had a basket of shiny toys (eg books about XP) to keep this VP amused, satisfied that we were sufficiently forward thinking enough. For my part, I've always moved my devs closer to the customers, bypassing the internal hierarchy. More signal,…

[deleted]

Re: Engineering management lessons (2014)

#76

Post by ransom1538 »

theprop wrote: post #53

The single most important thing in engineering management is hiring only the best. The best have two key characteristics: strong technical skills primarily in aptitude but also in technical knowledge, and a great ego-less attitude. It's at least as important to test for ego than for technical skills. Most of our "engineering disasters" were related to lowering our bar for hiring. Some "engineering disasters", though,…

Ah yes: "hire only the best". Like in baseball, just hit 500+. Or Mike Tyson explaining: "you just need to knock everyone else out". Tony Hawk: "You need to stick every move."

You want to make it to the superbowl? Well that is easy just have the right team.

Great advice.

Re: Engineering management lessons (2014)

#77

Post by Spooky23 »

dismantlethesun wrote: post #74
Spooky23 wrote: post #70

Earlier quoted context omitted.

That's why coding managers is dumb. The army figured it out. The Officers are in charge, but the sergeants get shit done. In engineering, your leads/supervisors are the sergeants. Officer quality varies between complete shitbird and Julius Ceasar. Either way, the army marches.

Sound like tech leads are sergeants and project managers are officers.

That's where the analogy breaks a bit. Where I work, PMs don't "own" people, just deliverables.

Their main weapon is pestering you.

Re: Engineering management lessons (2014)

#79

Post by khazhoux »

kator wrote: post #65

I always say management is they easiest job because you only have four things to do, and I'm sure your team has more than that to do: 1) Provide Air Cover 2) Provide resources 3) Provide direction 4) Get the F * out of the way Don't over think it. Empower your teams, trust them. They'll make mistakes just like you do. It's not how bad you F* Up it's how well you recover. Originality in mistakes is the best I can ask…

Wow, that sounds like a lazy shitty manager.

Every engineering team has problems they can't deal with on their own, either because it's out of scope, it's high-level organization, or whatever. A GOOD manager spends a significant chunk of their week ACTIVELY fixing problems. Not getting-the-fuck-out-of-the-way!! They should help clear the way. They should help fill gaps in the team, plan, or execution. Talk to other teams and see if everyone's on the same page. Make sure everyone agrees on priorities. Make sure your team's work integrates with what everyone else is doing. Be aware of everything going on around you (esp with other orgs, etc) so you know how it all fits together and your team doesn't waste time.

Don't just listen and nod during 1:1s and then give some off-the-cuff suggestions. Don't just "get out of the way". And you don't need nearly that much Air Cover when you're team is aligned with the rest of the company, so make sure THAT happens instead of trying to "protect" the folks that happen to report to you.

If a great team's manager can't point to what they ACTIVELY DID to get the team to success, they're disposable.

Re: Engineering management lessons (2014)

#80

Post by mbesto »

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.)

Context switching. Or in other words the exact opposite of Flow.

I've seen so many companies regularly invite engineers into meetings or have multiple disruptions throughout the day.

Post reply on HN