[HN Gopher] How learned helplessness happens in engineering teams
___________________________________________________________________
How learned helplessness happens in engineering teams
Author : tomasrb
Score : 147 points
Date : 2021-10-31 21:36 UTC (2 days ago)
(HTM) web link (www.okayhq.com)
(TXT) w3m dump (www.okayhq.com)
| hinkley wrote:
| > 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 between onboarding
| and being able to tackle projects as an IC grows and grows. That
| outsider perspective may be one of the few things they're good
| for. That outsider perspective may be the only thing that ever
| reduces that gap.
|
| I can't help but feel like people caught in that uncanny valley
| are damaged by being there, and one of the only ways I often have
| to improve morale is to point out how they're doing things -
| important things - that the Curse of Knowledge keeps me or my
| peers from doing well.
| Yhippa wrote:
| I 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.
| b9a2cab5 wrote:
| 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.
| commandlinefan wrote:
| > 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 seen
| any action taken on any of them.
| justin_oaks wrote:
| 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.
| 29athrowaway wrote:
| Read Dan Luu's article about normalization of deviance, or Dan
| Na's talk "pushing through friction".
|
| https://blog.danielna.com/talks/pushing-through-friction/
| _rtld_global_ro wrote:
| One of the best talk I haven't seen for quite a long time,
| thanks for sharing.
| commandlinefan wrote:
| > 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.
| rectang wrote:
| 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.
| commandlinefan wrote:
| > I quit
|
| I did that early on. Then again, because the next place was
| the same. Then again, because the next place was the same. 10
| places later, I finally realized they're all the same.
| rectang wrote:
| That's regrettable. Investing in reliability and redundancy
| is an optimization problem, resources are always limited,
| it's natural for there to be tension and I've grown
| accustomed to that. My experience has been varied, with
| some organizations investing more than others.
| halfmatthalfcat wrote:
| 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.
| morelisp wrote:
| The fun should come from solving fundamentally difficult
| problems, not from someone fucking up a CRUD response
| because they didn't properly test their filter parsing.
| fwip wrote:
| Lots of companies have no "fundamentally difficult
| problems" when it comes to their software. Lots of
| software developers don't have any of these problems to
| solve.
|
| (I'm also against this "YOLO because it's fun" attitude,
| though.)
| vjust wrote:
| YOLO-level development is a slippery slope... We had a case
| where 2 backends from 2 teams needed to interoperate.. to
| support a much talked-up UI/functional feature that was
| supposed to make our product standout from rivals. What was
| implemented was a rube-goldberg like contraption on the
| backend, where I dreaded being on-call as the talked-up UI
| feature was rolled out to more and more customers.
|
| Oh yeah, we had unit tests all right, fragility didn't
| prevent that since you couldn't commit otherwise.
|
| So there was no safety net. Just a constant dread of
| customers actually using the feature. So "fast-and-fragile
| development" resulted in a worst-case scenario as far as
| engineers were concerned.
|
| The author says : "Their reports won't tell the manager
| that they are having a terrible on-call experience". This
| was exactly what happened to me. And I quit one day, this
| was a big factor, two weeks out of a month (in my rotation)
| I'd be on the hook for supporting this morass of problems.
| rectang wrote:
| > _it 's nothing that has been world-stopping_
|
| Well then you're talking about a completely different
| scenario than I am.
| ddek wrote:
| I could definitely YOLO out a change when I worked on
| code used by 100 people. When it was used by 10000, an
| error every now and then is forgivable. Now, if I make an
| error in a deployment I could stop 10,000,000 from using
| my systems. Similar outages have made newspapers. Even
| then, compared to FAANG scale I'm still playing with
| toys. The fastly outage was top story on the BBC while it
| was happening.
| halfmatthalfcat wrote:
| I would hope that world-stopping software (banks,
| critical infrastructure, healthcare, etc) have tests and
| all the things to prevent catastrophic error. For the
| rest of us, breaking things here and there in the name of
| moving faster is (anecdotally) more fun.
| cntainer wrote:
| 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 and don't even try again.
|
| If a new monkey is added to replace an old monkey, it will of
| course try to go for the bananas. But the original monkeys will
| grab and drag it down before the punishment is even triggered.
| After a while, the monkey gets the message and it stops trying.
|
| Repeat the action of adding a new monkey in place of an old one
| enough times and you will reach a point where none of the monkeys
| know why they shouldn't get the bananas but they still won't try.
|
| The story concludes by stating that even if we remove the shower
| at this point it won't really make a difference. The learned
| behavior is already deeply ingrained in the culture of the group.
|
| Funny enough, I've seen this type of issue in many human
| teams/projects. And usually the inertia is far too strong for
| just a couple of engineering "monkeys" to radically change things
| if they don't get support from a few management "monkeys".
| erehweb wrote:
| That might be just a story, rather than something that actually
| happened. https://www.throwcase.com/2014/12/21/that-five-
| monkeys-and-a...
| nine_zeros wrote:
| 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 gatekeeper engineer wanted to change the
| entire design to his own, even if his own design had major flaws.
| Wasted a whole quarter just because the gatekeeper didn't seem to
| want to "concede". He would much rather have engineers make bad
| designs than accepting his own missteps. The author of the design
| fought vehemently at the expense of their own time and energy. To
| what end?
|
| Other engineers on the team have forever stopped producing design
| docs. Learned helplessness.
| sethammons wrote:
| 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.
| NAHWheatCracker wrote:
| 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 issues.
|
| 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.
|
| 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't communicate
| earlier. - Improve the release process.
|
| Everything I suggested was just flatly denied as impossible. -
| 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.
|
| 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.
|
| However, my experience tells me that bringing this stuff to my
| manager is even worse. My manager doesn't know anything about the
| code, my project, or the release project. He may assume it's
| complaining for the sake of complaining. It has been used as
| ammunition in reviews against me.
|
| Learned helplessness sucks and I wish I could do more. I don'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't be held responsible for by people below them.
| Thrymr wrote:
| > 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.
| NAHWheatCracker wrote:
| He's the scrum master for other projects and he deals with
| things like hiring.
| atmosx wrote:
| The tech lead wants to be "a hero". It's a common theme, the
| problems are well known when you have ppl hero-balling.
| NAHWheatCracker wrote:
| He actually called himself out for this during the
| conversation. I'm not sure how to convince someone to stop
| doing that.
| scottlilly wrote:
| I left my last contracting project around six weeks ago because
| of encountering this attitude - yet again.
|
| I wrote my first custom business program 40 years ago. Since
| then, I've only been on two teams that didn't exhibit this
| attitude.
|
| At this point, I really don't want to continue programming for
| a living, precisely because so many people adamantly refuse to
| fix problems with painfully obvious (and quick and cheap)
| solutions.
|
| I've given up on trying to get people to change their behavior.
| If I do continue programming, my approach will be to try to
| find one of those rare teams that actually changes and
| improves.
| ljm wrote:
| > Everything I suggested was just flatly denied as impossible
| [...] He [tech lead] wants to be a "team player" so he can't
| deny the release
|
| > The tech lead started out by complaining about [...]
|
| Tech Lead doesn't realise that he's a leader, and good leaders
| build good teams.
|
| A good leader would block a release if they knew it was fucked
| and then they'd work to unfuck it, they wouldn't let it go to
| prod because they wanted the warm fuzzies.
|
| The described 'tech lead' sounds more like a yes man.
| firebaze wrote:
| Most of the time managers are trying to be helpful, and most of
| the time they do in fact understand quite a lot of the
| background of a project.
|
| I'd suggest to try to see the situation from their perspective,
| which you maybe already did, but sometimes this helps
| understanding a perceived lack of action.
| JTbane wrote:
| > 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.
| thaumasiotes wrote:
| 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 project,
| or the release project.
|
| > He may assume it's complaining for the sake of complaining.
|
| > It has been used as ammunition in reviews against me.
| kevinmgranger wrote:
| The last bullet of each scenario is fundamentally different,
| and the ammunition bit is the most important part.
| NAHWheatCracker wrote:
| 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.
| afarrell wrote:
| In my experience, this sort of thing is why good leadership
| has an outsized impact.
| aflag wrote:
| 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?
| wcarss wrote:
| This seems like a really good idea.
| agumonkey wrote:
| 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.
| analog31 wrote:
| 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.
| jreese wrote:
| 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 can't google for internal
| tools/tech problems, suddenly folks have no idea how to read
| error messages, debug a stack trace, or solve any problem without
| hand-holding from a senior engineer. I've been at BigCo for nine
| years now, and it has only gotten worse as the size of the
| company has grown exponentially.
| tppiotrowski wrote:
| I agree with this and would add Slack to the equation. It's
| just faster to ping a senior engineer on Slack than to spend 5
| minutes looking into an issue.
|
| I've also seen new hires burn an entire week because they were
| afraid to ask a question.
|
| But I think the balance has definitely shifted towards asking
| too much help...
| jreese wrote:
| When I started at BigCo, the recommended policy was to spend
| two hours trying to solve it yourself, including searching
| the wiki, debugging code, etc. If you hadn't made any
| progress in that time period, then ask someone from your own
| team or make a post in a related internal support group. Only
| after exhausting that route, and getting no help, should you
| escalate to the team/oncall that owns the tool/service you
| are having problems with. It seems that culture has been
| lost.
| the_arun wrote:
| We need to add Team Politics as well. We often spend more time in
| right articulation to keep it diplomatically correct and
| communicate a risk/problem/concern - if it involves multiple
| teams. People often do not accept this communication and it goes
| for several iterations before they all arrive at work breakdown.
| Not sure there is a way to measure these churns.
| noneeeed wrote:
| 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.
| bxparks wrote:
| 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 most BigCo, people
| don't get promoted for fixing technical debt. They get promoted
| for launching shiny new features and products.
| firebaze wrote:
| Quite often "technical debt" from an engineer perspective is an
| asset from the leadership perspective. Make of it what you
| want, but code which is bad from a customer perspective usually
| doesn't live until it's legacy.
|
| And sometimes the technical debt cloud disappears after fully
| understanding the business rules and special cases which were
| the root cause for the code in question. This often gets
| overlooked and may (edit) lead to refactoring/rewrite
| approaches which ultimately fail. As everyone knows, not a rare
| occurrence.
| hinkley wrote:
| Technical debt is all of the forms of self-sabotage that don't
| have clear metrics associated with them.
|
| If they had clear, unimpeachable metrics, then you could
| increase your status by fixing them. Since they don't, few
| people engage with them. Worse, engaging with some of these
| problems can _lose_ you status, and so tackling them becomes a
| form of self-sacrifice.
| WalterSear wrote:
| Hinkleys's law: A measure that becomes a target might cease
| to be a good measure, but a target that isn't measured ceases
| to be a target at all.
| lumost wrote:
| A thousand times this. Good, steady software ownership is
| generally _not_ what leadership wants.
|
| Big new features are, it's infinitely easier to build process
| improvements into new projects vs fighting for improvements in
| existing areas.
| qaq wrote:
| The equation is skewed by the fact that quitting will get one a
| 20% bump in comp vs fighting the system will get you a ton of
| stress
| throwaway20371 wrote:
| My teammates create e-mail filters to send useless daily e-mail
| reports to the trash. I try to find out who controls the e-mail
| process, or the e-mail address, or something, so I can fix it...
| but I spend lots of time and it ends in vain. I couldn't find who
| "owns" the process, I couldn't find who controls the mailing
| list, and I couldn't get anyone to give me permission to change
| it even if I knew how.
|
| Clearly the problem isn't just having the skill or permission to
| change something, it's also the friction involved in figuring out
| how the hell to do it. How do you lower friction? Documenting
| things, making it easy to find things, making it easy to get
| access to things. If you can come up with an internal system that
| combines all of that, you have a one-stop shop for fixing high-
| friction problems.
|
| I think Wikis are highly underrated. They seem to encapsulate all
| those things. Anyone can edit (or revert edits), anyone can
| access it, anyone can find it (eventually). Somehow we need to
| tie all the rest of an organization into a Wiki.
| teeray wrote:
| Has 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.
| ikiris wrote:
| You can change to an outside org though. Rational self
| interest.
| justin_oaks wrote:
| The most positive change I've seen happen in an organization is
| through skunkworks projects, i.e. work you don't tell your boss
| about.
|
| Too much technical debt, but the boss doesn't want to refactor?
| Refactor any code you were touching anyway.
|
| Build process too complicated and brittle? Write build scripts,
| add error checking, and make other necessary changes to fix the
| problem.
|
| My past bosses never asked "Where did you find the time to do
| that?" even if they even noticed that anything happened at all.
|
| At one company I worked, we had no build server. The boss
| didn't see the need for it so he never approved it, but he also
| didn't reject it once we set it up.
|
| Any organizational change that requires other to change their
| behavior or their opinions? It is very difficult to change. The
| only success I've had is by mentioning an idea multiple times
| and eventually my boss started thinking it was his idea.
| sz4kerto wrote:
| Yes. It's really painful.
|
| Imagine a 5 year old code base that doesn't even have technical
| debt: it's a manifestation of the technical debt itself. It's
| hundreds of thousands of lines of code, mostly with "emergent
| behavior". You can't release without spending days on clicking
| through the RC system manually to check what's broken. Also,
| your product is extremely complex because apparently the
| barrier to entry in your field of business is very high.
|
| And you have no users.
|
| Then suddenly users arrive.
|
| What it takes is 1) management buy-in (they should be desperate
| enough) 2) engineers who are not willing to make compromises.
|
| Also, as usual in crisis management, people who successfully
| manage crises are generally ousted after the crisis is over
| because the personality needed to solve crises is not
| compatible with peacetime modus operandi.
| justin_oaks wrote:
| Funny enough, at my last job the bosses never listened to
| anything their employees suggested. Whenever an outsider
| (journalist, user, family member, or outside consultant)
| suggested the same thing as the employees suggested, only then
| did the bosses consider it.
|
| I don't know how common this is in other places, but that
| organization could only change through external, not internal,
| influences.
| ignoramous wrote:
| Related:
|
| Jeff Bezos on _Learned Helplessness_ (2005): https://www.youtube-
| nocookie.com/embed/WhnDvvNS8zQ
|
| Paul Graham on _Schlep Blindness_ (2012):
| http://paulgraham.com/schlep.html
___________________________________________________________________
(page generated 2021-11-02 23:00 UTC)