Over the past couple of years, I’ve noticed a bit of a trend amongst those who would consider themselves activists for one cause or another that’s essentially, “it’s not the underprivileged person’s job to educate people with people about their privilege.” Or, somewhat surprised responses to general questions from an ignorant person that they are ignorant on a topic the activist cares deeply about.
To be clear, for the record: I do not at all disagree that it would be best if people would put in more effort to examine their own privilege. People educating themselves is a much more scalable way to approach the problem when there are limited resources in time and energy. I’m very fortunate in that I haven't yet had so many experiences in having to explain the same thing over and over to others that I feel completely wearied by the effort and resentful of having that being seen as my “responsibility” to represent some entire group that I might be a part of.
The area where I might have come closest on this on is sharing with people who didn’t grow up around many Asian-American immigrant families what that was like. Amy Chua made this a lot easier in the last few years by writing her Tiger Mom book, but I just don’t particularly get tired of talking about how my childhood was different from a lot of other people’s with things like, “oh, you got a 99 on that math test? what did you do wrong?” kind of thing.
Here’s the big BUT that I’m of course leading up to: BUT, while it would be ideal for people to put more effort in, especially those that describe themselves as allies, I see the reality of the world as one where people are mainly motivated to do things that benefit themselves. Pretty much by definition, someone with privilege generally benefits from not examining that privilege too deeply. A layperson cares less about an issue than an activist does, because they’d be an activist already otherwise!
So appealing to people’s better natures and calling for them to do work seems to me as though it will be inevitably less successful.
If you’re the one that cares more about something, telling people more or less, “if you were a good person, you would care more, and if you cared more, you would do work and know more about it already” is not very effective to getting people to be on your side.
I watched a discussion awhile back about the challenges in interactions between socially awkward people* and people who don’t feel safe in a certain environment. On the one side, I don’t think it’s the “victim’s” responsibility to have to say right then and there, “you’re making me uncomfortable, please stop that.” There are plenty of good reasons why that is not a catch-all solution to resolving these situations.
My issue is with people for whom it seems almost a matter of principle that they should not have to explain to someone why something is inappropriate and should therefore be stopped. It’s almost like an assumption that people should just know what they should do to be decent human beings, by generally acceptable standards. Like again yes, ideally, we would never have to explain to any guys why street harassment is a bad thing they should not do.
But, when you run into something you want it to be stopped, your ultimate goal is to have fewer instances of this happening in the world, right? And explaining why it’s inappropriate will help you achieve that goal, in my opinion.
You may have another goal of not wanting to spend all your energy fighting with and educating other people all the time, which is also a perfectly fair and legitimate choice. But to me, it seems like having a principled stance against having to clearly explain the problem (which is not to say you have to have a customized response each time either, you can point people to something pre-written to read, if you have it) and always expressing your (valid, and deserved) anger at the world being an unfair place can get in the way of you getting what you want.
In conclusion, as a general life philosophy: Staying upset about how people are fundamentally pretty selfish and lazy can be a distraction from getting what you actually want. Do the things that will get you what you want instead.
Further reading: Getting More: How to Negotiate to Achieve Your Goals in the Real World
*One example is men in tech who’ve been diagnosed with autism-spectrum syndromes like Aspergers, or are just generally kind of awkward, interacting with women in tech, who are in the minority, and in general who in all likelihood have had to deal with many, many male creeps in her past. Yes, "autism is to blame for harassment of women" is trotted out and used as an excuse, even though pretty much everyone is capable of learning sufficient social norms not to harass others. However, there are a non-zero number of real-life cases where social awkwardness is in fact the cause.
Some thoughts on giving feedback effectively
December 16, 2014
I think a lot about the process of giving and receiving feedback a lot, because one of the concepts I'm a little obsessed with is how what you don't know, that you don't know, can have an outsized impact (the black swan theory). But also, I got a lot of feedback myself earlier in my career that I needed to improve at delivering feedback in the right forums and to the right people in a way that would actually effect the change I wanted to see.
I don't tend to have very much trouble coming up with content for feedback thanks to being trained by my Tiger Mom to always, always, relentlessly be asking and thinking about, “How could this be better? How could this be more efficient?” That incessant drive to improve is enormously powerful, but I know it can also be enormously irritating to be around, too. I've learned that appropriately managing one's more annoying tendencies can be really useful to actually getting what you want. Another result of that drive is that I often have Many Opinions and Ideas, but there can be so many of them that I don't necessarily even care all that much about a lot of them! So I've developed some tactics for achieving the long-term changes I do care most about.
I'll use the example of giving people feedback on conference talks they're practicing, since that's been something I've been doing a lot of this in the past year. One co-worker told me after one such a practice talk that he's automatically going to invite me to all his future practice talks to get my feedback, which made me feel like I might be doing something right nowadays!
There's a lot that's been written about the “compliment sandwich.” The basic idea is that because people tend to react more strongly to criticism, you should deliver positive feedback and encouragement before and after a piece of negative feedback in order to soften it. However, in practice, this can come across as kind of fake and formulaic, resulting in people still only hearing the negative feedback and then thinking you're a phony on top of it, like in this 30 Rock bit.
I think the key nugget to this idea is that you need to avoid overwhelming people with criticism. If you don't have enough substantive positive feedback of specific things people did well and should do more of, you need to prioritize and limit the pieces of negative feedback you give them, at least in that same session. You can always save the less important feedback for the next time. If I go to multiple practices of the same talk, usually at the very least, I can comment on the ways in which I observed they're put a lot of work into improving from the last practice.
When I'm sitting in on a practice talk, I take copious notes on items that probably fall into one of these categories:
The last two are particular items to watch out for, because I've noticed that in a lot of these practice talks, the presenters are usually running pretty close to time already, and then everyone (including myself) usually gives them suggestions of even more stuff they can include, which would of course bring them over time. So input on prioritizing what should be kept and what should be cut can be very useful and reduce being overwhelmed by the volume of suggested changes.
Once I have these notes down, because I tend to have a lot of them, I'll usually try to give it a moment and let other people start off with giving their feedback, while I take some time to prioritize and organize my points. Usually other people are less verbose, so it helps warm up the mood for feedback before I go in all guns blazing. The prioritization is to make sure I have enough of the positive stuff upfront and I can lead off with the suggestions I think would have the biggest impact. I also try to save a piece of really easily changed item for the end, so that if nothing else, people can seize on that small thing to change and feel good about accomplishing that (and helps me save face if they hate all my other suggestions). This prioritizing on the fly takes some practice. My notes have a lot of circles and arrows drawn on them after I do this.
Finally, another important tactic is to modulate your feedback based on how it's being received. Some people aren't very good yet at receiving feedback without feeling defensive. You can tell this is happening when you start getting a lot of explanations for why they chose to do things in that talk, versus just writing down or asking questions back to clarify the feedback. Again, because of that Tiger Mom influence, my instinct tends to be to still want to help people even if they don't really want to be helped that much right now. However, I've learned that preserving the relationship is more effective overall (and gives you a chance for your feedback to be established as trustworthy, even if it isn't taken at first), so I'll persist a little bit but then rapidly cut out a lot of what I was going to say if it seems like it isn't going over all that well.
In conclusion, this:
I don't tend to have very much trouble coming up with content for feedback thanks to being trained by my Tiger Mom to always, always, relentlessly be asking and thinking about, “How could this be better? How could this be more efficient?” That incessant drive to improve is enormously powerful, but I know it can also be enormously irritating to be around, too. I've learned that appropriately managing one's more annoying tendencies can be really useful to actually getting what you want. Another result of that drive is that I often have Many Opinions and Ideas, but there can be so many of them that I don't necessarily even care all that much about a lot of them! So I've developed some tactics for achieving the long-term changes I do care most about.
I'll use the example of giving people feedback on conference talks they're practicing, since that's been something I've been doing a lot of this in the past year. One co-worker told me after one such a practice talk that he's automatically going to invite me to all his future practice talks to get my feedback, which made me feel like I might be doing something right nowadays!
There's a lot that's been written about the “compliment sandwich.” The basic idea is that because people tend to react more strongly to criticism, you should deliver positive feedback and encouragement before and after a piece of negative feedback in order to soften it. However, in practice, this can come across as kind of fake and formulaic, resulting in people still only hearing the negative feedback and then thinking you're a phony on top of it, like in this 30 Rock bit.
I think the key nugget to this idea is that you need to avoid overwhelming people with criticism. If you don't have enough substantive positive feedback of specific things people did well and should do more of, you need to prioritize and limit the pieces of negative feedback you give them, at least in that same session. You can always save the less important feedback for the next time. If I go to multiple practices of the same talk, usually at the very least, I can comment on the ways in which I observed they're put a lot of work into improving from the last practice.
When I'm sitting in on a practice talk, I take copious notes on items that probably fall into one of these categories:
- the points that I strongly agree with, usually with some additional suggested examples for them to use to further emphasize that point
- any slides or points I thought were particularly clever or awesome in some way
- the parts I was confused by and any questions that came up in my mind (a preview of what might come up in Q&A)
- my observations on any differences between the emergent structure from their talk based on my synthesis of the content as they've delivered it, and the actual structure of their talk, in order to make the talk flow more smoothly (ex. “I think part 2 was actually good background for part 1, so you should reverse the order of those two sections”)
- any sections that could be candidates for being cut, if they're going over time
- which sections I think they should definitely keep
The last two are particular items to watch out for, because I've noticed that in a lot of these practice talks, the presenters are usually running pretty close to time already, and then everyone (including myself) usually gives them suggestions of even more stuff they can include, which would of course bring them over time. So input on prioritizing what should be kept and what should be cut can be very useful and reduce being overwhelmed by the volume of suggested changes.
Once I have these notes down, because I tend to have a lot of them, I'll usually try to give it a moment and let other people start off with giving their feedback, while I take some time to prioritize and organize my points. Usually other people are less verbose, so it helps warm up the mood for feedback before I go in all guns blazing. The prioritization is to make sure I have enough of the positive stuff upfront and I can lead off with the suggestions I think would have the biggest impact. I also try to save a piece of really easily changed item for the end, so that if nothing else, people can seize on that small thing to change and feel good about accomplishing that (and helps me save face if they hate all my other suggestions). This prioritizing on the fly takes some practice. My notes have a lot of circles and arrows drawn on them after I do this.
Finally, another important tactic is to modulate your feedback based on how it's being received. Some people aren't very good yet at receiving feedback without feeling defensive. You can tell this is happening when you start getting a lot of explanations for why they chose to do things in that talk, versus just writing down or asking questions back to clarify the feedback. Again, because of that Tiger Mom influence, my instinct tends to be to still want to help people even if they don't really want to be helped that much right now. However, I've learned that preserving the relationship is more effective overall (and gives you a chance for your feedback to be established as trustworthy, even if it isn't taken at first), so I'll persist a little bit but then rapidly cut out a lot of what I was going to say if it seems like it isn't going over all that well.
In conclusion, this:
"Please give feedback that is Actionable, Specific, and Kind." @Bontgoy that's a great way of putting it.
— Adewale Oshineye (@ade_oshineye) October 22, 2014
Some quick thoughts on talk proposals
December 9, 2014
If you have a talk proposal that's a bit more technology-agnostic, and/or you want a bit of a niche audience, submit to the bigger conferences in the different languages (your PyCons, RailsConfs). I think you'd have a better chance of being accepted that way.
For example, I didn't bother submitting my “How to be a Better Junior Developer” talk proposal to RubyConf, since there's probably a lot of overlap between attendees there and RailsConf, both being in Chicago and in the Ruby/Rails world.
Don't put pressure yourself to come up with a totally original idea, or on a technical topic, if those aren't the ideas you have right now. I've found a lot of other programmers that are also very interested in the intricacies of communication and psychology. Also, it turns out that the beauty of giving a talk on communication is that the people that come up to you afterwards are pretty much all into the topic. Because after all, the people who disdain the topic are probably not great communicators themselves, and poor communicators don't communicate :)
I think in a way, it might be slightly easier to get a talk accepted at a big conference, since there's a wider variety of interests in the attendees. The small regional conference feels a lot more manageable though, and an unforeseen benefit to me is that if you speak there, you become more known to the more prominent members of the community that are also speaking there since they're sitting through all the talks at the conference.
For example, I didn't bother submitting my “How to be a Better Junior Developer” talk proposal to RubyConf, since there's probably a lot of overlap between attendees there and RailsConf, both being in Chicago and in the Ruby/Rails world.
Don't put pressure yourself to come up with a totally original idea, or on a technical topic, if those aren't the ideas you have right now. I've found a lot of other programmers that are also very interested in the intricacies of communication and psychology. Also, it turns out that the beauty of giving a talk on communication is that the people that come up to you afterwards are pretty much all into the topic. Because after all, the people who disdain the topic are probably not great communicators themselves, and poor communicators don't communicate :)
I think in a way, it might be slightly easier to get a talk accepted at a big conference, since there's a wider variety of interests in the attendees. The small regional conference feels a lot more manageable though, and an unforeseen benefit to me is that if you speak there, you become more known to the more prominent members of the community that are also speaking there since they're sitting through all the talks at the conference.
Guide for newbie tech conference attendees
December 2, 2014
Now that I've been to two different multi-day conferences (and having made mistakes in how I approached them), I thought I'd pull together some tips for trying to get the most out of attending your first conference without getting completely overwhelmed.
0. Think a little bit about what your goal for the conference is, so that you have a heuristic for deciding what you want to do. Is it to learn a lot about a particular kind of technology? Is it meeting new people? For example, there were a few different informal socializing events at ArrrrCamp after the first day of the conference. One of those was rock climbing, which I was interested in trying out for its own sake, but my actual goal for the conference really was to meet people and have good conversations (while not getting overwhelmed like I did at RailsConf). So instead, I signed up for the bowling event. When the time actually came to it, my jetlag was hitting me pretty badly and I didn't want to go to an event where I might feel obligated to stay longer than I could really get myself to stay awake, so I instead went on the photo walk around the city where I could both easily chat up different people and leave early if I was about to fall over.
1. If there are any offers of some kind of conference guide program or attendee matchmaking program, sign up for it!! RailsConf had repeated messages about their program, but I didn't take them up on it because I thought I was taking up enough of their resources already from the support they were giving me as a first-time speaker, and I figured it was really more for solo first-time attendees. I also figured I'd be able to rely on my co-workers that were also attending. My co-workers really tried, but I ended up feeling bad about constantly asking to tag along with them and would then lose track of them. The accounts I heard of the guide program seemed pretty positive.
2. If there are specific people that you want to meet, take the initiative (probably over Twitter) to try scheduling breakfast/lunch/coffee/dinner dates or what-have-you instead of hoping to bump into them at one of the happy hours. I keep re-learning the fact that I dislike trying to get to know people in the loud and crowded environment of most happy hours. When instead I did things like reconnect with an old middle school friend over lunch at Portillo's, that was immensely more fun and effective.
3. Attend the lightning talks! I so regret not seeing Liana Leahy's rendition of “Let Me Code” (sung to “Let Me Go” from Frozen) in person. Anyway, lightning talks seem to be pretty reliably high value for your time, since the talks that are boring tend to be boring because there hasn't been enough editing to cut out irrelevant content.
4. Attend any smaller events you might hear about going on. Joanne gave me a tip about a thoughtbot podcast that was going to be recorded there one afternoon where Ben Orenstein interviewed Aaron Patterson, which ended up being in a fairly small room but was really cool to be in on.
5. However, IT IS OK TO SKIP EVENTS. I might've gotten more out of some talks if I'd gone to fewer overall or left some talks early after it looked like I wasn't going to get much out of them.
6. Along that theme, it's really important to take care of yourself. One of the best decisions I made during RailsConf was to sleep in the morning after my talk and spend the morning catching up and messing around on Twitter instead of going to see the keynote for that day (which was apparently quite funny, but I didn't think it would as important for me to see vs. DHH/Yehuda/Aaron Patterson etc.). I felt so much better about life, and then the first talk I did go see that day was Sandi Metz's, which was amazing already but particularly inspiring because I wasn't desperately exhausted anymore. At ArrrrCamp, I let myself sit alone and skip out on some of the socializing breaks in the afternoon of day 1 because it seemed like it would take more energy than I had left to get out of my seat to go talk to people (I promised myself I'd be better about it the next day, after getting a full night of sleep).
6a. Bring/eat more snacks. I get hangry pretty easily and the conference (being around so many people, attending all these talks I'm trying to pay close attention to, etc.) sucks up a lot of energy, so it would help to compensate for that with more snack consumption.
6b. Sleep more. Probably still won't get normal hours of sleep from being overstimulated, but just aim for as much as you can so you're not knocked off too much from your normal rhythm.
6c. There really are a lot of men around at tech conferences. It's always a bit overwhelming. My method for dealing with it is to let myself take a moment to acknowledge it before diving in to mingle or whatever.
7. I tried to take notes during all the talks I attended but I'd also come up with all sorts of ideas while sitting on talks (like new talk proposal ideas, things to dig into further afterwards, etc). I had a hard time re-finding those notes since I wasn't really taking notes on the talks to go through them again afterwards, but this got easier once I developed a different system for those notes to myself that I wanted to find again. I took notes on a reporter-style spiral notepad and put all my talk-notes on one side of the pages and all my notes-to-self on the other side so that I could flip backwards through and catch all the pages that had the notes I wanted to find again. Putting those notes aside in a draft email also worked.
8. Everyone talked so much about how the “hallway track” (general mingling and meeting new people in the hallways, outside of the talks themselves) would be the best part of the conference but I had a lot of trouble with this at RailsConf. A lot of people were on their laptops, so despite a co-worker's advice to just go up to people and ask them what they were working on, I couldn't bring myself to do that because it felt like I'd be interrupting them and I was afraid they'd be really annoyed about it. Instead, what worked a lot better for me was introducing myself to people that I sat near, before the beginning of the talk. That was a lot more similar to starting up conversations with strangers on public transit with random comments or observations, so I felt more comfortable with that.
8a. Another tactic to try is to bring your fandom or nerdy joke t-shirts to wear. This worked well for me when I wore my Veronica Mars t-shirt on day 2 of AdaCamp earlier this year, since that broadcast a potential shared area of interest to get a conversation going about.
9. When you tweet about the conference, using the hashtag instead of the official conference account handle so that others at the conference will pick up on the hashtag without the official account needing to retweet it.
10. Wear clothes that have pockets in order to not have to lug a bag around, or at most just have a light tote bag for my notepad and pen.
11. I didn't end up handing out all that many business cards. For most people, exchanging Twitter handles was sufficient, so I needn't have packed my whole heavy box of business cards, just brought a few extras.
(Note added 12/8/14: I started numbering this list at 0 because I wrote the post with all the numbers manually, then wanted to go back and add in a first point without having to renumber the rest. So think lazy, more than cutesy programmer numbering logic, lol)
0. Think a little bit about what your goal for the conference is, so that you have a heuristic for deciding what you want to do. Is it to learn a lot about a particular kind of technology? Is it meeting new people? For example, there were a few different informal socializing events at ArrrrCamp after the first day of the conference. One of those was rock climbing, which I was interested in trying out for its own sake, but my actual goal for the conference really was to meet people and have good conversations (while not getting overwhelmed like I did at RailsConf). So instead, I signed up for the bowling event. When the time actually came to it, my jetlag was hitting me pretty badly and I didn't want to go to an event where I might feel obligated to stay longer than I could really get myself to stay awake, so I instead went on the photo walk around the city where I could both easily chat up different people and leave early if I was about to fall over.
1. If there are any offers of some kind of conference guide program or attendee matchmaking program, sign up for it!! RailsConf had repeated messages about their program, but I didn't take them up on it because I thought I was taking up enough of their resources already from the support they were giving me as a first-time speaker, and I figured it was really more for solo first-time attendees. I also figured I'd be able to rely on my co-workers that were also attending. My co-workers really tried, but I ended up feeling bad about constantly asking to tag along with them and would then lose track of them. The accounts I heard of the guide program seemed pretty positive.
2. If there are specific people that you want to meet, take the initiative (probably over Twitter) to try scheduling breakfast/lunch/coffee/dinner dates or what-have-you instead of hoping to bump into them at one of the happy hours. I keep re-learning the fact that I dislike trying to get to know people in the loud and crowded environment of most happy hours. When instead I did things like reconnect with an old middle school friend over lunch at Portillo's, that was immensely more fun and effective.
3. Attend the lightning talks! I so regret not seeing Liana Leahy's rendition of “Let Me Code” (sung to “Let Me Go” from Frozen) in person. Anyway, lightning talks seem to be pretty reliably high value for your time, since the talks that are boring tend to be boring because there hasn't been enough editing to cut out irrelevant content.
4. Attend any smaller events you might hear about going on. Joanne gave me a tip about a thoughtbot podcast that was going to be recorded there one afternoon where Ben Orenstein interviewed Aaron Patterson, which ended up being in a fairly small room but was really cool to be in on.
5. However, IT IS OK TO SKIP EVENTS. I might've gotten more out of some talks if I'd gone to fewer overall or left some talks early after it looked like I wasn't going to get much out of them.
6. Along that theme, it's really important to take care of yourself. One of the best decisions I made during RailsConf was to sleep in the morning after my talk and spend the morning catching up and messing around on Twitter instead of going to see the keynote for that day (which was apparently quite funny, but I didn't think it would as important for me to see vs. DHH/Yehuda/Aaron Patterson etc.). I felt so much better about life, and then the first talk I did go see that day was Sandi Metz's, which was amazing already but particularly inspiring because I wasn't desperately exhausted anymore. At ArrrrCamp, I let myself sit alone and skip out on some of the socializing breaks in the afternoon of day 1 because it seemed like it would take more energy than I had left to get out of my seat to go talk to people (I promised myself I'd be better about it the next day, after getting a full night of sleep).
6a. Bring/eat more snacks. I get hangry pretty easily and the conference (being around so many people, attending all these talks I'm trying to pay close attention to, etc.) sucks up a lot of energy, so it would help to compensate for that with more snack consumption.
6b. Sleep more. Probably still won't get normal hours of sleep from being overstimulated, but just aim for as much as you can so you're not knocked off too much from your normal rhythm.
6c. There really are a lot of men around at tech conferences. It's always a bit overwhelming. My method for dealing with it is to let myself take a moment to acknowledge it before diving in to mingle or whatever.
7. I tried to take notes during all the talks I attended but I'd also come up with all sorts of ideas while sitting on talks (like new talk proposal ideas, things to dig into further afterwards, etc). I had a hard time re-finding those notes since I wasn't really taking notes on the talks to go through them again afterwards, but this got easier once I developed a different system for those notes to myself that I wanted to find again. I took notes on a reporter-style spiral notepad and put all my talk-notes on one side of the pages and all my notes-to-self on the other side so that I could flip backwards through and catch all the pages that had the notes I wanted to find again. Putting those notes aside in a draft email also worked.
8. Everyone talked so much about how the “hallway track” (general mingling and meeting new people in the hallways, outside of the talks themselves) would be the best part of the conference but I had a lot of trouble with this at RailsConf. A lot of people were on their laptops, so despite a co-worker's advice to just go up to people and ask them what they were working on, I couldn't bring myself to do that because it felt like I'd be interrupting them and I was afraid they'd be really annoyed about it. Instead, what worked a lot better for me was introducing myself to people that I sat near, before the beginning of the talk. That was a lot more similar to starting up conversations with strangers on public transit with random comments or observations, so I felt more comfortable with that.
8a. Another tactic to try is to bring your fandom or nerdy joke t-shirts to wear. This worked well for me when I wore my Veronica Mars t-shirt on day 2 of AdaCamp earlier this year, since that broadcast a potential shared area of interest to get a conversation going about.
9. When you tweet about the conference, using the hashtag instead of the official conference account handle so that others at the conference will pick up on the hashtag without the official account needing to retweet it.
10. Wear clothes that have pockets in order to not have to lug a bag around, or at most just have a light tote bag for my notepad and pen.
11. I didn't end up handing out all that many business cards. For most people, exchanging Twitter handles was sufficient, so I needn't have packed my whole heavy box of business cards, just brought a few extras.
(Note added 12/8/14: I started numbering this list at 0 because I wrote the post with all the numbers manually, then wanted to go back and add in a first point without having to renumber the rest. So think lazy, more than cutesy programmer numbering logic, lol)
Subscribe to:
Posts (Atom)