Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to drive away your best engineers

blog.hulacorn.com

Post reply on HN
Print view View original

111–120 of 316 posts

Re: How to drive away your best engineers

#111

Post by katzgrau »

wildrhythms wrote: post #69
katzgrau wrote: post #44

"What makes engineers sad? Their boss(engineering managers, Directors, VP’s) do not know what they face on a day to day basis and does not know how to build something, whether it is a feature or architecting something from scratch." If that's true, then it's probably mutual. Engineers typically do not realize that their manager's role is to manage people and process (which is a bit of a specialization in itself), and…

Do you think someone is qualified to manage a process they don't understand?

There's a group of these people called CEOs and they get paid a lot.

Re: How to drive away your best engineers

#112

Post by mr90210 »

dalbasal wrote: post #101
pid-1 wrote: post #82

Earlier quoted context omitted.

> If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad. I think there's a sweet spot that's particular to each project and collective skill set. Being in a small team and feeling anxious due being responsible for way too much stuff isn't fun as well.

IDK. If you're in one of these too-small-high-pressure teams, and then all these extra "resources" get poured in... It can go quite badly too. IMO, engineers themselves are sometimes responsible by leaning on "we need more resources."

Same thing happening at the small team I am part of, we have just hired a fifth engineer, while the business often struggles to define what’s a priority.

Re: How to drive away your best engineers

#113

Post by kayodelycaon »

netfortius wrote: post #84

Just reading the beginning of the article, and I couldn't help re-re-emphasizing how critical it is - as a manager at any level - to conduct "exit interviews" with your report-tos and other dependents, right when taking over a group. This was one of the best methods I leveraged, in my over 25 yrs career, in all sorts of low or senior management positions, i.e. serious "exit interview" with any team I got anew, which…

I think some nuance is being missed here. I’ve had a manager come in and ask questions like this and immediately turn around and use the feedback to fire people and rearrange the department.

Re: How to drive away your best engineers

#114

Post by abacadaba »

woutr_be wrote: post #15
lloydatkinson wrote: post #5

Specifically about managers that don’t have technical abilities - installing “agile coaches” as the scrum master and other Big Agile TM nonsense. Maximum micromanagement and a team getting ever more exhausted and demoralised.

The previous big bank I worked at did this all, they had an agile coach and multiple scrum masters. The agile coach would essentially sell agile to management, and then blame development teams for not delivering what he sold. Building a product almost became irrelevant. We seriously had a full day of sprint planning. Even had meetings where we had to deliver a feature in two weeks, and the agile coach put us all into…

Just 1 day? pfft

Re: How to drive away your best engineers

#115

Post by skydhash »

Closi wrote: post #17
hericium wrote: post #12

Agree with most points but one which is making a manager do coding/shipping. Most of IT managers I met possessed no real IT skills. They wrapped their heads around only as much theory as needed to _manage_. Most of them did not came from engineering world but from business one. Ideally, manager should be able to do the work their team is doing, but reality is quite different. I stopped expecting managers to understan…

> Regarding estimates, it really is frustrating when a non-engineering manager cannot understand the inability to state any reasonable time estimation. On the flipside, it can be frustrating for managers that engineers sometimes can’t understand that they have to manage deadlines. If the engineer doesn’t make an educated guess at the time it will take then the manager is put in the position of making a non-educated g…

> On the flipside, it can be frustrating for managers that engineers sometimes can’t understand that they have to manage deadlines.

Deadlines are not solved by estimations. Deadlines are a business problem that can be resolved by a discussion with your engineer to work out a plan based on that time constraint. If you have a deadline in mind for a feature, it would be better to state it directly. Then the engineer can say it can or can't be done the way you wanted. Or we need to modify the requirements to fit it in this timeframe.

But the most horrendous thing I've seen is when you give an estimation, the manager treat it as an actual deadline. It should only be used to verify if everything is progressing correctly and should be revisited periodically. But not to make promises.

Re: How to drive away your best engineers

#116

Post by ClumsyPilot »

woevdbz wrote: post #109

The underlying principle I've been using to understand this is, no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well. The opportunity cost of talented software engineers is much too high in general. This applies regardless of actual talent and does not guarantee results. I've seen mediocre SWEs with inflated egos jump ar…

> no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well

So is everyone developing advertising at google is a second rate engineer?

Re: How to drive away your best engineers

#117

Post by Ensorceled »

BaseballPhysics wrote: post #83

> Stop estimating. I have analysed every team I have been on that use estimation. Those teams have been 99% incorrect. In my experience, it does not work. If you need dates, I would recommend a more modern approach like forecasting. What does this even mean? I've never heard of a forecast that didn't use a combination of past data and an assessment of complexity of future work to assemble the forecast. And assessment…

The problem is that article is confusing the management failure of assuming estimates should be accurate and then punishing/rewarding based on accuracy of estimates with the proper practice of using estimates for scoping projects so they can properly prioritized and loosely road-mapped.

It's a throw the baby out with the bathwater problem.

Re: How to drive away your best engineers

#118

Post by anarazel »

bryanrasmussen wrote: post #28
hericium wrote: post #12

Agree with most points but one which is making a manager do coding/shipping. Most of IT managers I met possessed no real IT skills. They wrapped their heads around only as much theory as needed to _manage_. Most of them did not came from engineering world but from business one. Ideally, manager should be able to do the work their team is doing, but reality is quite different. I stopped expecting managers to understan…

Most engineers can guestimate, but I do know one that would say the following: no idea, I will have to do two days of research on the matter and come back to you with an estimate in standup the day after tomorrow. (really, he said exactly that one time, it was a wonderful expression of his character I thought) The person who just says no idea, and doesn't have a way to get to an idea, seems to have a very problematic…

It's not uncommon IME that doing the work to come up with a reasonable estimate is 80% of the final work.

E.g., addressing a scalability issue might require a bunch of profiling work, then a bunch of experimentation / thinking about developing a lock free algorithm. Or it might turn out that reducing false sharing a bit will give large enough benefit on its own. Without having done most of that I won't know whether it's a few days or many weeks.

Re: How to drive away your best engineers

#119

Post by elric »

nonrandomstring wrote: post #18

I'm sure we can all add plenty of fresh examples of bad organisational dynamics. Other than texts like Gall's "Systemantics" is there an equivalent to Acemoglu and Robinson's "Why Nations Fail" but for companies and projects? Here's some of mine: Put "security" before all else. Pointlessly surveil and monitor your staff for feelgood security theatre. Mandate MFA for every trivial login so that simply checking your em…

Is there a story behind all this bitterness?

MFA for every login is a very good idea. If you're having to log in to the same service over and over again within a short amount of time, someone is doing something very wrong.

Sending out company newsletters seems like a nice way to let everyone know what the company is up to. Not sure how you go from that to reminding lowly engineers of their "insignificance".

Social events are a great way to get to know your coworkers and to improve cooperation. Awareness training (I'm imagining you mean things like Security Awareness and such) also seem like an overwhelmingly good thing.

Everyone has actual work to do. All the stuff you perceive as meta comes with the territory of working anywhere with a non-trivial number of people.

Re: How to drive away your best engineers

#120

Post by marcinzm »

kqr wrote: post #90
a-walker wrote: post #77

> Stop estimating. I have analysed every team I have been on that use estimation. Those teams have been 99% incorrect. In my experience, it does not work. If you need dates, I would recommend a more modern approach like forecasting. What's the difference between estimating and forecasting? Seems very binary as written, but at some point don't you have to look forward and make some assumptions on complexity/effort req…

This sounds like it's written by someone who's only been in teams that do point estimations. Those are, almost by definition, 100 % incorrect because even small variations mean you're not done exactly when you said you'd be done. If you estimate in properly calibrated 90 % intervals, you'll be correct 90 % of the time, and this is something you can verify continually.

My company right now does OKRs with priority levels for each task. If you make it a P0 then you're saying it will get done this quarter baring really unexpected circumstances (ie: shit happens, we understand). P1 may not get done. P2 is even less likely to get done. This creates a natural distribution by holding the date constant and varying the work done by that date. Personally I find this more reliable and easier to communicate than holding the work constant and varying the date of each item.
Post reply on HN