How to drive away your best engineers • Hacker News Board

Re: How to drive away your best engineers

#151

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

DoubleGlazing wrote: post #133

> Stop estimating. This! It's more or less impossible to correctly estimate how long it will take to develop anything but the most basic pieces of software, and even then you can't be sure. I've had so managers who just don't get that there are so many unknown variables in the software development process. No matter what estimate you give, you cannot win. Estimate short, but it takes longer? Then you are accused of n…

Give three estimates. One if everything goes well, the most optimistically you can imagine. One representing the most likely path. And one representing the worst-case scenario. Let your manager digest from there.

If you have a bad manager (e.g. they would just use the best-case scenario estimate and ignore the others), average the estimates, 1 part best case, 1 part worst case and 4 parts normal case. Then try to make sure you are giving a set of estimates, not just one, and usually it will average out.

Step two of having a bad manager is finding a different situation, whether via internal transfer or a new job.

Re: How to drive away your best engineers

#152

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

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…

I think the difference is that a forecast is developed by a team (or formula/ML) separate from the engineers doing the work.

Re: How to drive away your best engineers

#153

Post by quantum_state » Sun, Jul 24, 2022, 1:40 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…

Very much true but not really recognized by management in general.

Re: How to drive away your best engineers

#154

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

Reading this article and the comments here is like group therapy. This feels like a nearly-universal experience; the shared trauma of pouring everything into a project only to see success destroyed by incompetent management.

I've been writing code for a living for 20 years and I swear it wasn't always this bad. There were fulfilling software jobs at one point. What changed?

Re: How to drive away your best engineers

#155

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

pluc wrote: post #105

> Design your organisation to minimise collaboration between teams, but have high collaboration within the team. this is a joke right?

Charitable read: OP probably didn't mean "minimize collaboration" but "minimize the need for collaboration."

Or phrased differently: design your teams so that the most common tasks can be done by a single team.

If support needs to talk to the developers for every single support request, there isn't much need for a separate support team. If, on the other hand, the support team gets all the tools and training to address the 99% most common support cases, support gets faster and developers get fewer interruptions.

Re: How to drive away your best engineers

#156

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

marginalia_nu wrote: post #19

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!

If we move to a microservices architecture, we can use 100 developers to solve same the same problem in with ten times the hardware! With growth like that, we'll be unstoppable!

How else will we justify the military grade, globally distributed, multi-planetary federated, immediately consistent Kafka cluster that the CIO just purchased? I’m still not sure how to get all the servers to synchronize when Mars is on the opposite side of the sun.

Re: How to drive away your best engineers

#157

Post by ramphastidae » Sun, Jul 24, 2022, 1:44 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.

This is pure fantasy. Markets have never been efficient and actors have never been rational.

Re: How to drive away your best engineers

#158

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

SideburnsOfDoom wrote: post #43

threatripper wrote: post #42

Earlier quoted context omitted.

True, the problem lies somewhere else. Maybe the project should not exist at all if it's not manageable. The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time?" and if you cannot then you should not take the project. The problem is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the en…

> The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time? Incorrect, it implies "can you do it in a reasonable time, that is as yet unknown and unknowable" - which might even be quite small, but no-one really knows, so committing to a fixed deadline is at best fooling yourself, and is more likely a trap. > is that it's hard to hire…

How could you make project management plans that imply deadlines if you don't have deadlines?

Yeah, maybe it's not such a smart idea to start with commitments that imply dates. But that's how it is. If you want to work in your own way then start your own company, I guess. Maybe it's time to do that.

Re: How to drive away your best engineers

#159

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

Nobody asked for walls in an exit interview? All of the engineers you spoke to enjoyed debugging while listening to sales calls?

Re: How to drive away your best engineers

#160

Post by CipherThrowaway » Sun, Jul 24, 2022, 1:47 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 strongly agree that managers do not need to be technical or understand dev work. However, I don't have much sympathy for managers who are "misunderstood" by engineers. Companies that have issues with disgruntled engineers grumbling about management and process are mismanaged almost by definition.