Live data from Hacker News

Engineering management lessons (2014)

defmacro.org

111–112 of 112 posts

Re: Engineering management lessons (2014)

#111
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 t…

Sad truth is that coding and problem solving and getting your hands dirty is low status work. I've had managers that new the application they were responsible for, and could speak coherently about technical things.

I've had managers who couldn't demo the apps that their team worked on.

Which one is better to work for as an engineer? The technically savvy one. Which one has higher stature and seems to be more highly regarded by his superiors? The non technical one.

In other words, that "lazy shitty manager" is probably playing the game better.

Re: Engineering management lessons (2014)

#112
post #72
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…

I always judge of the quality of a unfamiliar development team by the level of technical debt they agree to let into the codebase. Every team does that to some extent, but if one looks into all sorts of code frequently, at some point one works out a feeling for the "threshold" below which no-one should go.

It takes a good deal of ego to not cave to the pressure, and a growing ego feeds on accomplishments (ok, mostly ;-).

Post reply on HN