Engineering management lessons (2014) • Hacker News Board

Re: Engineering management lessons (2014)

#61

Post by Spooky23 » Sat, May 20, 2017, 5:04 PM UTC

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

In the Google SRE book, they have a concept of "toil".

If your engineers and builders are focused on the crisis of the moment, they aren't building.

Fundamentally, people don't do multiple different types of tasks well at the same time. Let the builders build, and the operators operate.

Re: Engineering management lessons (2014)

#62

Post by imajoo » Sat, May 20, 2017, 5:08 PM UTC

elliotec wrote: post #56

jalayir wrote: post #55

Earlier quoted context omitted.

> lowering our bar for hiring Let me guess, Amazon?

Why would that be your guess?

Amazon has a thing about "bar raisers" across the organization.

Re: Engineering management lessons (2014)

#63

Post by humanrebar » Sat, May 20, 2017, 5:17 PM UTC

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

> The single most important thing in engineering management is hiring only the best.

I agree.

It's easier said than done, though. Many engineering managers aren't really involved in the code in any real way. I can't imagine running a restaurant and not inspecting the kitchen, seeing hosts greet patrons, seeing how well tables stay cleared of dirty dishes, and so on.

I find that a lot of "hire the best" ends up boiling down to knowing which engineers are popular with "technical" folks and haven't obviously messed up (at least to someone who hasn't really looked at code or deployments). I'm not sure how to keep this from coming down, again, to politics and popularity.

Re: Engineering management lessons (2014)

#64

Post by pacaro » Sat, May 20, 2017, 5:24 PM UTC

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

Not everyone can hire the best.

Everywhere I've worked in the last 15 years has aimed to hire the best, none have succeeded.

A "hiring the best" motivation can easily become anti-diverse, because it plays on people's biases about what constitutes "the best", it can also foster a culture of arrogance

Do we ever think about hiring good enough for the tasks at hand?

Re: Engineering management lessons (2014)

#65

Post by kator » Sat, May 20, 2017, 5:26 PM UTC

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 for. Let's learn, progress and do better together.

I've been in tech for 35 years, if you think you've seen it all, you haven't and neither have I, so let's figure it out together and get some S*t done.

Re: Engineering management lessons (2014)

#66

Post by kator » Sat, May 20, 2017, 5:28 PM UTC

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

I hire for attitude and aptitude.

If you have a great attitude and you're able to learn then you will be amazing on my team.

It's impossible to say "hiring only the best". Because where are these "only the best" people? I've been smashing keyboards for 35 years, does that make me "only the best". Nope.

What makes an amazing team is the ability to learn, adapt and solve real world problems at scale together.

Not "only the best".

Re: Engineering management lessons (2014)

#67

Post by pacaro » Sat, May 20, 2017, 5:31 PM UTC

Did I miss something? I see nothing on this list that touches on mentoring or growing. I do see a line about firing underperformers. I've heard a metric that it costs between 2.5-5 time annual salary to replace someone. Sometimes an under performer is just in the wrong role, or on the wrong team; when this is the case they probably know it. Ask them!

Re: Engineering management lessons (2014)

#68

Post by douche » Sat, May 20, 2017, 5:33 PM UTC

pacaro wrote: post #64

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

Not everyone can hire the best. Everywhere I've worked in the last 15 years has aimed to hire the best, none have succeeded. A "hiring the best" motivation can easily become anti-diverse, because it plays on people's biases about what constitutes "the best", it can also foster a culture of arrogance Do we ever think about hiring good enough for the tasks at hand?

The converse is "hiring tecent college grads" who don't have a ducking clue, and needing to train them for a year or two. Sucking up the time of your preexisting ICs, and rendering them useless

Re: Engineering management lessons (2014)

#69

Post by tetrep » Sat, May 20, 2017, 5:35 PM UTC

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…

I think a lot of the difficulty of management is not in the description of you duties, but rather the difficulty in finding the "right" thing to do, which is very difficult when it comes to soft skills, which almost always lack any quantitative way to measure directly, and must be inferred from secondary and indirect metrics.

Re: Engineering management lessons (2014)

#70

Post by Spooky23 » Sat, May 20, 2017, 5:35 PM UTC

sanderjd wrote: post #48

watwut wrote: post #14

Earlier quoted context omitted.

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.

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.