How to drive away your best engineers
blog.hulacorn.com
How to drive away your best engineers
1–10 of 316 posts
Re: How to drive away your best engineers
#2Re: How to drive away your best engineers
#3Re: How to drive away your best engineers
#4Re: How to drive away your best engineers
#5Re: How to drive away your best engineers
#6- 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 decisions that affect them. Re-shuffle the teams around, re-architect the product, change the existing workflow, etc. If you hire professionals with 10-20+ years of experience just to ignore their advice, they're going to be looking for an employer that does appreciate their input very quickly. Nothing is more frustrating than telling a manager not to put his hand in a pan of boiling water, just to see him do it and then blame the cooks for having a pot of boiling water around :)
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).
In addition to this he decided to give the responsibility for the architecture of the application to outsourced "solution architects" with no domain knowledge and reorganized the teams to split them by job title (e.g testers, developers, operations, "management", etc).
Current productivity is lower with 55 than it was with 5, 3 out of 5 have already handed in their resignation. We're burning through an additional 3 million this year with 2 crappy React pages to show for it.
Next year the damage will probably be worse given the rapid outflow of talent.
Re: How to drive away your best engineers
#7I totally agree with this. I am in a situation right now where the skip level manager is asking to schedule meetings every other day to talk on a problem that requires research. They want to talk about a solution and not letting us find one. Another one is defining aggressive timelines when I don't even know what to solve. Obviously the timelines were shot to hell in the worst way possible.
When you're about to go to production, tests have been written and everyone's done their part, you'll get asked, "so you're sure nothing will break production?" It blows my mind.
Re: How to drive away your best engineers
#8Re: How to drive away your best engineers
#9Not 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…
What one developer can do in a week - two developers can do in two weeks!
Re: How to drive away your best engineers
#10So 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 a bigger team. Even when we do have the revenue to hire, we will certainly not go straight to a team of 6 or more engineers. Big teams have their own problems, like communication overhead.