How learned helplessness happens in engineering teams
1–10 of 220 posts
Re: How learned helplessness happens in engineering teams
#2I have found that the biggest thing that can be done is to ask your people over and over again. And then also genuinely care about the situation and make it your goal to communicate to others that the problem exists.
Re: How learned helplessness happens in engineering teams
#3> Complexity-related Learned Helplessness
I've gotten used to just accepting that every job I have will involve a code base that uses up way too much memory to run in a debugger and doesn't have (or allow for) unit tests.
Re: How learned helplessness happens in engineering teams
#4Related:
Jeff Bezos on Learned Helplessness (2005): https://www.youtube-nocookie.com/embed/WhnDvvNS8zQ
Paul Graham on Schlep Blindness (2012): http://paulgraham.com/schlep.html
Re: How learned helplessness happens in engineering teams
#5Read Dan Luu's article about normalization of deviance, or Dan Na's talk "pushing through friction".
Re: How learned helplessness happens in engineering teams
#6I have found that the biggest thing that can be done is to ask your people over and over again. And then also genuinely care about the situation and make it your goal to communicate to others that the problem exists.
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 from your employees because it's usually not coming out explicitly.
Re: How learned helplessness happens in engineering teams
#7> Complexity-related Learned Helplessness I've gotten used to just accepting that every job I have will involve a code base that uses up way too much memory to run in a debugger and doesn't have (or allow for) unit tests.
There's a certain amount of "YOLO" fast-and-fragile development I'm willing to tolerate or negotiate. It's not like I have all the answers, and everything is a team effort.
But when I'm called upon to work entirely without tests, or with inadequate backups, or otherwise in ways that create a scenario where every keystroke I make holds imminent potential for disaster, I quit. I can do trapeze acrobatics if you let me use a net. If you insist that I must not use a net, I'm not willing to live with that constant stress.
Re: How learned helplessness happens in engineering teams
#8> Complexity-related Learned Helplessness I've gotten used to just accepting that every job I have will involve a code base that uses up way too much memory to run in a debugger and doesn't have (or allow for) unit tests.
There's a certain amount of "YOLO" fast-and-fragile development I'm willing to tolerate or negotiate. It's not like I have all the answers, and everything is a team effort. But when I'm called upon to work entirely without tests, or with inadequate backups, or otherwise in ways that create a scenario where every keystroke I make holds imminent potential for disaster, I quit. I can do trapeze acrobatics if you let me…
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 necessarily cared as long as things got fixed).
Companies that subscribe to YOLO-level development usually already _know_ that and with it, comes a certain understanding that shit will break, it's just minimizing the blast radius by learning/knowing the code bases and leaning on those with more experience.
Re: How learned helplessness happens in engineering teams
#9I 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 most BigCo, people don't get promoted for fixing technical debt. They get promoted for launching shiny new features and products.
Re: How learned helplessness happens in engineering teams
#10Has anyone actually overcome any of these bad situations? Or has there been a situation where “So and so quit because X, we need to change X.”
You can’t change an org from the outside, but it’s also difficult to change it from the inside.