As a dev, it's my job to make someone else's job easier. Whose job is it to make my job easier?
How learned helplessness happens in engineering teams
91–100 of 220 posts
Re: How learned helplessness happens in engineering teams
#92Just today, my team had a developer meeting. The tech lead started out by complaining about how he has to do an untested unplanned release today because another team made some urgent changes. He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary. We've done two other releases in the past month and both required a day of troubleshooting to fix issue…
Quit. This is a sign of a broken and unfixable workplace.
Re: How learned helplessness happens in engineering teams
#93The 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.
--
Re: How learned helplessness happens in engineering teams
#94Just today, my team had a developer meeting. The tech lead started out by complaining about how he has to do an untested unplanned release today because another team made some urgent changes. He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary. We've done two other releases in the past month and both required a day of troubleshooting to fix issue…
My manager doesn't know anything about the code, my project, or the release project.
IOW, your team has no leadership and no management. Your team lead may be called that, but sounds like he doesn't lead at all. Your manager may be called that, but he doesn't manage either. This happens a lot when people are given responsibility without any authority (probably the case for you "team lead"), or authority over things they don't understand (probably the case for your "manager").
The bad news is that you're part of a disorganized mob. The good news is that there is a leadership vacuum that, if you play your cards right, you could fill. If you want. Of course, even if you succeed, it's possible no one will care about your accomplishments. And you will probably make enemies. It's possible you'll be rewarded but given your description, I view that as unlikely.
As a side note, suggesting to the team lead that he lead and do X, Y or Z may appear to him as if you want him to take on risks with little upside. He's probably thought about doing those things anyway but just decided it's not worth the trouble. It's not all that surprising that he doesn't want to rock the boat.
Re: How learned helplessness happens in engineering teams
#95From the article; > Hold managers accountable: one of the key responsibilities of leaders is to create positive change for their teams. Once you notice a situation where you think everyone is in learned helplessness mode, make sure to notify your manager and follow-up until the problem is addressed. "Hey boss, I noticed that Bob and Joe are really helpless at their jobs and that you just kinda watch it happen." Yeah…
It has nothing to do with "BigCo" or not. If you work in a small company, pretty much any boss will be happy to hear feedback like "Hey, it looks like there's an impediment to smooth work, and the team has gotten used to it, but it's costing us". Bonus points if you propose a solution.(If your manager isn't happy to hear that, it's time to leave, because small companies closing their eyes to this have a tendency to g…
> Imagine you’ve started a new job as an engineering manager, and the teams around you are too busy to use a planning process. You’ve mentioned to your peers a few times that you’ve seen Kanban work effectively, but folks tried it two years ago and are still upset whenever the word is mentioned: it just doesn’t work here.
> Your first reaction might be to confront this head on, but it takes a while to build credibility after starting a new job. Sure, you’ve been hired for your experience so they respect your judgement, but it’s a hard sell to convince someone that your personal experience should invalidate their personal experience.
Re: How learned helplessness happens in engineering teams
#96As 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…
Dealing with the infrastructure is your job. You know the ins and outs. It doesn't seem complicated to you.
For someone who is dealing with the application logic, having to context switch to infrastructure is painful. I have no idea how you have set things up. When I read your documentation I'm just baffled at the sheer amount of complexity. I don't want to deal with it. It's not my full time job. I have other things to worry about. I have no mental space to deal with this headache. I will just ask you so I can move on to do my actual job - which is already taking up over 90% of my mental capacity.
When I setup my own infrastructure, I make it as simple and stupid as possible, precisely because I have no mental slack to deal with all the complexity that I see devops people deal with on a daily basis.
At most jobs I've been to, the complexity I've seen in infrastructure is mind boggling. My intuition is that this complexity is not actually needed if you remove all the cruft and think from first principles about what the actual problem is you are trying to solve.
However, people in devops seem to enjoy building and maintaining this kind of complexity, and even take pride in how everything is orchestrated.
To me it's just a headache.
Re: How learned helplessness happens in engineering teams
#97Just today, my team had a developer meeting. The tech lead started out by complaining about how he has to do an untested unplanned release today because another team made some urgent changes. He's the only person who knows how to release it. The other team didn't communicate until today that a release is necessary. We've done two other releases in the past month and both required a day of troubleshooting to fix issue…
They broke it they have to fix it. You need the light shining on that team, not strive to fix it yourself.
Re: How learned helplessness happens in engineering teams
#98This 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.
Re: How learned helplessness happens in engineering teams
#99Re: How learned helplessness happens in engineering teams
#100Has 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.
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.
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.