How learned helplessness happens in engineering teams
Just today, my team had a developer meeting.<p>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&#x27;s the only person who knows how to release it. The other team didn&#x27;t communicate until today that a release is necessary.<p>We&#x27;ve done two other releases in the past month and both required a day of troubleshooting to fix issues.<p>Both of us have been working at this company for about 3 years and we both have over a decade of experience in software development.<p>When he finished complaining, I started asking questions and making suggestions about how we can improve things.
- Push back on the team that needs these urgent changes. Let them learn to do the release.
- Deny the release since they didn&#x27;t communicate earlier.
- Improve the release process.<p>Everything I suggested was just flatly denied as impossible. 
- The other team doesn&#x27;t know how to do the release.
- He wants to be a &quot;team player&quot; so he can&#x27;t deny the release.
- Project managers will never allocate time to improve the release process.<p>I feel strange because I&#x27;ve seen this same thing for my whole career and I still try fight for what&#x27;s right when others appear to moan and carry on.<p>However, my experience tells me that bringing this stuff to my manager is even worse. My manager doesn&#x27;t know anything about the code, my project, or the release project. He may assume it&#x27;s complaining for the sake of complaining. It has been used as ammunition in reviews against me.<p>Learned helplessness sucks and I wish I could do more. I don&#x27;t think either of the suggestions in the article are feasible for many ICs. Teams are ambivalent to making improvements, and retrospectives carry very little weight. Managers are above the fray and won&#x27;t be held responsible for by people below them.