In one of Alistair Christie's recent podcasts, he interviews his 70-year-old mother about how she uses computers. Although they cover many topics in the interview, her tech guilt is the most salient part of the discussion. She blames herself for not understanding how to work computers and navigate websites.
When she can't locate certain features on an interface (for example, Paypal), her first inclination isn't to blame the bad user design of the site or software, but to think that somehow it's her fault for not understanding.
The self-blaming attitude reminds me of a passage I read in Authentic Happiness years ago. Happier people, the author wrote, don't blame themselves when things go wrong. Rather, they tend to see others as responsible. I've often reflected about this, most often while playing basketball. After throwing a "bad" pass that my teammate misses, I used to say, "Sorry," or "My bad" -- blaming myself. But after reading the book, I decided that it's the other's fault for not catching the ball. The pass was decent enough. Embracing this attitude, I feel better about myself.
However, clearly this attitude fails in other contexts. Not taking responsibility for blame is one of The Five Dysfunctions of a Team. Team members must take responsibility for both successes and failures, and not play the blame game. The same is true in marriage. No matter how much you may have initially resisted a decision, if you relented and went along with it, you can't jump ship when the result is disastrous.
It seems, then, that at times you should include yourself in the blame (such as with teams), but other times you should not. The next time you're frustrated with software, do you blame yourself for being "technically stupid"? Or do you blame the developers for the idiot design? The answer reveals a lot about how you view yourself.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.