Live data from Hacker News

How learned helplessness happens in engineering teams

okayhq.com

71–80 of 220 posts

Re: How learned helplessness happens in engineering teams

#71
post #61
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…

I know your frustration and pain, but as someone frequently on the other side of the equation trying to seek out answers, it is often difficult-to-impossible. Just this past week I was working through some infra setup challenges, I had to piece together half a dozen different documents, several README files, and a few archived slack threads. These sources often are outdated or even contradicted each other. Even after…

No, no. This sounds completely different. You searched out all the information you could, and still had no idea. That’s great (I mean, not great, ideally the necessary information would have been available, but that’s on the people providing the information).

The problem is people that have not searched or tried at all, and then ask their senior to please do their job for them.

Re: How learned helplessness happens in engineering teams

#72
post #22

> Another employee or their manager teaches them it's a normal situation at this company I have one particularly memorable situation where I tried to coach someone out of this. Sometimes the New Guy is the only one who can change something at BigCo, and the moment you convince them that fighting the bureaucracy is too hard, you've lost one of the few assets that person has. As the processes get more complex, the time…

Oh man, this is so irritating. I've been pushing for changes for years, and told, "No, it can't be done!" Then the New Guy comes in, recommends the same damn thing, and suddenly management is like, "Hey! That's a good idea!" I mean, I'll take the win since the change finally happens, but what a great way to demotivate your existing staff.

Re: How learned helplessness happens in engineering teams

#73
post #26

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…

> We've done two other releases in the past month and both required a day of troubleshooting to fix issues. I feel you, it's especially frustrating when your product has such fragile and bespoke testing that things break on a regular basis. Then, us devs have to spend valuable time just troubleshooting.

Maybe I misunderstand, but if a product breaks regularly under "fragile and bespoke" testing, won't it break just as often, and probably more often, under robust and comprehensive testing? And if the product fails tests, who better to "just" troubleshoot the problems than the developers? (Perhaps you mean things break after nominal testing and subsequent release, but that's just shifting the time when the issues are detected -- the product still has the issues either way. And if the issues will adversely and/or significantly affect the customer, I imagine one's employer would prefer that you set aside your non-troubleshooting valuable time and fix the issues.)

Re: How learned helplessness happens in engineering teams

#74
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…

I don't know if that was intended to be snarky, but yes, that's exactly what you should do, and people do in fact do that, and it often does work (although probably not as quickly as you'd like). How else am I supposed to know Bob and Joe are doing bad work? Should I count their LOC/day? Pore over their code and rely on my own (10 years out of date) opinion of it? In my humble opinion, there is one (1) good way to me…

It is somewhat meant to be snarky, but then again the original quote is exceedingly naive.

It describes very well the phenomenon but gives advice that I can only see ever working at BigCo. Where your team is huge and if you screw up there's another one down the hall.

The truth is most places that exhibit this level of helplessness often include a small team of 5 or 6, each with plenty of tenure. With no other lateral teams to move to.

Now you want the new guy to walk up to the boss and tell him that his drinking buddies for the past decade are the reason things are falling apart and he's an ineffective manager for not noticing it. You can play with the wording but that's the message.

In the real world we have political factors like seniority, favoritism, nepotism, tenure, and nevermind external factors.

In the real world the boss doesn't actually care if the team is working well or not. He only cares that the perception of the team is positive. If the new guy threatens the perception, he's gotta go. Nobody cares if it gets fixed. If nobody knows it's broken there's no need to fix it.

Let's have less articles like this one where we basically fire ourselves ostensibly for virtue signaling and more articles about how to socially engineer your way to the fucking top. Because let's face it, that's what it actually takes.

Re: How learned helplessness happens in engineering teams

#75
A couple of thoughts on this:

* A powerful tool against Pattern 2 (Complexity-related Learned Helplessness) is just cataloguing and quantifying things that cause wasted effort, i.e. a waste snake. Make a channel for it and encourage people to add items like "spent 4 hours reinstalling docker after corporate pushed an update" or "18 people X 2 hrs when the vpn was down" or whatever. Some of them may not be solvable, but quantifying the impact is the first step towards prioritizing a solution (or realizing that the solution isn't worth the effort).

* IME the solution to learned helplessness, somewhat buried at the end, is team autonomy. Self-managing or autonomous teams are the exact opposite of learned helplessness. It's nice to imagine your boss solving your problems with heroics ("Hey guys, I joined the on-call rotation this week and discovered it's terrible so I'm getting rid of it, hooray!") but waiting for that to happen sounds like more helplessness. A more realistic solution is that you solve this the same way you solve your software problems: figure out who the stakeholders are, figure out what problem they have, and devise a better solution.

Re: How learned helplessness happens in engineering teams

#76

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…

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…

The team lead seems to carry a lot but has a certain "job safety", so no incentive to share the release process.

In fact the team leader is a "hero" who extinguished a fire caused by other department.

Re: How learned helplessness happens in engineering teams

#77
post #74

Earlier quoted context omitted.

I don't know if that was intended to be snarky, but yes, that's exactly what you should do, and people do in fact do that, and it often does work (although probably not as quickly as you'd like). How else am I supposed to know Bob and Joe are doing bad work? Should I count their LOC/day? Pore over their code and rely on my own (10 years out of date) opinion of it? In my humble opinion, there is one (1) good way to me…

It is somewhat meant to be snarky, but then again the original quote is exceedingly naive. It describes very well the phenomenon but gives advice that I can only see ever working at BigCo. Where your team is huge and if you screw up there's another one down the hall. The truth is most places that exhibit this level of helplessness often include a small team of 5 or 6, each with plenty of tenure. With no other lateral…

Why do you want to "engineer your way to the fucking top" of a broken organization with a bunch of teams full of bad engineers managed by stuffed shirts who don't give a shit?

You may think I sound naive; I think you sound burned out. In my experience, it's pretty common for someone to say, "hey boss, Joe is really phoning it in these past few months, it's dragging the team down and you need to do something about it" and for the manager to either help Joe improve or fire Joe. And given how cynical your attitude is, I think you'd be very surprised at how often Joe actually does improve. Everyone will have the worst year of their career at some point, and it usually isn't the last one.

Re: How learned helplessness happens in engineering teams

#78

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…

What you're doing wrong, very honestly, is you suggest and 2 of your suggestions are losses (denying release).

Dont suggest, make enemies: send emails to both teams saying now it must be like that, lay the plan, pose a meeting to go through the plan and get yelled at. Once you get yelled at by the complainypants because what you tell them to do is too hard, now you can go to your manager and explain him they complain for the sake of complaining. The tech lead will get a earful and either fight you to his grave or admit defeat and let you do your reform grumbling waiting for you to fail.

I do that in a giant bank that cannot move without 10 approvers to everything, and the more these helpless teams fight me the more management put me in their midst to reform them ... and Im just a silly dev nobody and I can tell you the wonders one can do by just bulldozing. There are things to do if you fail eventually, which is to teach the higher ups to enjoy trying and failing, but that requires a bit of weaseling charisma :D

Re: How learned helplessness happens in engineering teams

#79
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…

I am working at company that just won a contract with a BigCo and it has to be one of the most frustrating experiences I have ever had. I was asked to test a configuration change and I was able to demonstrate that it worked locally in 15 minutes. Unfortunately, testing locally isn't enough so now I need to test it in the lab, but BigCo is so compartmentalised that it can weeks even to organise a meeting where all the stakeholder can get together and talk about what needed to be done to get the configuration changed in the lab.

We've had working sessions where the moment there was an issue, the developers at BigCo said that they need to talk to someone on some team and they wrap up the meeting for the day -- even if we had just got started. It's gotten to the point where we will have project managers in the working session -- essentially babysitting -- to stop the devs from just giving up.

The amount of stonewalling I've seen is insane. We were trying to address an issue with our integration and I was told that a particular configuration on the client side was impossible, or maybe that we needed a new license, or perhaps we needed to contract to another vendor and it's going to cost half a million dollars, or whatever other excuses they could come up with.

So I asked them what product BigCo used, I looked up the documentation, I sent an email with 12 steps on how to make the configuration change, I got on a video call with my contact at BigCo (and his boss to make sure he showed up) and I literally walked him through the setting up the configuration.

I just don't understand how you get to the point where that's business as usual.

Re: How learned helplessness happens in engineering teams

#80
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…

It has nothing to do with "BigCo" or not.

If you work in a small company, pretty much any boss will be happy to hear feedback like "Hey, it looks like there's an impediment to smooth work, and the team has gotten used to it, but it's costing us". Bonus points if you propose a solution.(If your manager isn't happy to hear that, it's time to leave, because small companies closing their eyes to this have a tendency to go down in flames)

But you'll definitely need to learn to take the blame out of your communication. Learned helplessness is a technical term, it doesn't mean "Bob and Joe are helpless". And your manager not noticing a problem is hardly "you just kinda watch it happen".

Frame it as a possible improvement to what the team can do - because that's what it is. Yes, you might get turned down. And if you repeatedly get turned down, you have a choice to make.

Post reply on HN