Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to drive away your best engineers

blog.hulacorn.com

Post reply on HN
Print view View original

261–270 of 316 posts

Re: How to drive away your best engineers

#261

Post by therealdrag0 »

mancerayder wrote: post #197
flappyeagle wrote: post #181

I get paid to give advice to tech executives and directors. Something I often have to say to them is: hire talented managers. Talent dominates technique. They need to stop reading blog posts like this and just think about talent. We’re obsessed with technical talent but we hire managers at random after asking a couple of behavioral questions they’ve heard a thousand times.

What's your opinion of the new hiring standard that has arisen the last several years across Big Tech and has trickled down: We're looking for an experienced Software or SRE or DevOps or X Manager in this exciting and fast growing company! Must be able to code in a job interview, have five years experience or more directly managing a staff count of at least ten engineers, and answer algorithm questions! We also expec…

I’m not a manager but I’ve observed managers stay technically strong by being involved in technical activities. Participate in design reviews, project planning, on-call issues etc. being able to smell good vs bad system design does not change that fast. Also they’ll occasionally bust out a ticket that only takes a few hours, aka still able to commit code. I don’t think this is unreasonable for edge level managers. I even get good insight from managers at the director/vp level at where I work.

Re: How to drive away your best engineers

#262

Post by anotherrandom »

eggsmediumrare wrote: post #255
bdw5204 wrote: post #208

Earlier quoted context omitted.

The best way to evaluate the productivity of engineers would be to determine if their peers see them as a top performer, a net positive or a net negative. If somebody is a net negative, get rid of them. If somebody is a top performer, make sure they're compensated accordingly and kept happy so they don't leave. If somebody is a net positive then you should be satisfied that you aren't stuck with a net negative. Any a…

There's a guy on my team who everyone thinks is a bad programmer and general looks down on, but he is always willing to help, does a thorough job and writes generally decent code. I have no idea where his reputation came from, but it would be a shame if he were let go based on his peer evaluation.

If he does a good job and is always willing to help, that sounds like a net positive to me. It just might be that there are a lot of toxic team members

Re: How to drive away your best engineers

#263

Post by m3047 »

BeetleB wrote: post #237
LaurensBER wrote: post #6

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…

> have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed. Why should I have to teach a junior how to use an essential tool of the job, when I can just point them to good books/guides on the Internet? My list would definitely include: Hire people who can and are w…

> I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed.

Git is nontrivial and has many ways to do things, and it is only one of many ways to do most of these things.

If commit messages and merge squashing take the discernment and nose of a winemaker, you can't tell them to crush some grapes and leave it at that.

Re: How to drive away your best engineers

#264

Post by anotherrandom »

summertime42 wrote: post #219
cebert wrote: post #163

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…

If it's as bad as you say it is, collect evidence and prove Mythical Man-Month to them. Explain it's wasting more time AND money, and the deadline is missed regardless. Hopefully they'll listen.

Depends on the company. At BigCorp Inc., that sounds like a great way to get on management's bad side

Re: How to drive away your best engineers

#265

Post by marcosdumay »

greymalik wrote: post #147
wildrhythms wrote: post #69

Earlier quoted context omitted.

Do you think someone is qualified to manage a process they don't understand?

Do you think it’s impossible for someone to understand a process without having years of experience doing it themselves?

At least a few days, yes, it's impossible.

But more importantly, it's impossible to manage a process that you don't know how to do yourself. The closest you can get is on a client-seller relationship.

Re: How to drive away your best engineers

#266

Post by dreamcompiler »

sokoloff wrote: post #61
LaurensBER wrote: post #6

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…

It’s hilarious to me to think “let’s put all the managers on one team…”

Reminds me of the B Ark.

https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_...

Re: How to drive away your best engineers

#267

Post by marcosdumay »

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…

How many times did you take a task you have no idea of the timeframe, do some short research without completing it and was able to make a correct estimate?

If that happened even once, I would be interested to hear about it.

Re: How to drive away your best engineers

#268

Post by jnwatson »

LaurensBER wrote: post #6

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…

An interesting sociological question arises about how knowledge is passed down through generations.

One could count the number of software engineering management tenets on one hand. One of them was detailed in a popular book almost a half century ago.

If managers haven’t heard of the Mythical Man Month, how can one have any confidence at all about any of their decisions. Is management a knowledge-free profession?

Re: How to drive away your best engineers

#269

Post by marcosdumay »

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…

> It's not uncommon IME that doing the work to come up with a reasonable estimate is 80% of the final work.

That estimate you do after finishing 80% of the work is probably orders of magnitude smaller than the real thing.

More realistically, if you don't have the experience for an estimate beforehand, you also don't have the experience to know when you covered enough of the high-risk subproblems, so you have no basis at all to decide how complete your research is. You will only have a reasonably safe estimate by the time you finish the task.

Re: How to drive away your best engineers

#270

Post by marcosdumay »

threatripper wrote: post #158
SideburnsOfDoom wrote: post #43

Earlier quoted context omitted.

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

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

Looks like your project management plans have a problem.

Post reply on HN