How to drive away your best engineers • Hacker News Board

Re: How to drive away your best engineers

#141

Post by kqr » Sun, Jul 24, 2022, 1:24 PM UTC

marcinzm wrote: post #120

kqr wrote: post #90

Earlier quoted context omitted.

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 be honest, I also like that approach better, because in my experience the budget tends to be relatively fixed, but the work amount is often fairly flexible.

Re: How to drive away your best engineers

#142

Post by [deleted] » Sun, Jul 24, 2022, 1:25 PM UTC

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…

[deleted]

Re: How to drive away your best engineers

#143

Post by unsupp0rted » Sun, Jul 24, 2022, 1:27 PM UTC

katzgrau wrote: post #111

wildrhythms wrote: post #69

Earlier quoted context omitted.

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.

They manage a process they do understand (in theory): getting groups of people to do valuable stuff without irreparably imploding.

I don’t understand any of the tools I use in my own work (how does VS Code do syntax highlighting? How does the electricity make my laptop screen show me high resolution colors?). But I’m still able to produce plenty of value for my clients.

Re: How to drive away your best engineers

#144

Post by greymalik » Sun, Jul 24, 2022, 1:28 PM UTC

kqr wrote: post #108

code_runner wrote: post #97

Earlier quoted context omitted.

I’m interested but not totally sure what you mean here. Do you have a source or name for this intervals/calibration stuff? I’ve always had issues when people are using hours instead of points. The one time we properly used points on a team it went really well.

A good reference is Douglas Hubbard's How to Measure Anything . The idea is that most people can calibrate their sense of probability to be fairly accurate, by intentionally adjusting for some common biases. (In particular, if you prevent anchoring and availability bias, and actively engage system 2 and your loss aversion, you get a long way. There are specific techniques to do that in the book.) This is really easy…

I’m a developer who’s been doing this for a loooong time and I can’t imagine being able to accurately guess with 90% confidence the calendar day I’ll have a particular task done. And the tasks I work on are different enough that a feedback loop about how much I misguessed would be useless for error-correcting future estimates. Maybe that works for factory-like tasks like how long it tasks to add a REST endpoint for a CRUD action?

Re: How to drive away your best engineers

#145

Post by kqr » Sun, Jul 24, 2022, 1:28 PM UTC

dalbasal wrote: post #62

Most of these, I think, relate to a single kinda-meta-problem. Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compar…

This is a great point. I've never thought about it in these terms before, but whenever I've transitioned from organisations that feel like they're "run by engineers" into organisations that feel like they're "run by administrators" I've taken a hit in happiness.

Re: How to drive away your best engineers

#146

Post by drdec » Sun, Jul 24, 2022, 1:29 PM UTC

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…

I disagreed with this point in the article. I do not need a manager that has done my job before or spends a week a quarter doing my job. I need a manager that knows how to get my team the resources it needs and knows how to to deliver a product. Most importantly, I need a manager that trusts the team.

I've had great managers that couldn't code their way out of a paper bag.

Re: How to drive away your best engineers

#147

Post by greymalik » Sun, Jul 24, 2022, 1:30 PM UTC

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?

Do you think it’s impossible for someone to understand a process without having years of experience doing it themselves?

Re: How to drive away your best engineers

#148

Post by ChrisMarshallNY » Sun, Jul 24, 2022, 1:30 PM UTC

> Hire managers that cannot build software

> Make the process of defining software painful.

> Make engineers estimate their work.

IMNSHO, these all have the same "fix":

Technically-proficient managers (that are also good managers). The combination of those two is rare.

Management is often considered an "ego position," so unqualified* people fight to be managers. It's not always about the money. It may be about the office, the car, the administrative assistant, the invitations to trade shows, etc.

Also, upper management types frequently consider "workers" to be "lower class people," and only want people they can relate to, personally, and that don't make them uncomfortable, in management roles, so they end up mining the Yes Man and Politician veins for managerial talent.

In my case, my company actively discouraged me from being technically proficient. They would routinely deny me training (so I went to training seminars on my own dime, and took vacation time), and would ignore my technical work (which was often extremely relevant and useful). I ended up doing a ton of open-source work, just to keep my tech chops up. Because it was my own work, I did stuff that had very little connection with my "day job," and also brought my own equipment.

I hated being a manager. It was always a burden, but I feel (and everyone else seemed to agree), that I was pretty good at it. Since leaving my last job, I ran screaming for my tech work.

*"Unqualified" is not just "technically unqualified," but also "emotionally unqualified." I think managers need to remember that they are managing people, not just "human capital," and that, if things are done right, their employees may be more technically qualified than they are. That was certainly the case for me, and I was proud that my team knew more about the work than I did.

Re: How to drive away your best engineers

#149

Post by magicalhippo » Sun, Jul 24, 2022, 1:32 PM UTC

threatripper wrote: post #135

magicalhippo wrote: post #95

Earlier quoted context omitted.

When I'm asked by my boss to estimate, I break it down for him. This part here I'm confident is 1-2 days of work, this part here can potentially be tricky so could be 1 day could be a week, and this part here I can't tell without digging into the details. If this is based on a customer request I'll try to find some restrictions he could take back to the customer to narrow the scope and provide a better estimate assum…

What if he asks you for a number instead of a range? After all you have to use the company template to present your project and that does not have ranges on it.

If for example, I say 3-7 days and he wants a single number because customer wants a date, he'll ask me "ok, so if I say to the customer they'll get the change in 10 days, we should be able to deliver?"

Then I say yes, under the assumption of X, Y and Z that sounds realistic to me.

Of course, sometimes the numbers are to high. That's where narrowing the scope or even finding a different solution comes in.

Re: How to drive away your best engineers

#150

Post by nonrandomstring » Sun, Jul 24, 2022, 1:33 PM UTC

elric wrote: post #119

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

> Is there a story behind all this bitterness?

Does it even need saying? Of course there is. Many stories. Over many decades. It's sad watching great people quit and wonderful projects die because of a poor working environment and the selfishness of others who inflict their narrow values in others. If you're one of the people who see these as good things then naturally you'd frame criticism as "bitterness". But as another commenter said, these are personal stories. Your own subjective peeves might strike me as strange. Do please open your mind to a world that contains different people with different values.