DEV Community

Ambrose Little
Ambrose Little

Posted on

An Introvert's Guide to Being Sociable: Faux Openness to Feedback

Introduction

Some time ago I wrote a post about how to be awesome without being a jerk. It has some concrete suggestions, which is helpful, but it's also helpful to learn by example. So this is my first entry in the series I'm calling "An Introvert's Guide to Being Sociable." The goal of this series will be to help introverts like myself become more aware of the things we do and say that, let's say, don't come across the way we think they do--or more like, when we don't even realize we're doing something wrong.

I've heard other introverts say, and I can relate a lot, that being in social situations is exhausting. And by that I mean situations extending beyond a very close friend that we feel more or less completely comfortable being ourselves around. The kinds of social situations that are exhausting generally involve folks we're not super close to, and as the number and degree of our familiarity with those persons decreases, our anxiety and feeling of having to "work" just to "be" around them increases.

So we are those types--the ones who really need "alone time" to recharge at the end of the day when we have to be in such social situations (and this often means just a regular day at the office). Sadly, for us, being sociable doesn't really come naturally. We have to put a lot of what feels like unnatural effort into it, and it's even more exhausting knowing that we're probably not doing a great job.

Unfortunately, I'm not aware of any magic mantras to make us feel more at home and comfy, but what I hope to do with this series is to offer examples where I have observed where a person (many times myself, upon later reflection or discussion with others) kind of "steps in it," in one way or another. These will be all real examples, and maybe also some general tips that I've learned. The idea is to pepper our brains with examples, so that our minds will start to innately form patterns from them and help us to avoid making the same mistakes.

I am by no means, believe me, an expert, but it is an area I have actively worked on throughout my adult life, and I hope I've learned a few things. And while I'm on the general topic, I can't recommend How to Win Friends and Influence People enough. It has stood the test of time, and is a fantastic primer in this area. I was fortunate enough to have it recommended to me in my early twenties, and I've reread it at least a few times since.

As for organization of this series, these are more or less disorganized--as I remember them or observe new ones, I'll add. Remember, these are things that we do almost always unconsciously--so the goal is not to feel bad for having done them but rather to become more aware so that we can do better in the future. Without further ado, the first example...

Faux Openness to Feedback

Let's say you have created something--a product, a tool, a service, etc. This happens a lot in software development, IT, systems engineering, etc. We put a lot of thought, blood, sweat, and tears into making a thing. And we put it out there for people to use. We want our creation to be appreciated.

Inevitably, it will not be appreciated by everyone all the time. So people will have opinions and feedback. We want to think of ourselves as people who are open to feedback--to improve the thing we made--so we say, "if you have any suggestions or feedback, just let me know!" or some variation on that.

And then the feedback comes in. Sometimes the feedback is.. not nice, but even when it is friendly and constructive, it still feels like our baby is being called ugly, so we fall into defensiveness. We start looking for ways to justify and explain why it is the way it is. We sometimes (especially when the feedback is mean) want to strike back. "Boy is this person an eye-dee-ten-tee." "Man, that has to be the dumbest idea ever." "If they only understood it..."

Trust me, I've been there. It's normal. Feeling this way isn't particularly limited to being an introvert, but I think we tend to be less apt at communicating back in productive, healthy ways when this happens.

Things Not to Do

Explain why it is the way it is.

Yes, this seems innocuous, but it is more often than not just a manifestation of a defense mechanism. The person providing the feedback, unless they say otherwise, almost certainly doesn't care why it is the way it is. You asked for feedback, and they gave it. Don't try to dismiss or minimize their feedback by way of explanation.

And this is so very hard for an introvert, particularly for technical introverts--because we actually do care why things are the way they are. We are fascinated by the intricacies of details. How could someone NOT want to know the beautiful thought and rationale that went into it!?!

But just don't. Hold that in. Kindly take the feedback and try to see it for what it is--it is someone else's perspective who doesn't have (and probably doesn't want to have) your knowledge about why it is the way it is. What is valuable here is that it is a great learning experience to put yourself in someone else's shoes, often the very people that you want to use and be happy with what you made. And if they don't appreciate it, sadly, it is a failure of Design somewhere.

Feedback is a great jumping off point into learning the mental models of the people who are using your thing. The more you can get into that mental model and reflect it in your design, the better your thing will be (for them) and the more your baby will be appreciated for the beautiful thing it is.

Tell Them to RTFM

Or some form of that. Actually, if someone has to read a manual to use your thing, it better be darned complicated. Think of needing to use a manual as a failure of Design. It's not always, but many times it is.

Tell Them Some Other Way to Do It

Okay, so this one is a little tricky. Often, depending on the context, giving someone some way to do what they want to do is important and helpful. But there are good and bad ways to do this, and times when we shouldn't do it.

"ALL you need to do is... 1, 2, 3, 4, 5... SEE? It's easy!"

If your inclination or response is something like the above--where you are thinking in your head like "I don't get what's so hard about doing this!"--then you need to STOP. Technical people tend to be far more patient with adapting ourselves to technology than the general populace is. People (and let's be honest, if we had our druthers, we'd prefer it to) just want it to work, and be easy. I mean, barring things like games where the challenge is the point of the thing.

I've worked in quite a few contexts in my life, including making commercial tools for other devs, and where I've seen this the most is devs dealing with other devs. Dev A loves the CLI. Dev A thinks it is easy as pie to type 30 commands in a row--much easier and better than some dumb UI. While Dev B prefers to point and click, or have some tool or other abstraction that lets them get to the same endpoint without knowing and using all those commands. OR, Dev C loves X editor or OS or shell and is super proficient in it, but Dev D has more experience and prefers another. And so on..

So, the right way to handle this kind of situation is to thank someone for the feedback, say you will make a note and look into how you might be able to make it work the way they expect, and then say, "in the meantime, I can show you a way to get that done today..." AND then you gotta listen more. If they say something like "no thanks," don't force it. If they tell you they're not familiar with some tool involved, don't say "don't worry, it's easy" or anything like that.

The overriding thing here is to make yourself more aware that other people lack a lot of what you take for granted, and that doesn't make them stupid or lazy. Listen to where they are coming from and try to adapt yourself to their mental model and context as much as possible, but don't get so focused on completing the task that you bowl over them in the process of "helping" them.

Search teh interwebs for 'Nick Burns SNL' and watch it. It parodies this kind of thing--and it's obvious that we do it, or it wouldn't have become a thing enough to be parodied! "Move!"

Tell Them What They Want to Do Is Not Worthwhile

This sounds kind of obvious when put this way, but I have seen so many manifestations of this it's kind of crazy. The worst offender I've seen is throwing this chart into the discussion. I outline in that post why, but for our purposes here, it's just a way that you can (accidentally) be a jerk.

Don't ask "why would you want to do that?" Umm.. think about how to rephrase that, if you really want to know. If you don't really want to know, if you're asking rhetorically because in the back of your head you're thinking it's stupid and a waste, DO NOT ask this. Just keep your lips zipped.

"That doesn't really save much time." Okay, maybe not. But most people in these situations are less focused on the time involved than the subjective experience involved. Obviously, if someone is taking the time to provide feedback, it passed a reasonably high bar of subjective disatisfaction. Your job is not to pass judgment on the objective worth of their disatisfaction. If you asked for feedback, your job is to listen and try to understand.

"That doesn't make any sense." Believe it or not, I have heard variations on this. Ironically, thinking that is essentially how the person giving feedback probably felt when trying to use your thing. So rather than judging the sense of what they're saying, try to better understand why they expected it. Again, your goal is not to get them to go away or to defend your thing. Your goal is to understand their perspective, their motivations and expectations. Accept and affirm their perspective, rather than judge and defend your own.

Insist on Having the Last Word

Don't do it. This is good general advice, and in this context, it tends to apply to when you've already started down a bad path by doing one of the above. For example, if you start explaining it, the other person will feel inclined to explain their perspective, and you both grow increasingly defensive. And I say this 100% from personal experience--it can be one of the most difficult things to just shut up and let them have the last word.

As someone who is very good at arguing and can often argue successfully and still ultimately be wrong, this is a hard thing to learn and even harder to practice. Because it's like a good chess match--move, counter move, formulate strategy, plan moves in advance, and watch the "enemy" fall into your clutches. Exhilarating, but completely counterproductive when you are asking for feedback.

Remember the goal. To understand and adapt your thing so that more people love it. You won't get there by arguing with people, no matter how satisfying that feels in the short term. (As an aside, this applies in most life situations.)

What Do You Think?

Do you think this sort of thing is helpful? Do you have your own examples? I'd love to get more folks sharing their own examples so we can all learn from each other. Feel free to contact me personally, in a comment here, or even publish your own in the series. Something like, "An Introvert's Guide to Being Sociable: <your example>" would be fine, and link back here/post a comment. Maybe we just make a unique-enough tag, like #socialskills, to categorize these together, or if I find enough, I can manage a list post..

Top comments (2)

Collapse
 
ambroselittle profile image
Ambrose Little • Edited

Ah, good point. I didn't really suggest how to deal with meanies. As a one-time dev tools product manager, yeah, I've had to deal with that. If it's in person, you say, "thank you. That's good feedback." And file it away in ignore bucket in your head, while smiling. :) Don't engage or argue! (a.k.a., don't feed the trolls)

That said, sometimes there are gems of valid feedback even when hostilely communicated, so try to keep an open mind. Sometimes you can even turn angry folks around, if you find the underlying feedback insightful and are able to show that you care and (even better) can make it better.

Collapse
 
rpalo profile image
Ryan Palo

Think of needing to use a manual as a failure of Design. It's not always, but many times it is.

I really, really like these sentences.

Thanks for sharing this :)