I have long believed that, complicated though it might seem, human behavior is incredibly predictable if you pay attention to their tells. A few weeks ago, a random stream of Google Fu led me to reading about learned helplessness, and like a child that learns a naughty word, I can’t stop telling everyone I know about it.
So back in the late 1960s, a psychologist named Martin Seligman was conducting experimental research on dogs, as one does. He discovered that when they received unavoidable electric shocks, they stopped trying to take steps in avoiding getting shocked--even when it was easily possible. They essentially accepted their fate and just took it. I don’t understand why someone had to conduct experiments to determine that when bad things happen to you, you expect more bad things to happen, but here we are.
He went on to conduct similar experiments on humans, but by playing loud noises instead of electric shocks, because people are liable to punch you in your tenders if you shock them. Turns out, when things are hard, we tend to want someone else to do them.
Learned helplessness is the expectation that outcomes are uncontrollable, and having worked for most of my life in some sort of “IT guy” capacity, holy shitsnacks is this true.
I work with quite a few college students, recent graduates, or people who are new in the IT field. This has given me the opportunity to help many people not make many of the early career mistakes, including not attempting something they for sure don’t know how to do. Taking risks and attempting something you don’t know is important to get better. Now that doesn’t mean running update queries in production when you don’t know what it does, but trying something you’re bad at is a great way to be not as bad at it the next time you do it.
When we have new interns start, we let them pick out a rubber duck. They are told they can ask anyone for help with anything, but they have to ask their question to the rubber duck first. Framing the question often gets you the lead you need to solve it. If they don’t have the answer after speaking with the duck, they can find someone who knows.
This also comes into play with end users, though it’s not always effective with everyone. Whenever we’re making a technical change that will affect how the users behave, I go out of my way to provide an explanation for the why behind the what. Most end users could care less about changes to your firewall or to the underlying framework behind your software, but the more aware people are, the less likely they are to simply accept it when something doesn’t work, waiting for someone else to do something. Knowing they have a way to get involved in the process is an empowering prospect for someone who is traditionally expected to just shut up and use the tools they are given.
In every group I have worked in, I set up multiple channels for end users to report anything unusual they see--and highly encourage them to do it. If you see something, say something! Oftentimes what they notice is a non-event, or they found something that’s already been reported before. But once in a while they stumble upon an edge case we hadn’t considered, or a design element we hadn’t thought of. The more involved the user is, the less helpless they are likely to feel--and the less likely they are to cause you additional work.
And that is my ultimate goal--to never put off till tomorrow what I can avoid doing altogether. Trust your users, trust your team mates, and worry less.
Top comments (0)