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

191–200 of 316 posts

Re: How to drive away your best engineers

#191

Post by ironmagma »

whydid wrote: post #183
ironmagma wrote: post #177

Earlier quoted context omitted.

As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.

Yes, git can be complex. It's also a requirement for modern software development. It is well documented, and not esoteric. If someone hasn't taken the time to learn the tools their team uses, they will be a burden to the rest of the team. They don't need to become an expert, just experienced enough so they don't cause problems for others on the team.

I've never seen documentation on Git that was good and accurate. Pretty much every explainer out there commits major errors, claiming things like: commits are changesets, branches are sets of commits, claiming that any Git operation can be undone, implying merge is a symmetrical operation, or saying to never force push.

Being a beginner in Git is probably hell.

Re: How to drive away your best engineers

#192

Post by pmontra »

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…

Some managers do that kind of things to prepare the next step of their career or because they worked for the company they are hiring (which is a variation of the first point.)

Re: How to drive away your best engineers

#193

Post by SpicyLemonZest »

chrisseaton wrote: post #56
mwcampbell wrote: post #26

Earlier quoted context omitted.

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.

Why does anyone have to give up a vacation? Unless you're building intelligence or defence software or something like that.

When you're have a small company you're hoping to turn into a larger one, many deadlines are every bit as existential as a DoD proposal deadline for a defense contractor. Especially when you don't have a big slosh pool of VC funding (but this is largely true even if you do), the difference between "stable and growing at a healthy pace" and "if something doesn't change we'll have to shut down" is often one or two customers.

Re: How to drive away your best engineers

#194

Post by skeeter2020 »

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.

This is definitely not universal. I'm at my 3rd organization in an engineering management capacity, and only the 1st one where I grew into the role didn't both put me through the technical gauntlet and explicitly interview for people leadership skills and experience. I think the challenge is that management is a more subtle skill with longer lead times to positive outcomes. There is no testable analogy for the coding challenge or take home project.

>> Talent dominates technique.

I really don't like this as it implies some sort of naturally leader vs. skill development over time. We'd do much better to optimize for affinity, desire and coachability in potential leaders.

Re: How to drive away your best engineers

#195

Post by honkdaddy »

skeeter2020 wrote: post #189

I get why these "Managers are so clueless!" posts feel good and are often well received. One thing that would help is if technical talent didn't naturally position leadership as comprised of people who are totally different from them, who intentionally strive to create an unpleasant counter-productive environment that makes it hard to create and deliver software. I get the pain expressed here, it's real, and the prob…

Well said. Managing engineers is an incredibly difficult and multi-variable challenge - companies have been trying different approaches for nearly a century now. We like to imagine as software developers our management problems are unique and can be solved with a silver bullet blog post, but I think they’re largely the same meta-issues that Ford faced in the 30s or Boeing in the 90s.

Re: How to drive away your best engineers

#196

Post by [deleted] »

lawgimenez wrote: post #70
noduerme wrote: post #45

Granted, speaking as someone running a very small shop, mostly freelance, I really think a lot of the ennui and sense of being overwhelmed or unsatisfied can be solved by just deploying constantly. Rather than get stuck in a review cycle I try to get every incremental change online as soon as it's done and minimally tested. That can be up to six live redeployments per day, especially when a new feature is in beta. It…

I agree with this one. Nothing frustrates me more than the huge friction from PR to deployment.

[deleted]

Re: How to drive away your best engineers

#197

Post by mancerayder »

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 expect you to know not just application architecture and CI/CD workflow inside and out, but experience with X and Y vendor applications, Z framework, and running Agile teams!

My qualm is that a manager can't remain a hands-on coder very long if they're spending their days in 1:1's, product meetings, negotiating with other teams to protect their engineers, and generally being good managers.

I'm baffled by how someone can be an experienced and talented manager, and also have their technical chops stay strong - forever. Technology changes such that what you became and expert at when you weren't a manager, is different from when you're manager today. All that remains are patterns, intuition and wisdom that can't easily be captured.

When you've experienced first-hand managing various personality types like 'shy engineer who needs to be encouraged' and 'arrogant talented engineer who everyone relies on but does what they feel like' and 'new junior engineer' and 'repurposed engineer who was doing a completely different role' as well as 'the other remote team that's just joined'... you realize these things are hard.

There's no way a heads-down coder can be good at these things. Unless they're elite geniuses or people who work 6-7 days a week.

So I don't understand the job specs for tech management today.

Re: How to drive away your best engineers

#198

Post by rossdavidh »

So, many of these I agree with, but not this one: "Hire managers that cannot build software". Managers that cannot build software are, in my experience, just as likely to be good (or bad) managers as managers that were good programmers. Managers who used to be programmers are sometimes clueless, and aggressively so, about people skills. While it is possible to manage programmers well without programming skills, if you work at it, I don't believe it is possible to manage programmers (or anybody else) well without people skills.

Software managers who were never programmers _know_ they don't know about programming, and understand that this gives them some blind spots, so they are often willing to take constructive, professional, tactfully given hints on that. Software managers that were programmers, in some cases, not only don't have people skills, they don't think people skills are important or useful, and they don't try to get better.

Not saying former programmers _cannot_ be good managers, I've seen some that are. But I don't think non-programmers are, on balance, less likely to be good at managing software development, because they know what they don't know, and managers who were formerly programmers often don't.

Re: How to drive away your best engineers

#199

Post by dalbasal »

nevinera wrote: post #139
dalbasal wrote: post #101

Earlier quoted context omitted.

IDK. If you're in one of these too-small-high-pressure teams, and then all these extra "resources" get poured in... It can go quite badly too. IMO, engineers themselves are sometimes responsible by leaning on "we need more resources."

I think engineers often say "we need more resources" but mean "we need to have hired more resources two years ago".

One liner of the day. That's the best possible way to make this point.

Re: How to drive away your best engineers

#200

Post by kayodelycaon »

twobitshifter wrote: post #137
kayodelycaon wrote: post #113

Earlier quoted context omitted.

I think some nuance is being missed here. I’ve had a manager come in and ask questions like this and immediately turn around and use the feedback to fire people and rearrange the department.

That sounds like a good thing or was it too fast? Most companies do nothing to address the problems following exit interviews and them end up with terrible retention

People were fired for systemic issues they criticized. Non of the issues were corrected and the new person started handing down questionably legal changes to our platform.
Post reply on HN