Engineering management lessons (2014) • Hacker News Board

Re: Engineering management lessons (2014)

#101

Post by pweissbrod » Sun, May 21, 2017, 2:23 AM UTC

afarrell wrote: post #98

pweissbrod wrote: post #89

Earlier quoted context omitted.

I hear you. Estimation is a skill just like coding or documenting or management. Some people have a better knack for it than others. But it is an important skill and a part of being a professional engineer. My rule of thumb is that if you cannot estimate your work to some degree of confidence up front then you haven't spent enough due diligence time and the design before writing code. If your task is too complex to e…

> just like coding or documentation But, you can look at a piece of code and go "no that doesn't make sense. Lets try this instead" and both reason about its quality or run tests on it. You can have nuanced discussions of what makes a piece of code more clear or a tutorial code example more easy to interpret. It seems like no such nuance is available. I share your opinion that it is unreasonable for me to expect to b…

I've been there. I appreciate what youre saying. You sound like an honest logical person. Id love to help you if i can.

For 10 years I was a small gig consultant 5 of which I worked solo. Fixed price contracts. Clients with tight budget. Projects with high technical variety.

People like us our product is our time. Getting things done on time/budget (or not) sometimes yield a significant impact on our reputation. Thats pressure especially when youre working with so many variables!

Everybody in this line of work goes through this on some level. Based in my downvotes above i assume many folks dont like the idea of trying to estimate to high accuracy. Thats their take. Everyone has their own opinion. Heres mine:

Itemize out the work into logical work items. For each item fix the estimate and the level of confidence on your estimate. If the level of confidence is below say 80% then state the unknowns and add estimate an optimistic/pessimistic range for the item instead of a single number.

After going through this exercise bring this to the client. In all my years doing this ive never had a client who didnt appreciate a thoughtful breakdown of the work and it became easy for all parties to appreciate what areas of the project had the greatest unknowns and why. Also the client can either accept the estimate based on the pessimistic high end of the range or we find a cheaper alternative or i scope a proof of concept. Either way the choices are clear to everyone even if the estimates arent entirely clear.

Sorry for the long-winded explanation and thank you for reading. I would summarize by saying an estimation is just that. it is not accurate but the unknowns are clear and the work is carefully considered before beginning in earnest.

Best of luck to you and don't give up

Re: Engineering management lessons (2014)

#102

Post by mncharity » Sun, May 21, 2017, 4:48 AM UTC

NortySpock wrote: post #45

valuearb wrote: post #44

Earlier quoted context omitted.

Why did you code it that way? How hard is it to answer that question?

"It will cause performance problems if you don't" , with only a gut feeling to back it up, and no actual testing. I just ran into this response yesterday, and I ended up going over his head (unfortunately) and asked our DBAs for a recommendation. DBA solution worked faster than either of the previous two solutions. I still need to apologise for that one.

> I still need to apologise for that one.

Curious. Running an idea by people to get their thoughts, because it's currently leaving you short on warm fuzzies... is something to apologize for?

The initial solution was low on warm fuzzies for him. Your second solution was low on warm fuzzies for you. So you explored further. Where's the problem?

Re: Engineering management lessons (2014)

#103

Post by drieddust » Sun, May 21, 2017, 7:04 AM UTC

FLUX-YOU wrote: post #37

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

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

Correct, butttt "Customer is king."

On a serious note, I have seen more projects ending into dumpster because we listened to customer too well and didn't actually infer the meaning which lies between the lines.

Most managers I have encountered are just messenger pigeons. Sometimes I wonder how system still works!

Re: Engineering management lessons (2014)

#104

Post by theprop » Sun, May 21, 2017, 7:12 AM UTC

reledi wrote: post #96

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 replies are all playing word police and missing the point. Hyperboles are great for getting a point across, except when they're taken too literally. OP means you should be raising the bar for hiring at your org.

Thanks! Yes, exactly what I meant. "The best" is according to your organization's criteria in terms of skills, attitude, etc. for your team. In my experience, when we've started lowering the bar (after interviewing umpteen candidates and eager to just hire someone), we always had problems down the road and usually big ones (i.e. none of those candidates are any longer with us).

I'm not talking about the mythical 10x engineers or anything like that. It's your bar for what skills fit into your company. If you have no bar...you've got much bigger problems than management...

That said, if you lower the bar a bit in hiring, do not lower the bar in expectations. See if that person who you weren't that confident in can catch up fast. Some candidates work very hard and make it. Those who aren't are apparently fairly quickly...you have to let them go.

Incidentally, there is no real "best" when it comes to engineers -- I've found there are two ways to think about the engineers you need: specific skillsets and brilliance. Someones you need someone who really knows a particular technology or area and can do that very well even if that person isn't generally super-capable. Such a person is often much more efficient than any new-comer will be even after several months of training. Then there's certain work that requires learning or general brilliance (which is probably learning fast if I had to define it...).

Re: Engineering management lessons (2014)

#105

Post by theprop » Sun, May 21, 2017, 7:15 AM 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 noted in another comment, but I'll say it again hopefully right below my post (sorry I should've clarified it in the original comment because it is VERY annoying that every company claims to hire "the best"). What I meant by "the best" was those folks who meet your bar...whatever that bar is. So it's not anything absolute but depends on your organization.

Re: Engineering management lessons (2014)

#106

Post by loco5niner » Sun, May 21, 2017, 8:05 AM UTC

douche wrote: post #41

boltzmannbrain wrote: post #39

+ a meta-point: Learn these through experience, not in a classroom. Having managed engineers in industry and also gone through a masters program in engineering management, 90% of what makes me a decent manager/leader/coach today can be attributed to the former.

The dirty secret is that 90% of all formal education is a waste of time, and is just signalling hoop-jumping.

Overall, my CompSci degree certainly wasn't. Some classes were though.

Re: Engineering management lessons (2014)

#107

Post by pionar » Sun, May 21, 2017, 12:10 PM UTC

biztos wrote: post #47

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

I've never been an engineering manager so this is my perspective as a software engineer: My attention is my ability to concentrate on what I need to do right now -- not what the company needs in a broad strategic sense, not what the stock is doing, not what might be on the horizon in a few weeks. All of those things are important to me but my attention can only be on one at a time. And I think the reality of serious…

I am an engineering manager, formerly a dev, so I know what you mean.

I have a rule that I'm the gatekeeper to my group's time. My people know that if someone tries to contact them directly (unless as part of an ongoing project/conversation), they're to direct that person to me, where I can set expectations appropriately. It doesn't happen much anymore.

I see part of my role as a liaison between my group and the rest of the company.

My people don't fight fires, there's a team for that. I'm sorry that you don't feel like your issue gets the attention it deserves over there. Those guys are swamped. Pinging my team directly is not the appropriate resolution.

Usually, what happens is someone from some other group (sales, support, services) will come to me to ask a question. If I don't directly know the answer, I'll throw the question in a Slack channel. My ask of my team is that they check that before they head out to lunch, head home, etc., because it's usually a 5-minute investigation.

Re: Engineering management lessons (2014)

#108

Post by logicallee » Sun, May 21, 2017, 2:00 PM UTC

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

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

This might be the single best example of "managing upward" that anyone has ever written on Hacker News.

Re: Engineering management lessons (2014)

#109

Post by mratzloff » Sun, May 21, 2017, 3:10 PM UTC

"When you do X, it makes me feel Y."

I saw this phrase several times in this article and the linked article on "non-violent communication," but I don't think it's a particularly productive phrase.

Consider the possibility that no one can "make you" feel anything, and that you are ultimately responsible for your own emotional state. For example, you can't command me to feel happy or sad. My emotional response is something I'm a party to, in combination with my own unresolved fears and insecurities.

Instead, I suggest phrasing it in the present tense: "When you do X, I feel Y." That is observational and avoids any accusation or blame, so you can focus on the core issue at hand.

Re: Engineering management lessons (2014)

#110

Post by EpicEng » Sun, May 21, 2017, 11:58 PM UTC

dasmoth wrote: post #85

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…

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. While I agree with the general point here, I'm not…

I think the intent is to have a "question by default" mentality. I'm a lead and my default answer is almost always (in my head) "no" when asked for something from the team that doesn't have direct development value. I then try to get the requestor to demonstrate why e.g. a meeting is needed.

More often than not we end up solving the issue via email.