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

151–160 of 220 posts

Re: How learned helplessness happens in engineering teams

#151

Post by rewgs »

agumonkey wrote: post #39
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 is why I .. struggle to function in society. There are tribal forces at play that are beyond me. Or require me to play games I don't want to play. Social tissue is a strange medium and most of the time it's a friction generating engine. People complain, time passes on, nothing happens, repeat.

Boy, this resonated.

Re: How learned helplessness happens in engineering teams

#152

Post by kuu »

gyulai wrote: post #150

"Learned helplessness" as a psychological phenomenon relates to situations where the individual assumes they are powerless to change certain things, but they actually are not. A lot of the time, when one is an individual contributor in an engineering team, that is not the case. Rather it is the case that you really are powerless. That's an important distinction to make. Don't assume that your struggle is with interna…

I agree, and I think until certain point you need to assume that you'll be powerless in some aspects. You cannot change it all and you need to accept certain amount of being powerless.

The key is to find the proper amount...

Re: How learned helplessness happens in engineering teams

#153

Post by [deleted] »

jreese wrote: post #105
hsn915 wrote: post #96

Earlier quoted context omitted.

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 e…

[deleted]

Re: How learned helplessness happens in engineering teams

#154

Post by ownagefool »

vimwizard wrote: post #138
JohnBooty wrote: post #108

Earlier quoted context omitted.

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…

>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. I came to this conclusion after watching the place I work at for 2 and a half years fail to implement any of the grand ambitions management had in their heads. We wanted code review, pull requests, build…

I think they key is to find people who have put effort into figuring out what good is, and are frustrated and care enough to enact change.

Similarly to your org not having a dedicated DX team being the reason, dedicated teams will happily dissapear into a void of non-delivery as their purist vision, unconnected with reality, will simply never apply to your stack, and thus you'll never use it.

End of the day, different things work and fail. The key is almost always the quality of people, their motivation and how many road blocks you put in front of them.

Re: How learned helplessness happens in engineering teams

#155

Post by kuu »

afarrell wrote: post #88
zelon88 wrote: post #62

From the article; > Hold managers accountable: one of the key responsibilities of leaders is to create positive change for their teams. Once you notice a situation where you think everyone is in learned helplessness mode, make sure to notify your manager and follow-up until the problem is addressed. "Hey boss, I noticed that Bob and Joe are really helpless at their jobs and that you just kinda watch it happen." Yeah…

Whom do you talk to if you notice it in the CTOs?

To HR of the next company...

Re: How learned helplessness happens in engineering teams

#156

Post by ownagefool »

NAHWheatCracker wrote: post #49
Thrymr wrote: post #31

Earlier quoted context omitted.

> My manager doesn't know anything about the code, my project, or the release project. What... does he know? Fine, he doesn't get into the code itself. But the project and its dependencies? Yikes.

He's the scrum master for other projects and he deals with things like hiring.

Yeah, I'd hard pass on the scrum master picking colleagues.

If the person hiring isn't technical, they likely aren't qualifying competancy, nor are they likely capable of building an Engineering culture.

Re: How learned helplessness happens in engineering teams

#157

Post by antman »

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…

For a person of many years of experience your friend is the problem. He has agreed to push untested code which is his responsibility, enabled other teams to work out of schedule and him producing dangerous results. All these without any indication that he sought approval from upper management. Why would you use the word "complaining" when communicating an issue? State the facts and how they diverge from the formal process, flag parts of the process that are problematic due to lack of resources of consistency, put them in an email with a "default" course of action if not answered and without using "I" or "They", use passive voice (tone). Keep the score in writing as an informal calendar linked to the respective communications. Cc the manager. Obtain bliss, people will fret then they will forget.

If the team is disfunctional or the manager bad consider changing work. Not only due to the dysfunction but because a good team and manager is part of ones' mentoring, and it hampers ones' growth. At least now you gain some reflexes that will assist you in the future, if you chose to move on.

Re: How learned helplessness happens in engineering teams

#158

Post by nyulmalac »

JohnBooty wrote: post #113
geoduck14 wrote: post #109

Earlier quoted context omitted.

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

Hiring Rails devs? I'll work for you! Seriously, though: I firmly believe that most managers do think and act like you do. (I've been in lead and/or management-lite roles myself; I don't view management as some weird or evil "other") But, I think it only works if that sort of change is valued all the way up the org chart and folks at each level are empowered, incentivized, and motivated to address the pain points of…

I‘m working in a strongly hierarchical org, whit very high N number. What shocking me and blocked good ideas or solutions is that: The persons in charge, empowered to make decisions are so far from reality. And the outcome of their decisions has no effect on their lives… And not because they are evil, just unable to understand the problem. (Once some guy asked, why we put bugs in the code…) Now I fight to change this doing a half management half coder job. But thats hard, I am close to total burnout…

Re: How learned helplessness happens in engineering teams

#159

Post by Tade0 »

There's a side to this that I feel wasn't explored in the article: some people want to be put in such a situation, because it makes them appear busy and thus not layoff material. They have bills, mortgages, private schools to finance and prefer the status quo.

Moreover there are people who want their team to be like that, because they enjoy not having their decisions second guessed by any of the team members. These people in turn suck up all the autonomy that the team is given and produce the NIHest examples of architectural astronautics possible.

I've been in several projects where this was the case. The usual scenario starts off with me barging in and crying "cease this madness!". Replies range from indifferent through apologetic to hostile.

Eventually, after shoehorning too many refactors into my assigned tasks I either get fired or quit.

I now actively avoid such places because I'm simply not cut for such work.

Re: How learned helplessness happens in engineering teams

#160

Post by nyulmalac »

bxparks wrote: post #9

I don't think it's "learned helplessness". It is a rational, calculated tradeoff decision. In many situations, it is more painful to fix the underlying layers of technical debt, and more time consuming to fight the push back from the various teams that own different parts of the technical stack. It's far easier to just silence the pagers while on pager duty for that week. It's also caused by misaligned incentives. At…

Oh this hits close to home. At my BigCo I have seen tremendous amount of great tools/product landed in the trash bin, because it was only interesting until somebody get the promotion… Immense amount technical dept and lack of viable business model lead to fast death of great ideas… What a huge waste…
Post reply on HN