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

How learned helplessness happens in engineering teams

okayhq.com

Post reply on HN
Print view View original

101–110 of 220 posts

Re: How learned helplessness happens in engineering teams

#101

Post by TeeMassive »

> In a word, we could call this resignation by a thousand cuts, which makes it unexpected for managers.

Eh eh eh, this feels like reading the Phoenix Project all over again: "are you me!?"

My first job out of university was a job at a BigCo, right in the middle of a Death March. Nobody at the beginning of the project remained. Most people who "finished it" were new comers like me or "team leads"(tm).

The three years I was there my teammates and I tried to push numerous changes and much needed improvements. Every time we had push back, especially by the team leads who literally shouted everyone down; I now have a profound hate for people with loud soprano voice by I digress.

I tried my best to raise up problems, find their roots and solutions. I mean, I couldn't be subtle that I wasn't satisfied with what I have seen.

And yet when I quit, my colleagues all could point out reasons of why I quit and yet none expected that I would leave.

As the article pointed out, you should quit early and make sure your reasons are known; your old colleagues will owe you and this is pretty much the only way they can get the message.

Re: How learned helplessness happens in engineering teams

#102

Post by xwdv »

junon wrote: post #92
NAHWheatCracker wrote: post #19

Just today, my team had a developer meeting. The tech lead started out by complaining about how he has to do an untested unplanned release today because another team made some urgent changes. He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary. We've done two other releases in the past month and both required a day of troubleshooting to fix issue…

> It has been used as ammunition in reviews against me. Quit. This is a sign of a broken and unfixable workplace.

You don’t know other aspects about his job. If the work is easy and the pay is good there’s no point in quitting unless you aren’t working from home or there’s a substantially better offer.

Re: How learned helplessness happens in engineering teams

#103

Post by junon »

xwdv wrote: post #102
junon wrote: post #92

Earlier quoted context omitted.

> It has been used as ammunition in reviews against me. Quit. This is a sign of a broken and unfixable workplace.

You don’t know other aspects about his job. If the work is easy and the pay is good there’s no point in quitting unless you aren’t working from home or there’s a substantially better offer.

They're mentioning it here as though they're unhappy. Doesn't sound like someone that's beneficial for them outside of funds, if anything.

Re: How learned helplessness happens in engineering teams

#104

Post by halfmatthalfcat »

Kaze404 wrote: post #85
halfmatthalfcat wrote: post #8

Earlier quoted context omitted.

Maybe it's just me, but not having the net provides some level of "fun". Most of the projects/companies/teams I've worked on didn't have tests, adequate backups or had scenarios where errant keystrokes blow up production but it's nothing that has been world-stopping and these jobs rarely involved anything were downtime equated to real harm (outside of the economics of the companies themselves, but usually nobody nece…

I will never understand this position. My life are already chaotic enough without factoring in the work-related part of it, it makes no sense to me why someone would actively invite chaos like the one you're describing. I'm much more excited by solving interesting problems or creating useful things than by having my work day interrupted by a production error that needs to be fixed immediately.

You're not necessarily inviting chaos, you're making a cost/benefit analysis of moving faster or safer. I prefer to move faster.

Moving safer takes up a lot of, imo, unnecessary time with dubious payoffs. I'd personally rather live on the side of YOLO and ship a lot then hem/haw over getting certain % unit test coverage (and the maintenance costs that come with that in the face of uncertain requirements).

Re: How learned helplessness happens in engineering teams

#105

Post by jreese »

hsn915 wrote: post #96
jreese wrote: post #40

As a member of a core infra/"foundation" team, the biggest drain on my soul is the number of other engineers that are helpless, or never learned how to find solutions on their own. They never search wikis, look for similar posts on internal groups, or even read the error message from the tool that tells them exactly how to fix the problem they're asking about. When the culture has become "google everything", but you…

Think about it from the other side: Dealing with the infrastructure is your job. You know the ins and outs. It doesn't seem complicated to you. For someone who is dealing with the application logic, having to context switch to infrastructure is painful. I have no idea how you have set things up. When I read your documentation I'm just baffled at the sheer amount of complexity. I don't want to deal with it. It's not m…

The drain I am talking about is a complete lack of due diligence on behalf of those asking for my help (and my limited time/attention).

When the error message contains a clear message and a URL with step-by-step instructions, and the person in question just pastes the full error message including the URL, and asks "what do I do?"

When a problem can be solved by responding with "please follow the instructions in the error message you sent me".

When someone makes an internal group post asking "how do I do X?" and the pinned post that was right below the submit button contains a summary and link to detailed step-by-step instructions titled "how to X".

Re: How learned helplessness happens in engineering teams

#106

Post by RNCTX »

jcims wrote: post #81
firebaze wrote: post #23

Earlier quoted context omitted.

Quite often "technical debt" from an engineer perspective is an asset from the leadership perspective. Make of it what you want, but code which is bad from a customer perspective usually doesn't live until it's legacy. And sometimes the technical debt cloud disappears after fully understanding the business rules and special cases which were the root cause for the code in question. This often gets overlooked and may (…

We need a different word. ‘Technical debt’ implies some kind of objectively quantitative zero sum game, when it is anything but.

> We need a different word. ‘Technical debt’ implies some kind of objectively quantitative zero sum game, when it is anything but.

Not only that, but it's been around long enough that bad management types throw the term around. That's a sure enough sign that whatever usefulness it had has been far outlived.

Re: How learned helplessness happens in engineering teams

#107

Post by SaltyBackendGuy »

Iefthandrule wrote: post #66
mixmastamyk wrote: post #64

Earlier quoted context omitted.

All you have to do is say no once in a while. No, don't bring the company to a halt with a tantrum. Just insist on getting one thing fixed a month and nine months from now everyone will be a lot happier.

Can't teach everyone to have a backbone. Heck, nerds are infamous for being easy to manipulate.

Anecdotally, the most manipulative individual I've ever met was a nerd.

Re: How learned helplessness happens in engineering teams

#108

Post by JohnBooty »

NAHWheatCracker wrote: post #19

Just today, my team had a developer meeting. The tech lead started out by complaining about how he has to do an untested unplanned release today because another team made some urgent changes. He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary. We've done two other releases in the past month and both required a day of troubleshooting to fix issue…

This hit so close to home for me. At my last two jobs, I've simply burnt out from hitting this sort of wall over and over.

    Everything I suggested was just flatly 
    denied as impossible 

    [...]

    I feel strange because I've seen this same thing 
    for my whole career and I still try fight for 
    what's right when others appear to moan and carry on.
For anybody (100% rightfully!) wondering if it's my fault: (1) I've been consistently praised in reviews as a good communicator (2) I always operate by the maxim "don't just complain -- instead, offer solutions" and I see that you do too. (edit: That's not to say that I couldn't be communicating things better. Certainly, I don't believe I've reached some level of perfection there)

I think the reality is that this kind of change can't originate from the in-the-trenches folks at the bottom of totem pole. Management will never let individuals waver from their short term goals.

The only times I've seen developer pain-points successfully addressed in a sustainable way, it's because there was a dedicated team allocated to that sort of thing: a "developer experience" team, or some equivalent.

(Although, the issues you ran into are kind of an org issue in addition to a developer experience issue)

Re: How learned helplessness happens in engineering teams

#109

Post by geoduck14 »

JohnBooty wrote: post #108
NAHWheatCracker wrote: post #19

Just today, my team had a developer meeting. The tech lead started out by complaining about how he has to do an untested unplanned release today because another team made some urgent changes. He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary. We've done two other releases in the past month and both required a day of troubleshooting to fix issue…

This hit so close to home for me. At my last two jobs, I've simply burnt out from hitting this sort of wall over and over. Everything I suggested was just flatly denied as impossible [...] I feel strange because I've seen this same thing for my whole career and I still try fight for what's right when others appear to moan and carry on. For anybody (100% rightfully!) wondering if it's my fault: (1) I've been consisten…

>I think the reality is that this kind of change can't originate from the in-the-trenches folks at the bottom of totem pole.

I'm a manager. Please. PLEASE don't believe this. In-the-trenches folks ARE powerful. Really. I promise. I can't implement change if YOU don't do it. I don't know what sucks if YOU don't tell me.

I NEED you to help me make things better.

Re: How learned helplessness happens in engineering teams

#110

Post by cm2012 »

The biggest cause of this in my experience is too much codified process, not too little. This is cause #1 in this article, which is vindicating.

Adding process is a delicate balance and most large companies err on too much of it.

Every checklist you add, every new approval, every sheet that needs some rows filled out, every brief - all of them add friction.

New projects are inherently speculative, and most things don't move the company's bottom line. The power law that says 10% of work get 90% of results is true. Friction means whoever is doing the work is just a little less likely to propose a bold test, to push on a tweak they notice, because they know it will become an ordeal.

Obviously you can't be 100% wild west and some process is needed. But you have to be very very careful when adding it.

Post reply on HN