21 ms·

How learned helplessness happens in engineering teams

474 points by tomasrb 5y ago

Yhippa 5y ago
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 5y ago
  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 5y ago
    > 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 5y ago
      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.
commandlinefan 5y ago
> 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 5y ago
  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.
  - halfmatthalfcat 5y ago
    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.
    - rectang 5y ago
      > it's nothing that has been world-stopping Well then you're talking about a completely different scenario than I am.
      - ddek 5y ago
        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.
ignoramous 5y ago
Related: Jeff Bezos on Learned Helplessness (2005): https://www.youtube-nocookie.com/embed/WhnDvvNS8zQ https://www.youtube-nocookie.com/embed/WhnDvvNS8zQ Paul Graham on Schlep Blindness (2012): http://paulgraham.com/schlep.html http://paulgraham.com/schlep.html
29athrowaway 5y ago
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/ https://blog.danielna.com/talks/pushing-through-friction/
- _rtld_global_ro 5y ago
  One of the best talk I haven't seen for quite a long time, thanks for sharing.
- Kinrany 5y ago
  Dan Luu's article: http://danluu.com/wat/ http://danluu.com/wat/
bxparks 5y ago
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.
- hinkley 5y ago
  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 5y ago
    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.
    - kubanczyk 5y ago
      Does this law apply also to projects like Linux Kernel or Wikipedia? If not, where does it apply?
- firebaze 5y ago
  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.
teeray 5y ago
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.
- justin_oaks 5y ago
  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.
  - jodrellblank 5y ago
    I remember reading something about it in the gaming industry; from memory it was written by a contractor brought into 3D games on tight deadlines to unstick them. And what they did was go in, ask the employees what was wrong, the employees told him everything that was wrong and what would fix it. They'd been trying to tell anyone who would listen, for months, and he was the first person who would listen. Then he turned around and told everything that was wrong to management, who were thrilled that the contractor could come in and so quickly tell them what was wrong and how to fix it, and give him the resources to do it because the deadline was imminent. The employees could lean on the consultant to cut through bureaucracy, and the consultant (who had skills) could sort out some intricate game engine performance problems, and the whole thing moved on. He did that almost routinely moving round big game companies from project to project. I might be misremembering, but I can't find it in the HN search history. Like an explanation given for how companies will let key employees quit, then excitedly pay more for new hires. New employees (or contractors) are all marketing about how great they are. Existing employees are all too obviously mere mortals with plenty of flaws. Of course getting rid of the ordinary employee and getting Superman looks like a good idea. Manager spends time listening to employees complain: losing proposition, boring, time consuming, looks like doing nothing. Manager brings in amazing consultant who helps: manager looks good, saves effort, has a claim to need a bigger team and budget in future because evidence shows they just needed some extra help.
NAHWheatCracker 5y ago
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.
- rnrnrn 5y ago
  This kind of thing needs to have some exec sponsorship or at the very least awareness. Otherwise ICs just risk landing on the sword. You can try but once there’s resistance is probably a better idea to find something else. Let management figure out why people keep quitting. I don’t like giving this recommendation out but the other way can make for a career limiting move.
- firebaze 5y ago
  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.
the_arun 5y ago
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.
hinkley 5y ago
> 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.
- thewebcount 5y ago
  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.
  - hinkley 5y ago
    Near as I can tell, this has to do with how many different people a problem has been reported by. Either strict numbers or turns of phrase finally changes the mind of the holdouts. I started sending people to ask the person who has been vetoing the change about why we can’t have nice things. Sometimes it works.
cntainer 5y ago
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 5y ago
  That might be just a story, rather than something that actually happened. https://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-banana-story-is-rubbish/ https://www.throwcase.com/2014/12/21/that-five-monkeys-and-a...
  - cntainer 5y ago
    yep, that's why I called it a story, not a scientific experiment. It could even be read as a kind of anecdote of parable. While oversimplified, it can serve as a good example on how an initially rational practice could easily became dogma even when the initial stimulus is no longer present. Part of my day job in the past 2 years has been to consult a client in refactoring/rewriting an old platform. The client's old team is still in place and even if we've added some new people just to try and change the mindset, the inertia of the spaghetti codebase coupled with the client's short and mid term financial goals as well as the "traditions" of the old team has stopped us from enacting any groundbreaking changes. I guess the moral is that there are many forces at play in this kind of setup and stories like these can help in framing some of them in a fun way.
nine_zeros 5y ago
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 5y ago
  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.
  - nine_zeros 5y ago
    No. I am also in learned helplessness mode. The manager doesn't appear to get that the gatekeeper engineer is stubborn. I have nothing to gain by getting caught in the crossfire. I would just quit after biding my time.
jreese 5y ago
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 5y ago
  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 5y ago
    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.
    - noisy_boy 5y ago
      I still do this and I don't think this is entirely about culture. Some people do the legwork and some take the laziest route. Sure if the technical tools at hand make it that much hard to do the due diligence, maybe promptly reaching out for help can be (somewhat) justified, but I don't think that is usually the case.
  - 5y ago
qaq 5y ago
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 5y ago
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.
noneeeed 5y ago
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.
inspector-g 5y ago
I’d like to add a #3 to the list, which I’ll half-jokingly name “ruined by working at a large company learned helplessness” My company is small and we have very small teams (1-4 people). One person recently hired has been working at successively larger companies over the years (I’ve known him for a long time). Sometimes he’ll do something like this: stop working on a task he’s been assigned, say “test data needed”, and just totally bow out until someone else makes it for him. As I said, this is a small team. He knows how to make his own test data, and sometimes there is even a UI dedicated to making the kind of data he needs. But he has learned from working at larger companies that he can sometimes just pass his work onto someone else (perhaps even an entire other team dedicated to the thing he doesn’t want to do) instead of stepping up to the plate to do such a trivial thing on his own. To be clear, this is just an example (which has actually happened) and other similar “not my job” thinking/actions have shown up repeatedly. Many years ago we worked together on a small team and he was not like this at that time.
- Aeolun 5y ago
  I think it’s more that you’re not allowed to do those things in a larger company. People will feel like you are ursurping their area of responsibility, or you’ll even be completely unable to make it.
zelon88 5y ago
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 what could possibly go wrong with that? I'm not saying the thinking is wrong, but a little idealistic. Not everyone works at BigCo where it is impossible to get fired and you only ever get transferred. Nevermind most of the people in this position are going to have extremely short tenture.
- afarrell 5y ago
  Whom do you talk to if you notice it in the CTOs?
  - kuu 5y ago
    To HR of the next company...
- ineptech 5y ago
  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 measure developer productivity, and that is to ask their teammates, and if you won't tell me your teammate is awful, you can't really complain that I don't act on it. Of course it's possible that you tell me and I don't do anything, but at least then it's my fault and not yours.
  - zelon88 5y ago
    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.
ineptech 5y ago
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.
csours 5y ago
It is expensive to know what is going on. In military terms this is called 'Fog of War'. Front line managers quickly learn to manage up - know what their boss expects and present things in an appealing way. Same for middle managers and senior managers. They all hide the pain that their teams undergo. Senior managers and executives can have people write reports that show progress on some metric, and then they manage to that metric (or bucket of metrics in more enlightened organizations), without ever knowing, thinking about, or caring about how much it takes to get things done. As a dev, it's my job to make someone else's job easier. Whose job is it to make my job easier?
molsongolden 5y ago
How have people found balance in these situations? The examples mentioned are painfully real and accurate but it's possible to swing too far in the other direction too. Too much autonomy, feedback collection, etc. can also bog down the entire team. Not all feedback is good or well-reasoned. It's easy to get stuck in a spiral of short-sighted reactive changes and the second-guessing of every past decision. - It takes a lot of focused effort to both empower individuals and educate them (without indoctrinating them into learned helplessness?). The only lead I have here is to document decisions in ADR-style[1] docs so newcomers can see what else was considered and not chosen. I'd love to hear any other success stories or tips. -- [1]https://adr.github.io/ https://adr.github.io/
miqkt 5y ago
> Notice subtle changes in behavior: the most useful hint here is when someone who used to be very vocal about an issue stops complaining. This point resonated greatly with my own observations, both of myself and of other colleagues with each development team I've been part of. I think another challenge is fostering a culture where everybody genuinely cares about the output that's delivered. Not everybody will. Some people are comfortable moving tickets from triage through to a resolved state day in, day out without caring whether this process or the output can be improved.
TeeMassive 5y ago
> In a word, we could call this resignation by a thousand cuts, which makes it unexpected for managers. Eh eh eh, this feels like reading the Phoenix Project all over again: "are you me!?" My first job out of university was a job at a BigCo, right in the middle of a Death March. Nobody at the beginning of the project remained. Most people who "finished it" were new comers like me or "team leads"(tm). The three years I was there my teammates and I tried to push numerous changes and much needed improvements. Every time we had push back, especially by the team leads who literally shouted everyone down; I now have a profound hate for people with loud soprano voice by I digress. I tried my best to raise up problems, find their roots and solutions. I mean, I couldn't be subtle that I wasn't satisfied with what I have seen. And yet when I quit, my colleagues all could point out reasons of why I quit and yet none expected that I would leave. As the article pointed out, you should quit early and make sure your reasons are known; your old colleagues will owe you and this is pretty much the only way they can get the message.
adxl 5y ago
Big teams at big companies are the pits. Find a startup with under 10 people and no technical debt. You might not bank as much cash, make sure to get a large slug of equity on the off chance the company does well and you are then set. You don’t have to put up with this garbage. Otherwise why are you reading this on YCombinator?
cm2012 5y ago
The biggest cause of this in my experience is too much codified process, not too little. This is cause #1 in this article, which is vindicating. Adding process is a delicate balance and most large companies err on too much of it. Every checklist you add, every new approval, every sheet that needs some rows filled out, every brief - all of them add friction. New projects are inherently speculative, and most things don't move the company's bottom line. The power law that says 10% of work get 90% of results is true. Friction means whoever is doing the work is just a little less likely to propose a bold test, to push on a tweak they notice, because they know it will become an ordeal. Obviously you can't be 100% wild west and some process is needed. But you have to be very very careful when adding it.
- Brian_K_White 5y ago
  There is another, opposite force that manifests in humans arising from almost the same inputs, they will often happily tolerate 99% friction, as long as they actually get at least those few 1% of wins. Even with a ton of nice safe ossified process to make the owners feel safe, if you just make it a policy to give them a win once in a while, they'll live off of that and not even be all that unhappy. The 99% friction is felt less like a waste and more like a high bar. I think in a lot of places, they just don't allow even that calculated IV drip of dignity and purpose.
travisgriggs 5y ago
What I’ve noticed in this cycle is that as the turn over continues, the employee skill level will trend downwards. Essentially in a sort of ironic-Darwinian-gone-wrong, the system selects for those that will stay and/or don’t care or are desperate enough for work (because of geographical allegiance of low hireability, or just low initiative to make a change). I fear my current workplace that was so cool years ago is showing these signs.
- ironman1478 5y ago
  This is definitely happening. A engineer can't really work on anything truly complicated if they hop around every 2-3 years. These types of engineers gain cursory knowledge of topics but never become experts.
  - therealdrag0 5y ago
    That’s not exactly what parent was saying. They were saying, afaict, if an org is struggling with retention then each successive generation will be worse at affecting change. They aren’t saying anything about individuals themselves who switch jobs often. But about your point I think it can depend greatly. Personally I switched jobs many times but have so far kept in the same field and my knowledge has compounded and I have never dealt behind. In fact sometimes I feel the opposite, some coworkers who have less diverse experience have less to offer.
  - abdabab 5y ago
    2-3 years is enough to master a certain niche of technology fairly well if you want to.
- mattchamb 5y ago
  I see this happening in places too. I have seen it described as the Dead Sea effect. http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/ http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
jeffyang 5y ago
I used to run support groups to tackle the rampant helplessness I saw around me. The way it worked is that the person would describe their situation and then everyone else would ask questions. The format was: 1. understand the facts, and understand if they are actually true 2. explore options, even crazy ones 3. pick an action to take and commit to it For the questioners, the most important rule was you can't give advice. The person who is asking for help needs own it. They provide all the answers and decide on their own action. That action could be anything from talking to your manager, to setting boundaries, to looking for another job. It worked amazingly well, many people who started off feeling stuck realized they had the ability to find a better path. Even just making a conscious decision to do nothing and being okay with the consequences of that is empowering and insightful. I used to be completely helpless, learned from childhood. I finally realized that I'm not a child anymore and I have so many more options as an adult. Happy to chat with you if you're feeling stuck, feel free to email me (see my profile). Shameless plug: I stopped this to work on a related area - empowering people through team-building. The first session is free, you could do it in place of your next virtual happy hour! Check it out at https://risingteam.com https://risingteam.com.
aunty_helen 5y ago
This article is bashing BigCo while letting move-fast-and-break-things Startup inc. off the hook. Just because the fires are different every day at Startup Inc. doesn't mean we're not being conditioned to endure suffering. Case in point, a previous BigCo on call roster that I was required to partake in, sucks, makes you lose will to live, keeps you up at night, nothing documented, on-call phone ringing 5-7 of the nights in the week. I tried to improve this process and was mildly sucessful even if that was just to get these incidents recorded. Fast forward to my next job at Startup Inc. and their on call roster, sucks, makes you lose will to live, keeps you up at night, nothing documented, on-call phone ringing less but still often enough and with higher urgency. The source of the two problems was different most of the time, one being a lack of training and effectively giving children knives. The other being moving fast and breaking things resulting in things breaking after it was declared that version x.x went out without any issues just like the CEO wanted.
trabant00 5y ago
I have a completely different perspective: processes in a company reflect the people and the relationships between them. It is on these levels you must operate in order to bring change. As an engineer you have very little power to do so. So leaving and finding a different team is often the right choice when you are unhappy. From my experience staying and fighting an uphill battle is an exercise in futility which will bring more unhappiness to you and the people you are trying to change.
gyulai 5y ago
"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 internal psychological forces, when your struggle really is with your teammates and the team's power structure.
- kuu 5y ago
  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...
Tade0 5y ago
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.
nathias 5y ago
Ever tried. Ever failed. No matter. Try Again. Eeach time a little less, until quitting seems better.
nextstep 5y ago
Google is this for almost every internal tool and process. The only difference is most never reach step 5 (quitting), so imagine how toxic that culture is.
adminscoffee 5y ago
i think it happens when there is no hands off approach. the way i heard it before was that some people learn from pressure and others learn from the hands off approach. i know i do a way better job when people tell me what to do without the assumption that i am completely new to something, other people have the opposite learning style, they want the baby steps. but one major issue is when a manager mistakes ones learning style and that just creates frustration for everyone
julian_sark 5y ago
So true! Both "This is just how the company is, it won't change" and "We survived thus far, we'll get through" are the unofficial mantras of the company I work for. Even though many in the middle management see the problems, these mantras are repeated whenever one speaks up against silly processes. And boy, do we have some silly processes. It's not helped by the fact that the second is actually a mantra often quoted as the official motto of the neighboring metropolis, as if resistance to betterment is something to be proud of ("et hät noch immer jot jejange", for those in the know of both German and the dialect). Though I suppose it might have also been the motto of the dinosaurs before the big impact. There is "learned helplessness" in a way also in management, because they in turn seem to have learned that raising any issues with the higher management only leads to being branded as, if not a source of discord or trouble, then at the least as someone who requires a higher manager to deal with something, as opposed to those not requiring a higher manager to deal with something. The later clearly being preferred by the upper management.
tukson 5y ago
This is a mindset issue not a technical one. At the end of the day, if you're a developer, you don't get to call the shots in terms of what issues get fixed when. That's up to the lead dev/product owner/BA. You can flag issues and propose solutions, sure. If you think the company isn't worth the trouble then quit and get another job, there are plenty of tech opportunities out there, one's that are no doubt more dev focused.
bluedino 5y ago
My example of horrible technical debt goes like so: I (not that long ago) worked at a company that kept all their data in MySQL. Sounds fine. The bad part was all their user-facing stuff was written in Microsoft Access. This didn't make any sense and was the main thing that prevented them from moving to a web-based or API-based interface. They had written some code here and there that would cobble a few things together but it wasn't the right way to do it. During a discussion, I asked why there were 2 MySQL servers. They held different databases, but it would have made more sense to have them both on one server. I assumed that at some point in the company history, the data got too big to fit on one server, so they split it up, and that ended up being true. And ever since they had some misguided sense of safety having two different databases, even though if you were missing the other, all functionality would break. At the current time, the databases weren't large enough or accessed enough to require being on separate hardware. It seemed simple enough to just import one into the other and then get on with modernizing the rest of the code. "We would have to re-write the entire codebase since it's based on having two servers" Access lets you basically do joins etc on two separate databases. So this was used heavily. Whenever they tried to duplicate this functionality in PHP or whatever they would try, it turned into a nightmare. I would imagine if they had spent another $10k on hardware back when they first had this problem they would have saved a lot of future troubles. Imagine running legacy versions of Visual Basic, developers needing Windows XP VM's, end users needing two copies of Microsoft Access installed...

474 points by tomasrb 5y ago

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 5y ago
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 5y ago
  > 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 5y ago
    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.

commandlinefan 5y ago

> 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 5y ago
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.
- halfmatthalfcat 5y ago
  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.
  - rectang 5y ago
    > it's nothing that has been world-stopping Well then you're talking about a completely different scenario than I am.
    - ddek 5y ago
      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.

ignoramous 5y ago

Related: Jeff Bezos on Learned Helplessness (2005): https://www.youtube-nocookie.com/embed/WhnDvvNS8zQ https://www.youtube-nocookie.com/embed/WhnDvvNS8zQ Paul Graham on Schlep Blindness (2012): http://paulgraham.com/schlep.html http://paulgraham.com/schlep.html

29athrowaway 5y ago

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/ https://blog.danielna.com/talks/pushing-through-friction/

_rtld_global_ro 5y ago
One of the best talk I haven't seen for quite a long time, thanks for sharing.
Kinrany 5y ago
Dan Luu's article: http://danluu.com/wat/ http://danluu.com/wat/

bxparks 5y ago

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.

hinkley 5y ago
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 5y ago
  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.
  - kubanczyk 5y ago
    Does this law apply also to projects like Linux Kernel or Wikipedia? If not, where does it apply?
firebaze 5y ago
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.

teeray 5y ago

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.

justin_oaks 5y ago
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.
- jodrellblank 5y ago
  I remember reading something about it in the gaming industry; from memory it was written by a contractor brought into 3D games on tight deadlines to unstick them. And what they did was go in, ask the employees what was wrong, the employees told him everything that was wrong and what would fix it. They'd been trying to tell anyone who would listen, for months, and he was the first person who would listen. Then he turned around and told everything that was wrong to management, who were thrilled that the contractor could come in and so quickly tell them what was wrong and how to fix it, and give him the resources to do it because the deadline was imminent. The employees could lean on the consultant to cut through bureaucracy, and the consultant (who had skills) could sort out some intricate game engine performance problems, and the whole thing moved on. He did that almost routinely moving round big game companies from project to project. I might be misremembering, but I can't find it in the HN search history. Like an explanation given for how companies will let key employees quit, then excitedly pay more for new hires. New employees (or contractors) are all marketing about how great they are. Existing employees are all too obviously mere mortals with plenty of flaws. Of course getting rid of the ordinary employee and getting Superman looks like a good idea. Manager spends time listening to employees complain: losing proposition, boring, time consuming, looks like doing nothing. Manager brings in amazing consultant who helps: manager looks good, saves effort, has a claim to need a bigger team and budget in future because evidence shows they just needed some extra help.

NAHWheatCracker 5y ago

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.

rnrnrn 5y ago
This kind of thing needs to have some exec sponsorship or at the very least awareness. Otherwise ICs just risk landing on the sword. You can try but once there’s resistance is probably a better idea to find something else. Let management figure out why people keep quitting. I don’t like giving this recommendation out but the other way can make for a career limiting move.
firebaze 5y ago
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.

the_arun 5y ago

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.

hinkley 5y ago

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

thewebcount 5y ago
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.
- hinkley 5y ago
  Near as I can tell, this has to do with how many different people a problem has been reported by. Either strict numbers or turns of phrase finally changes the mind of the holdouts. I started sending people to ask the person who has been vetoing the change about why we can’t have nice things. Sometimes it works.

cntainer 5y ago

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 5y ago
That might be just a story, rather than something that actually happened. https://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-banana-story-is-rubbish/ https://www.throwcase.com/2014/12/21/that-five-monkeys-and-a...
- cntainer 5y ago
  yep, that's why I called it a story, not a scientific experiment. It could even be read as a kind of anecdote of parable. While oversimplified, it can serve as a good example on how an initially rational practice could easily became dogma even when the initial stimulus is no longer present. Part of my day job in the past 2 years has been to consult a client in refactoring/rewriting an old platform. The client's old team is still in place and even if we've added some new people just to try and change the mindset, the inertia of the spaghetti codebase coupled with the client's short and mid term financial goals as well as the "traditions" of the old team has stopped us from enacting any groundbreaking changes. I guess the moral is that there are many forces at play in this kind of setup and stories like these can help in framing some of them in a fun way.

nine_zeros 5y ago

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 5y ago
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.
- nine_zeros 5y ago
  No. I am also in learned helplessness mode. The manager doesn't appear to get that the gatekeeper engineer is stubborn. I have nothing to gain by getting caught in the crossfire. I would just quit after biding my time.

jreese 5y ago

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 5y ago
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 5y ago
  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.
  - noisy_boy 5y ago
    I still do this and I don't think this is entirely about culture. Some people do the legwork and some take the laziest route. Sure if the technical tools at hand make it that much hard to do the due diligence, maybe promptly reaching out for help can be (somewhat) justified, but I don't think that is usually the case.
- 5y ago

qaq 5y ago

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 5y ago

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.

noneeeed 5y ago

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.

inspector-g 5y ago

I’d like to add a #3 to the list, which I’ll half-jokingly name “ruined by working at a large company learned helplessness” My company is small and we have very small teams (1-4 people). One person recently hired has been working at successively larger companies over the years (I’ve known him for a long time). Sometimes he’ll do something like this: stop working on a task he’s been assigned, say “test data needed”, and just totally bow out until someone else makes it for him. As I said, this is a small team. He knows how to make his own test data, and sometimes there is even a UI dedicated to making the kind of data he needs. But he has learned from working at larger companies that he can sometimes just pass his work onto someone else (perhaps even an entire other team dedicated to the thing he doesn’t want to do) instead of stepping up to the plate to do such a trivial thing on his own. To be clear, this is just an example (which has actually happened) and other similar “not my job” thinking/actions have shown up repeatedly. Many years ago we worked together on a small team and he was not like this at that time.

Aeolun 5y ago
I think it’s more that you’re not allowed to do those things in a larger company. People will feel like you are ursurping their area of responsibility, or you’ll even be completely unable to make it.

zelon88 5y ago

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 what could possibly go wrong with that? I'm not saying the thinking is wrong, but a little idealistic. Not everyone works at BigCo where it is impossible to get fired and you only ever get transferred. Nevermind most of the people in this position are going to have extremely short tenture.

afarrell 5y ago
Whom do you talk to if you notice it in the CTOs?
- kuu 5y ago
  To HR of the next company...
ineptech 5y ago
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 measure developer productivity, and that is to ask their teammates, and if you won't tell me your teammate is awful, you can't really complain that I don't act on it. Of course it's possible that you tell me and I don't do anything, but at least then it's my fault and not yours.
- zelon88 5y ago
  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.

ineptech 5y ago

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.

csours 5y ago

It is expensive to know what is going on. In military terms this is called 'Fog of War'. Front line managers quickly learn to manage up - know what their boss expects and present things in an appealing way. Same for middle managers and senior managers. They all hide the pain that their teams undergo. Senior managers and executives can have people write reports that show progress on some metric, and then they manage to that metric (or bucket of metrics in more enlightened organizations), without ever knowing, thinking about, or caring about how much it takes to get things done. As a dev, it's my job to make someone else's job easier. Whose job is it to make my job easier?

molsongolden 5y ago

How have people found balance in these situations? The examples mentioned are painfully real and accurate but it's possible to swing too far in the other direction too. Too much autonomy, feedback collection, etc. can also bog down the entire team. Not all feedback is good or well-reasoned. It's easy to get stuck in a spiral of short-sighted reactive changes and the second-guessing of every past decision. - It takes a lot of focused effort to both empower individuals and educate them (without indoctrinating them into learned helplessness?). The only lead I have here is to document decisions in ADR-style[1] docs so newcomers can see what else was considered and not chosen. I'd love to hear any other success stories or tips. -- [1]https://adr.github.io/ https://adr.github.io/

miqkt 5y ago

> Notice subtle changes in behavior: the most useful hint here is when someone who used to be very vocal about an issue stops complaining. This point resonated greatly with my own observations, both of myself and of other colleagues with each development team I've been part of. I think another challenge is fostering a culture where everybody genuinely cares about the output that's delivered. Not everybody will. Some people are comfortable moving tickets from triage through to a resolved state day in, day out without caring whether this process or the output can be improved.

TeeMassive 5y ago

> In a word, we could call this resignation by a thousand cuts, which makes it unexpected for managers. Eh eh eh, this feels like reading the Phoenix Project all over again: "are you me!?" My first job out of university was a job at a BigCo, right in the middle of a Death March. Nobody at the beginning of the project remained. Most people who "finished it" were new comers like me or "team leads"(tm). The three years I was there my teammates and I tried to push numerous changes and much needed improvements. Every time we had push back, especially by the team leads who literally shouted everyone down; I now have a profound hate for people with loud soprano voice by I digress. I tried my best to raise up problems, find their roots and solutions. I mean, I couldn't be subtle that I wasn't satisfied with what I have seen. And yet when I quit, my colleagues all could point out reasons of why I quit and yet none expected that I would leave. As the article pointed out, you should quit early and make sure your reasons are known; your old colleagues will owe you and this is pretty much the only way they can get the message.

adxl 5y ago

Big teams at big companies are the pits. Find a startup with under 10 people and no technical debt. You might not bank as much cash, make sure to get a large slug of equity on the off chance the company does well and you are then set. You don’t have to put up with this garbage. Otherwise why are you reading this on YCombinator?

cm2012 5y ago

The biggest cause of this in my experience is too much codified process, not too little. This is cause #1 in this article, which is vindicating. Adding process is a delicate balance and most large companies err on too much of it. Every checklist you add, every new approval, every sheet that needs some rows filled out, every brief - all of them add friction. New projects are inherently speculative, and most things don't move the company's bottom line. The power law that says 10% of work get 90% of results is true. Friction means whoever is doing the work is just a little less likely to propose a bold test, to push on a tweak they notice, because they know it will become an ordeal. Obviously you can't be 100% wild west and some process is needed. But you have to be very very careful when adding it.

Brian_K_White 5y ago
There is another, opposite force that manifests in humans arising from almost the same inputs, they will often happily tolerate 99% friction, as long as they actually get at least those few 1% of wins. Even with a ton of nice safe ossified process to make the owners feel safe, if you just make it a policy to give them a win once in a while, they'll live off of that and not even be all that unhappy. The 99% friction is felt less like a waste and more like a high bar. I think in a lot of places, they just don't allow even that calculated IV drip of dignity and purpose.

travisgriggs 5y ago

What I’ve noticed in this cycle is that as the turn over continues, the employee skill level will trend downwards. Essentially in a sort of ironic-Darwinian-gone-wrong, the system selects for those that will stay and/or don’t care or are desperate enough for work (because of geographical allegiance of low hireability, or just low initiative to make a change). I fear my current workplace that was so cool years ago is showing these signs.

ironman1478 5y ago
This is definitely happening. A engineer can't really work on anything truly complicated if they hop around every 2-3 years. These types of engineers gain cursory knowledge of topics but never become experts.
- therealdrag0 5y ago
  That’s not exactly what parent was saying. They were saying, afaict, if an org is struggling with retention then each successive generation will be worse at affecting change. They aren’t saying anything about individuals themselves who switch jobs often. But about your point I think it can depend greatly. Personally I switched jobs many times but have so far kept in the same field and my knowledge has compounded and I have never dealt behind. In fact sometimes I feel the opposite, some coworkers who have less diverse experience have less to offer.
- abdabab 5y ago
  2-3 years is enough to master a certain niche of technology fairly well if you want to.
mattchamb 5y ago
I see this happening in places too. I have seen it described as the Dead Sea effect. http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/ http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...

jeffyang 5y ago

I used to run support groups to tackle the rampant helplessness I saw around me. The way it worked is that the person would describe their situation and then everyone else would ask questions. The format was: 1. understand the facts, and understand if they are actually true 2. explore options, even crazy ones 3. pick an action to take and commit to it For the questioners, the most important rule was you can't give advice. The person who is asking for help needs own it. They provide all the answers and decide on their own action. That action could be anything from talking to your manager, to setting boundaries, to looking for another job. It worked amazingly well, many people who started off feeling stuck realized they had the ability to find a better path. Even just making a conscious decision to do nothing and being okay with the consequences of that is empowering and insightful. I used to be completely helpless, learned from childhood. I finally realized that I'm not a child anymore and I have so many more options as an adult. Happy to chat with you if you're feeling stuck, feel free to email me (see my profile). Shameless plug: I stopped this to work on a related area - empowering people through team-building. The first session is free, you could do it in place of your next virtual happy hour! Check it out at https://risingteam.com https://risingteam.com.

aunty_helen 5y ago

This article is bashing BigCo while letting move-fast-and-break-things Startup inc. off the hook. Just because the fires are different every day at Startup Inc. doesn't mean we're not being conditioned to endure suffering. Case in point, a previous BigCo on call roster that I was required to partake in, sucks, makes you lose will to live, keeps you up at night, nothing documented, on-call phone ringing 5-7 of the nights in the week. I tried to improve this process and was mildly sucessful even if that was just to get these incidents recorded. Fast forward to my next job at Startup Inc. and their on call roster, sucks, makes you lose will to live, keeps you up at night, nothing documented, on-call phone ringing less but still often enough and with higher urgency. The source of the two problems was different most of the time, one being a lack of training and effectively giving children knives. The other being moving fast and breaking things resulting in things breaking after it was declared that version x.x went out without any issues just like the CEO wanted.

trabant00 5y ago

I have a completely different perspective: processes in a company reflect the people and the relationships between them. It is on these levels you must operate in order to bring change. As an engineer you have very little power to do so. So leaving and finding a different team is often the right choice when you are unhappy. From my experience staying and fighting an uphill battle is an exercise in futility which will bring more unhappiness to you and the people you are trying to change.

gyulai 5y ago

"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 internal psychological forces, when your struggle really is with your teammates and the team's power structure.

kuu 5y ago
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...

Tade0 5y ago

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.

nathias 5y ago

Ever tried. Ever failed. No matter. Try Again. Eeach time a little less, until quitting seems better.

nextstep 5y ago

Google is this for almost every internal tool and process. The only difference is most never reach step 5 (quitting), so imagine how toxic that culture is.

adminscoffee 5y ago

i think it happens when there is no hands off approach. the way i heard it before was that some people learn from pressure and others learn from the hands off approach. i know i do a way better job when people tell me what to do without the assumption that i am completely new to something, other people have the opposite learning style, they want the baby steps. but one major issue is when a manager mistakes ones learning style and that just creates frustration for everyone

julian_sark 5y ago

So true! Both "This is just how the company is, it won't change" and "We survived thus far, we'll get through" are the unofficial mantras of the company I work for. Even though many in the middle management see the problems, these mantras are repeated whenever one speaks up against silly processes. And boy, do we have some silly processes. It's not helped by the fact that the second is actually a mantra often quoted as the official motto of the neighboring metropolis, as if resistance to betterment is something to be proud of ("et hät noch immer jot jejange", for those in the know of both German and the dialect). Though I suppose it might have also been the motto of the dinosaurs before the big impact. There is "learned helplessness" in a way also in management, because they in turn seem to have learned that raising any issues with the higher management only leads to being branded as, if not a source of discord or trouble, then at the least as someone who requires a higher manager to deal with something, as opposed to those not requiring a higher manager to deal with something. The later clearly being preferred by the upper management.

tukson 5y ago

This is a mindset issue not a technical one. At the end of the day, if you're a developer, you don't get to call the shots in terms of what issues get fixed when. That's up to the lead dev/product owner/BA. You can flag issues and propose solutions, sure. If you think the company isn't worth the trouble then quit and get another job, there are plenty of tech opportunities out there, one's that are no doubt more dev focused.

bluedino 5y ago

My example of horrible technical debt goes like so: I (not that long ago) worked at a company that kept all their data in MySQL. Sounds fine. The bad part was all their user-facing stuff was written in Microsoft Access. This didn't make any sense and was the main thing that prevented them from moving to a web-based or API-based interface. They had written some code here and there that would cobble a few things together but it wasn't the right way to do it. During a discussion, I asked why there were 2 MySQL servers. They held different databases, but it would have made more sense to have them both on one server. I assumed that at some point in the company history, the data got too big to fit on one server, so they split it up, and that ended up being true. And ever since they had some misguided sense of safety having two different databases, even though if you were missing the other, all functionality would break. At the current time, the databases weren't large enough or accessed enough to require being on separate hardware. It seemed simple enough to just import one into the other and then get on with modernizing the rest of the code. "We would have to re-write the entire codebase since it's based on having two servers" Access lets you basically do joins etc on two separate databases. So this was used heavily. Whenever they tried to duplicate this functionality in PHP or whatever they would try, it turned into a nightmare. I would imagine if they had spent another $10k on hardware back when they first had this problem they would have saved a lot of future troubles. Imagine running legacy versions of Visual Basic, developers needing Windows XP VM's, end users needing two copies of Microsoft Access installed...