How to drive away your best engineers • Hacker News Board

Re: How to drive away your best engineers

#221

Post by grayclhn » Sun, Jul 24, 2022, 4:11 PM UTC

dasil003 wrote: post #169

23B1 wrote: post #34

Like many engineers, the author of this article assumes all engineers are ethical, and perfectly suited to the assigned task. The author also assumes unlimited budgets, perfect control over a company's hiring and resource management, and a perfect understanding of the software's requirements. These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but a…

Maybe it's because I've always straddled the line between IC, EM and leadership roles, but in my mind engineers are managers. They are managers of software systems. The software systems are producing some economic output just as human or animal labor does in other domains or historical contexts. When you write code and deploy it to a production system, you are responsible for the behavior, cost and other implications…

This is usually why people make the distinction between “leadership” and “management” — if you use “management” the way your comment does, you no longer have a word for someone with multiple direct reports.

But yes — totally agree that “technical leadership” is 100% part of being a senior+ engineer and that almost always requires understanding the business and customers.

Re: How to drive away your best engineers

#222

Post by a_square_peg » Sun, Jul 24, 2022, 4:13 PM UTC

I see posts like this and wonder if software developers are in such high demand that they're able to call the shots these days but many of these points are come off as very arrogant.

> Make your engineering managers, Directors or VP’s take about one week in a quarter and get them to build and deliver a feature.

While we're at it, why don't we also get them to design a part of a car, design an icon for UX, do some accounting and have them do a legal brief?

> Stop estimating.

How does this person think an organization schedule, budget and allocate resources?

> In my opinion, Have a minimum team size of six.

To build what? Some production software can be built by one person. Some need hundreds. This is like saying an organization needs a minimum of $1.5m annual budget for software development because it's software development.

Re: How to drive away your best engineers

#223

Post by grayclhn » Sun, Jul 24, 2022, 4:20 PM UTC

a_square_peg wrote: post #222

I see posts like this and wonder if software developers are in such high demand that they're able to call the shots these days but many of these points are come off as very arrogant. > Make your engineering managers, Directors or VP’s take about one week in a quarter and get them to build and deliver a feature. While we're at it, why don't we also get them to design a part of a car, design an icon for UX, do some acc…

>> Stop estimating.

> How does this person think an organization schedule, budget and allocate resources?

Collect data and use a trivial prediction model (i.e. median calendar time it took to complete the last 5 stories). Monitor and improve the prediction model over time if necessary. If you’re not collecting data reliably enough to generate a prediction automatically, you’re not taking any of these issues seriously anyway.

Re: How to drive away your best engineers

#224

Post by grayclhn » Sun, Jul 24, 2022, 4:22 PM UTC

lifeisstillgood wrote: post #175

nonrandomstring wrote: post #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 em…

I argue it's democracy. (That can save Nations and presumably companies) Imagine voting for the CEO. Imagine voting to allocate budgets. Yes there will be a lot of pork barrel- but it might just work. I mean the idea that companies are like single cells / autonoma so they don't have to be democratic leads us to silly ideas like trying to put in place rules for not abusing the electorate. I mean if a boss is sexually…

You vote by changing jobs. I think “real governments” make it clear that this isn’t sufficient to thwart harassment though.

Re: How to drive away your best engineers

#225

Post by AtNightWeCode » Sun, Jul 24, 2022, 4:26 PM UTC

Some very good points on this list. Some more points.

1. Hand out responsibilities and make engineers accountable without giving the engineers any influence on decisions.

2. Make team decisions without asking the team.

3. Make promises to individual employees that is not inline with the team or company strategy.

4. Make tech decisions among management people.

5. Outsource new development and let the staff work with legacy.

6. Constantly increase the scoop of what the engineers are working with.

Re: How to drive away your best engineers

#226

Post by kimixa » Sun, Jul 24, 2022, 4:29 PM UTC

grayclhn wrote: post #223

a_square_peg wrote: post #222

I see posts like this and wonder if software developers are in such high demand that they're able to call the shots these days but many of these points are come off as very arrogant. > Make your engineering managers, Directors or VP’s take about one week in a quarter and get them to build and deliver a feature. While we're at it, why don't we also get them to design a part of a car, design an icon for UX, do some acc…

>> Stop estimating. > How does this person think an organization schedule, budget and allocate resources? Collect data and use a trivial prediction model (i.e. median calendar time it took to complete the last 5 stories). Monitor and improve the prediction model over time if necessary. If you’re not collecting data reliably enough to generate a prediction automatically, you’re not taking any of these issues seriously…

That's just a way of estimating that is likely quite accurate in a completely steady state.

But what if you know you're changing things significantly, and that's the whole point you need to think about resources and schedules? Like starting a new project?

Re: How to drive away your best engineers

#227

Post by steveBK123 » Sun, Jul 24, 2022, 4:31 PM UTC

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…

Yes, I was in an "agile" org that over-hired senior engineers and then expected them to just do regular "spade" work tickets.. but more quickly / more per sprint. No ownership of long running projects/tasks, no design/planning, just a constant stream of whatever ticket is at the top of the queue - GO.

Over the last 12 months, 55% of seniors have left. Most that remain have been at the firm 0-1 year.. The median senior now has 1 year on the team versus previous median of 3 years.

There's basically no institutional knowledge on the team anymore. Managers have now convinced themselves that all these green engineers are going to build v2.0.. however they are basically recommitting all the mistakes and suffering all the pitfalls that v1.0 did because.. no one is left to ask..

Re: How to drive away your best engineers

#228

Post by proxyon » Sun, Jul 24, 2022, 4:33 PM UTC

astura wrote: post #220

proxyon wrote: post #209

Earlier quoted context omitted.

Are you a people manager? If so, what is the turnover like on your team? I ask because the author is dead on and I've been in this industry for 10 years.

If you wanna make this a competition I've been in the industry for 16 years. I'm a technical lead which does have a little bit of people management responsibilities. Turnover on my team is probably well below average, we had two developers leave for other jobs in the last year out of 15 developers and one fired for poor performance. I can't remember anyone leaving the year before. To be clear, I don't think this arti…

Tech leads don't have people management responsibilities. An engineering manager with your perspective would quickly find themselves without any talented developers. I did not write the OP but you're coming in with the hot take that it doesn't matter how people feel about their jobs and that is by the far least controversial part of the article and one that you're out of sync with 90% of the community on.

Re: How to drive away your best engineers

#229

Post by dghf » Sun, Jul 24, 2022, 4:33 PM UTC

ironmagma wrote: post #177

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…

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.

But 90+% of the time, it'll be a basic use of add, checkout, commit, merge, pull or push, especially if you're a junior.

Re: How to drive away your best engineers

#230

Post by alephxyz » Sun, Jul 24, 2022, 4:45 PM UTC

tomohawk wrote: post #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 member…

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

I've worked with a few PhD's whose software engineering experience was limited to Matlab scripting. One even refused technical training because that's "not what they're interested in". Another co-worker with a masters still had no idea what they were doing after 4 years working there, often asking the same basic questions at a few weeks interval. Stuff like which branches to merge in a PR or questions that are answered verbatim in a readme file. Having to babysit educated people who refuse or are unable to learn is a great way to get demotivated. When those people start getting promoted to management positions and training junior employees is when things really start to derail.