How to drive away your best engineers • Hacker News Board

Re: How to drive away your best engineers

#161

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

threatripper wrote: post #30

romanovcode wrote: post #9

Earlier quoted context omitted.

> My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated). What one developer can do in a week - two developers can do in two weeks!

It sounds like you're not having enough coordination meetings. You can make communication more efficient if you add more levels of hierarchy. MBAs are good at managing. Engineers are often wandering off-topic, so put MBAs in between the engineers to manage the communication and avoid unsupervised engineer-engineer-contact between different groups.

They need more morons.

Source: https://www.mit.edu/people/dmredish/wwwMLRF/links/Humor/Admi...

Re: How to drive away your best engineers

#162

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

ebiester wrote: post #92

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…

Forecasting looks like this: https://medium.com/expedia-group-tech/monte-carlo-forecastin... It’s running through simulations based on previous team behavior to give a range.

You still need story point estimates on the previous items, or some reason to believe that previous stories were of similar size (which is also a form of estimate).

Re: How to drive away your best engineers

#163

Post by cebert » Sun, Jul 24, 2022, 2:04 PM UTC

Hiring cheap contractors can be frustrating too. I am on a project that is behind schedule. Management’s solution is to temporarily staff the project with several temporary, cheap offshore developers. I think a smaller team with competent folks can be much more product. There’s a lot of truth to the book, “The Mythical Man Month”. Now, we have far more meetings and communication chains. We also have to spend multiple cycles reviewing the contractor code and helping them learn software development.

Re: How to drive away your best engineers

#164

Post by marcosdumay » Sun, Jul 24, 2022, 2:07 PM UTC

raisin_churn wrote: post #128

noduerme wrote: post #52

Earlier quoted context omitted.

I was waiting for a /s at the end of this comment, but now I can't tell if you're kidding.

If MBAs weren't economically efficient, the market wouldn't make so many of them and companies wouldn't pay them so much.

And you surely got enough answers showing why the "\s" is important...

Re: How to drive away your best engineers

#165

Post by bryanrasmussen » Sun, Jul 24, 2022, 2:12 PM UTC

wildrhythms wrote: post #74

bryanrasmussen wrote: post #28

Earlier quoted context omitted.

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…

I don't agree with this. If an engineer can't estimate how long something will take, usually that's an indication that your requirements are unclear, or there's a history of changing up requirements on people. What you've labeled as a limitation is probably an engineer being honest with you.

ok so in this case I would probably expect them to say:

the requirements are unclear - that right there is them having an idea how they are going to be able to give you an estimate, by forcing you to be clear in your requirements. That would actually be an engineer being honest.

or

there is a history of changing up requirements on issues like this, I can give you the estimate of what it will be with the current requirements but if the requirements change, as in my experience they are likely to, then that estimate will have to change as well. - this would also be an engineer being honest.

Both of those honest examples aside if the engineer replies no I can't make an estimate and I never will be able to it is probably the engineer being a bit pissy. And I know definitely one or two guys who would exactly behave in this manner.

unless you are dealing with the first time implementation of something that there is only mathematical theory backing it and no previous implementations in the world, I have a hard time seeing how you can construct a situation in which an engineer cannot come with an estimate AND cannot find a way to figure out what they need to come with an estimate (more specific requirements, research on the matter). If they can't figure out at least one of those things I'm going to think it is probably a limitation on the part of that engineer.

Finally, I am an engineer. Although I tend to be one of those arrogant guestimaters, which is a failing in my personality.

Re: How to drive away your best engineers

#166

Post by switch007 » Sun, Jul 24, 2022, 2:18 PM UTC

Ensorceled wrote: post #132

hibernator149 wrote: post #46

Earlier quoted context omitted.

- Manager: How long would it take to migrate from A to let's say B? - Me: How would I know that? - Manager: Just make an educated guess. - Me: Maybe X months? I really don't know. - Manager writes down X. - Me makes a mental note to not trust Manager again... Maybe it's better to have any plan than to have no plan, but having a plan based on known bad data can't be the solution. Dear Managers, if your plan requires d…

- Manager: How long would it take to migrate from A to let's say B? - Me: What do we want to accomplish from the migration? I'm assuming cost reduction? - Manager: Yeah, the guys at B are much cheaper. - Me: Ok, give me until EOD Friday to do some investigation. - Manager: EOD Thursday would be better, don't need a full roadmap, just enough for an ROI. I'll flip over the CEO's spreadsheet that she's using for the cal…

Hah if only managers were that grown up too. I’ve tried those conversations.

Firstly, that Friday deadline likely would have been fine, it was just a power play.

Secondly, when the manager said “yep” to dropping the feature, you’ll still be expected to make progress. (Of course most of the time they try to make you do double the work. A quick “yep” wouldn’t happen IRL)

Re: How to drive away your best engineers

#167

Post by bryanrasmussen » Sun, Jul 24, 2022, 2:19 PM UTC

anarazel wrote: post #118

bryanrasmussen wrote: post #28

Earlier quoted context omitted.

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

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

so this sounds like my example of my friend that I gave above who would say I will have to do a bunch of profiling work first and then a few days of investigation before I tell you how much it is actually going to take.

I don't say you can't run into uncertainties and be unable to estimate until you have clarified those uncertainties, I also don't say that you can't run into uncertainties in the actual implementation and have your estimate be woefully off, not every estimate needs to be correct.

Re: How to drive away your best engineers

#168

Post by _djo_ » Sun, Jul 24, 2022, 2:21 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…

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

Speaking as someone working in a small company that was acquired by a much larger corporation that shows all the signs being discussed here, it's not just newsletters. Those are useful. It's being sent dozens of spammy emails a week about initiatives that are clearly some VP's ego project and have no relevance you other than clogging your inbox and taking away some of your time and attention.

One recent example I got was three days of emails telling me to 'get ready' for an internal initiative but mentioning nothing else except a name. No links to click, no calls to action, no useful information at all. Only for the final email to reveal it was about a non-strategic initiative that applied to some other site only, despite all the emails being sent to the global company. All attempts at getting that sort of thing off the all-hands mailing list have been rejected.

A place that thinks that's okay does not respect the time or attention of its employees, and it does tend to make you feel reminded of your insignificance.

Re: How to drive away your best engineers

#169

Post by dasil003 » Sun, Jul 24, 2022, 2:21 PM UTC

23B1 wrote: post #34

Like many engineers, the author of this article assumes all engineers are ethical, and perfectly suited to the assigned task. The author also assumes unlimited budgets, perfect control over a company's hiring and resource management, and a perfect understanding of the software's requirements. These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but a…

Maybe it's because I've always straddled the line between IC, EM and leadership roles, but in my mind engineers are managers. They are managers of software systems. The software systems are producing some economic output just as human or animal labor does in other domains or historical contexts. When you write code and deploy it to a production system, you are responsible for the behavior, cost and other implications of doing so.

Although I believe managing people is generally the harder of the two overall, managing software systems is uniquely demanding of being able to zoom into deep technical details and then back out to understand the big-picture implications and where different layers of abstraction may have failed. To call oneself a senior software engineer I believe you need both the technical understanding as well as the big picture view of what business value your code produces.

Many software engineers don't want to think that way; they look to the Product Manager to tell them what to build, the QA Analyst to sign off on releases, the Ops Engineer to tell them what broke, and the Engineering Manager to prioritize their time. And of course those asks do align with the job descriptions and are not wrong per se. The problem is that the SWE is in a much better position to foresee the majority of problems, and can save the company as well as their team a tremendous amount of pain by trying on different hats and thinking at a higher level. Not all company cultures make this possible, but IMHO it is the key to the highest performing teams.

Re: How to drive away your best engineers

#170

Post by computronus » Sun, Jul 24, 2022, 2:23 PM UTC

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

This sounds like a variation of Brooks's Law - adding people to a late software project makes it later. In this case, now you need to take time to help the new resources ramp up, and the new resources themselves can't make meaningful contributions right away. So the pressure isn't alleviated for a while, and in fact goes up.