Live data from Hacker News

How to drive away your best engineers

blog.hulacorn.com

21–30 of 316 posts

Re: How to drive away your best engineers

#21

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

Growing your team too fast will always result in integration problems. Both quality and culture wise.

Quality can be enforced by tooling somewhat (automatic formatting, enforced linter rules in CI etc.), but culture takes time.

Re: How to drive away your best engineers

#22

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

I work in a small company, and we have a team of 3, if you count liberally. One colleague does front-end stuff, there is a tester who is intimately familiar with the way the software is used, I do the rest. That's really enough for the moment.

Re: How to drive away your best engineers

#23

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

There's a huge difference between a team of 6 full-stack developers and a modularized team where everyone has their own projects.

Re: How to drive away your best engineers

#24

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.

I don't agree.

Its perfectly reasonable not to have any idea about an estimate until after an investigation or prototype has been produced.

Demanding an estimate up front for something totally new just makes you look inexperianced or bad at managing engineers.

Re: How to drive away your best engineers

#26
post #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.

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.

Right, in that case, I'd probably give up my vacation instead.

Re: How to drive away your best engineers

#27

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

There's a huge difference between a team of 6 full-stack developers and a modularized team where everyone has their own projects.

Six is where you start figuring out how you're going to split the team. Eight is where you actually make it happen (either into 4+4 or 6+2).

Re: How to drive away your best engineers

#28

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…

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

Re: How to drive away your best engineers

#29
post #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 g…

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

It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost.

Time is almost always more flexible than the people imposing the deadlines think that it is.

As for budget, you just have to choose to keep spending more, or to stop (or wait till you run out of money). Making up an estimate beforehand doesn't alter that process.

If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time. In reality we all know what usually happens: the project simply continues; the estimates, deadlines, etc. are shifted.

Re: How to drive away your best engineers

#30

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!

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.
Post reply on HN