Live data from Hacker News

How to drive away your best engineers

blog.hulacorn.com

11–20 of 316 posts

Re: How to drive away your best engineers

#11

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.

I've lost hope of anyone at the top figuring it out.

Re: How to drive away your best engineers

#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 understand what I do outside of expected effects.

Regarding estimates, it really is frustrating when a non-technical manager cannot understand the inability to state any reasonable time estimation.

- so how long will it take you to finish this task?

- no idea, haven't done anything like that in the past

- ok, so how long?

Re: How to drive away your best engineers

#13
Agree on some points (first 3 for sure), disagree on others.

A major missing one is the demoralizing effect of having to work with incompetent team members, with management unwilling or unable to do anything about it.

An incompetent person is likely not a bad person - more likely a good person who is the wrong position, or who just isn't capable.

I recall working on a team where I was called over by one of the members to help out. I was new on the team, and wondered what the sidelong looks from other team members were about. She wanted to know why her program did not run. I asked to see the compiler output. She asked what a compiler was. How a person could attain a masters degree without actually knowing that is beyond me, but her skillset clearly had nothing to do with software.

This was in a government agency, so she was promoted to management where she became one of those other problems on the list.

Re: How to drive away your best engineers

#15

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 a room to figure out how we could use agile to deliver this. He also constantly pushed his technical implementations, despite being a non-technical person.

I believe of the 12 devs across two different teams, only one of them remains at the company today.

My first instinct was try and fight it, try to explain why this wouldn’t work. But you quickly realise the agile coach wasn’t there to help development teams, he was there to sell agile, so he could remain employed.

Re: How to drive away your best engineers

#16

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…

Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. A total nightmare for project management.

Re: How to drive away your best engineers

#17

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 guess (because you can’t effectively run a company without having any idea of either time or cost to deliver).

The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation.

Imagine going to a customer and having to say “Ok, we’ve talked to the engineering team and in order to deliver that feature you asked for they might be able to deliver it in a day for £2,000 or in a year for £500,000”

This doesn’t mean that you can’t give sensical ranges, or state your assumptions when doing the estimate.

Re: How to drive away your best engineers

#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 email becomes a tedious schlep.

Spam your employees. Send out daily self-congratulatory ego-trips as "newsletters" celebrating how well the company is doing. Sap morale by reminding every lowly engineer just how insignificant they are, what huge profits the company is making and how much senior salaries are. For bonus points use a "no-reply" internal address and make it impossible to block them.

"Team build" by putting on mandatory "social" events, and various awareness and training. Shame employees to do not "participate" because that have actual work to do.

Keep zombie projects alive. Even though clients have cancelled and everyone knows it will never be delivered, keep projects running for the sake of appearances and to keep managers close to retirement in a job for another year.

Actually, stop me! This could go on all day. Someone really should write a book "How to kill a company".

Re: How to drive away your best engineers

#19

Not included in this list but definitely worth mentioning; - Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. - Not involving your current team in decis…

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

Re: How to drive away your best engineers

#20

> In my opinion, Have a minimum team size of six. So I guess this post is only for big companies and VC-funded startups. I'm the technical cofounder of a tiny bootstrapped company, and for now, I'm the only engineer. Being the sole engineer is stressful, but it's currently necessary, and I think it's worthwhile to maintain the control and integrity that we'd probably have to give up if we pursued the funding to hire…

Not having team of six can be alleviated by setting realistic expectations.

If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago.

It will hit your bottom line but that is the risk you will have to eat as an owner and not your employees.

Manager at big.co usually does not have option to "eat a risk" so he should put preventative measure for such a scenario.

Post reply on HN