Live data from Hacker News

How learned helplessness happens in engineering teams

okayhq.com

51–60 of 220 posts

Re: How learned helplessness happens in engineering teams

#51
post #32

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…

The tech lead wants to be “a hero”. It’s a common theme, the problems are well known when you have ppl hero-balling.

He actually called himself out for this during the conversation. I'm not sure how to convince someone to stop doing that.

Re: How learned helplessness happens in engineering teams

#52

Earlier quoted context omitted.

What is the difference between your team lead's bad reasons not to push internally for a better system: > The other team doesn't know how to do the release. > He wants to be a "team player" so he can't deny the release. > Project managers will never allocate time to improve the release process. and your good reasons not to push internally for a better system? > My manager doesn't know anything about the code, my proj…

I do push for changes, such as bringing ideas to the team lead and bringing these things up with my manager (hence being brought up in reviews). There is a self-reinforcing aspect to learned helplessness in teams, as you've pointed out.

In my experience, this sort of thing is why good leadership has an outsized impact.

Re: How learned helplessness happens in engineering teams

#53
This is one of the things I like most about my current job, I feel like we are all able to fix stuff, and everyone is open to questioning what we are doing and how we do it. If it's not working, or there's a better way then we change. People don't take it personally, everyone seems open to suggestions.

I've been here for 2 years now, and while there's still things to be improved in both the code base and the way we do things, we've been making steady improvement over all that time, all while managing to deliver on new features. Even at times when the progress might slow, just knowing that there is some improvements happening, and more will happen when resources allow, creates a whole different mindset from previous places where I've just given up and left.

Re: How learned helplessness happens in engineering teams

#54
post #6

Earlier quoted context omitted.

Unfortunately people are very conflict averse and will avoid giving that sort of feedback if it means an uncomfortable conversation (particularly if whoever came up with the process is still employed). Even anonymous surveys are not really that useful because the most useful criticism stays exclusively inside peoples' heads. As a manager you have to have really good EQ to be able to read this sort of stuff implicitly…

> people are very conflict averse and will avoid giving that sort of feedback I'm not (that) conflict averse - I'm perfectly happy to suggest, when asked, that we could deliver better results faster if we could spend some time fixing some non-customer facing problems, had better tools, and had a testing environment that was closer to the production environment. I have no trouble saying those things, but I've never se…

Indeed. The learned helplessness comes in after you try make improvements over and over again, and still no action is taken. You assume, usually correctly, that you're helpless to effect change so you give up.

The main driver of learned helplessness is those who refuse to listen to feedback or act on feedback.

Re: How learned helplessness happens in engineering teams

#55

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…

A hazard of meetings is that the best debater owns the show. It's quite possible that the tech lead thought his idea was straightforward enough that he didn't expect it to be debated, and wasn't prepared for it.

I don't introduce new information at meetings unless I am ready to back it up, which usually takes an hour of preparation for every hour of meeting. If time is of the essence, it's often better to settle things in hallway conversations or via web chat.

Re: How learned helplessness happens in engineering teams

#56

This reminds me of a story I've read some time ago, about some monkeys and bananas. A group of monkeys in a room. In the center of the room is a tall pole with a bunch of bananas suspended from the top. Every time a monkey tries to reach the bananas it is hit with a torrent of cold water from an overhead shower. Eventually, the monkeys learn that something bad will happen if they climb up the pole so they just sit an…

That might be just a story, rather than something that actually happened. https://www.throwcase.com/2014/12/21/that-five-monkeys-and-a...

Re: How learned helplessness happens in engineering teams

#57

My learned helplessness story - Another engineer fancies himself as the gatekeeper of our codebase. Nitpicks on PRs all the time. Always tries to change something. This time around, an engineer produced a fantastic design. But this gatekeeper engineer had something else on his mind. The gatekeeper did not even communicate his thought process but continued asking ridiculous questions. Later we found that the gatekeepe…

did you let their manager know? Especially valid with data that shows "look, before, ppl tried to follow process X, and now, as you can see, nobody even tries." Data, data, data. Management likes data.

Re: How learned helplessness happens in engineering teams

#58

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…

[deleted]

Re: How learned helplessness happens in engineering teams

#59
I’d like to add a #3 to the list, which I’ll half-jokingly name “ruined by working at a large company learned helplessness”

My company is small and we have very small teams (1-4 people). One person recently hired has been working at successively larger companies over the years (I’ve known him for a long time). Sometimes he’ll do something like this: stop working on a task he’s been assigned, say “test data needed”, and just totally bow out until someone else makes it for him.

As I said, this is a small team. He knows how to make his own test data, and sometimes there is even a UI dedicated to making the kind of data he needs. But he has learned from working at larger companies that he can sometimes just pass his work onto someone else (perhaps even an entire other team dedicated to the thing he doesn’t want to do) instead of stepping up to the plate to do such a trivial thing on his own.

To be clear, this is just an example (which has actually happened) and other similar “not my job” thinking/actions have shown up repeatedly. Many years ago we worked together on a small team and he was not like this at that time.

Re: How learned helplessness happens in engineering teams

#60
post #38

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…

Can't your tech lead suggest that he'll do the release under the condition that someone from that other team pairs with him so that they learn how to do it?

Yeah, at a previous job, I had inherited responsibility for maintaining a particular poorly tested (and hard to test—lots of API dependencies), widely-used library. Most changes were contributed by users and I managed by reviewing new code and tests as carefully as I could.

At one point, one particularly hard-pressed user wanted to make really sweeping changes to the library and had limited time. I stalled and stalled to try and review all their changes and convince myself they were going to work, and they got more and more agitated, and my TL (who was himself frustrated by how much of my time this was consuming) told them "you can merge whatever you want if you take over maintaining it". So that's what happened, and everybody left happy.

Post reply on HN