Talking Pay in the Public Square

J. Paul Reed
7 min readSep 24, 2018

In America, it is generally considered taboo to discuss salaries.

Some of this is surely rooted in socially normative behavior, where discussions of personal finances are considered conversation’s most intimate tier. Some of it probably comes from that stigma being cemented into the “professional identity” expected of employees. (Some companies have even gone so far as to make open salary discussions a dismissible offense!)

This is unfortunate, because sharing compensation information is the best way to get an unfiltered pulse on the local job market, to correct for socio-economic, racial, gender, and other prejudices, and put labor on a more stable footing with management, especially in the tech industry where if you utter the word “union,” you’d better be talking about the memory-saving alternative to structs.

I’ve always believed that on-the-whole, more information is generally better. That’s why I was fascinated with the #TalkPay movement launched in 2015 by Lauren Voswinkel: people posted their job titles and salaries on Twitter, shattering notions of what was “proper” and “private” information.

It was deliciously simple, delightfully subversive, and incredibly effective.

I happened to be at DevOps Days Austin when the original #TalkPay hashtag was winding down, so I thought “Heck, why not do it here, as an open space?”

Of course, exchanging this information presents some challenges in an “IRL
space, so I had to think on my feet about how to #TalkPay while creating a sufficiently safe space (both psychologically and professionally) for people to have that conversation.

Since that Austin DevOps Days in 2015, I’ve run #TalkPay at DevOps Days Denver (twice, in fact), DevOps Days Austin (also twice), and DevOps Days Chicago.

People had such a positive experience and got so much value out of getting more information about their local job markets, I’ve been asked repeatedly to write up the process.

Before doing the exercise, I start with a discussion with the group about what we’re going to do with the data it generates; there are generally two items to decide:

  1. What are we going to do with the data on the poster boards, that is: “Can we take pictures of it?” Some groups are OK with this. Others are not. I usually err on the side that if even a few people are uncomfortable, we don’t allow it. Most groups end up playing by Vegas-rules here: what happens in the open space, stays in the open space, so… no photography.
  2. What are we going to do with the data afterward? Often, people will want to see all the provided data. I’ll ask how everyone feels about that. If it looks like a supermajority of people present (66+%) want to see the data, I offer to collate it up, but I also tell people to write “opt-out” on their submission if they don’t want it included in the summary. We still put their base salary number on the poster board in the ops/dev/other group they specified, but it’s not included in the spreadsheet sent out afterward.

Interestingly, most groups don’t want the information in the room taken outside of the room, but they do want the summary sent out afterward.

Discuss this with the group before running the exercise, so everyone is on the same page about what will happen with the data, and can make decisions that are right for them.

This also means I take responsibility for taking down and destroying the poster boards after the open space.

Here’s the process I’ve used to #TalkPay IRL:

  1. Invoke the space: Like an incident postmortem, an all hands, or any other
    potentially difficult meeting, it’s important to invoke the space. I do this by telling people we’re talking about a generally-considered taboo subject, and as such, we all need to slow down, pay closer attention to each other, and recognize that it can be difficult to talk about these topics. We need to respect other people’s boundaries and step, speak, and act deliberately. Setting this stage early helps to put people in the right frame of mind and heads off a lot of potential problems.
  2. I explain that to be a part of #TalkPayIRL, every participant needs to
    answer the next three questions
    . If they’re not comfortable answering all
    three, that’s OK, and they should feel free to observe.
  3. On a piece of paper — sticky notes do not work well for this; index cards or a piece sheet of paper torn in half does — I ask the following three questions:
    a. Categorize yourself: developer, operations, or other. (I pick these buckets because we’re usually at a DevOps Days event, so they’re a natural bucketing.)
    b. Job location: I tell people they can be as specific or general as they
    like: some will be pretty specific (“North Denver”); others
    might put “Colorado” or “America.” Whatever they put is fine.
    c. Base salary: rounded to the nearest hundred dollars.
  4. I then also ask the following questions, but I make it clear, THESE QUESTIONS ARE OPTIONAL.
    They’re optional because they solicit more information from people, and people should feel comfortable not-answering any of these questions. They’re welcome to answer all, a few, or none of them:
    a. Your gender: this is to surface information about gender bias in the local job market.
    b. Any notable additional benefits provided above your base salary: options, RSUs, bonuses, weird/interesting perks and benefits, etc. This is to allow people to further contextualize their base salary if they want. (Plus, I’ve seen some pretty interesting/wild perks and benefits.)
    c. Years at your current company: Gives some context about when the
    person’s salary was “reset” to the market
    d. Years experience in the industry: Gives some context around career/seniority
  5. I then ask people to put their paper in a (physical) container or bucket, again, one for Dev, one for Ops, one for Other; we then ask people to be patient with us while we sort the salaries, and write them, from low to high, on poster board. Every salary is written down, so if ten people make $90,000, we write “$90,000” on the poster board ten times.

We then take five or so minutes to let people look at each of the poster boards. #TalkPayIRL is generally held as an open space, so after that, I generally facilitate a conversation about what we see:

  • What’s the highest salary in each bucket? The lowest? The estimated median? Are they all what you expected?
  • What patterns do you notice?
  • Does anything surprise anyone?
  • Are any outliers or otherwise “weird” data points? What do you think explains it?
  • How does this data make you feel?

These conversations always take on a life of their own. Hiring managers will usually have a lot to say here. People will ask how they can get the salaries they see on the poster boards. People share stories about asking for raises, including what worked and didn’t work. We’ve discussed the gender and racial biases even this very high level data betrays.

Invariably, someone will point out that this data is not very useful, because job titles aren’t included in the summary data on the poster boards. I agree and then ask if anyone was worried about sharing their salary; hands also invariably go up, which is a great entrée to discussing why providing even this level of information can be so difficult socially, dissecting why we’re told that even a gathering a list of numbers is supposedly so dangerous.

I am often asked “How can you even think of doing this exercise?” or “Isn’t it difficult?”

It can be difficult to navigate these conversations, but ultimately, I think it’s been worthwhile:

  • I have said “adding DevOps to your title will net you an extra $20-$30 thousand in salary.” While this sounds funny, it wasn’t a joke: it was based on numerous #TalkPayIRLs held in 2015 and that revelation prompted numerous people to make edits to their resume.
  • I have had conversations with numerous women afterward who are both surprised and angry at the data. They use the experience to start figuring out how to fix this problem.
  • In probably the most egregious example: one of these exercises surfaced a DevOps engineer who was making $40k a year. At next year’s DevOps Days, I asked how he was doing, and he said he quit about six weeks after last year’s event, and was now being paid a market rate.
  • At one event, a manager pulled me aside an hour or so after #TalkPayIRL, and scolded me for running it: “Y’know, I just had to have a couple of really uncomfortable conversations with two junior engineers I brought to this event, because their numbers were at the bottom of the range. I didn’t appreciate that.” I stared blankly at her. My immediate reaction was “Sorry-not sorry?” While #TalkPayIRL is never intended to create difficult situations — and therefore, I am sorry she had to have that conversation, unexpectedly, at a tech conference — I am very much not-sorry two people were provided with new information that they were actively being undervalued and taken advantage of in the marketplace. I will never feel bad for facilitating knowledge transfer that, quite literally, materially improves people’s lives.

I wholeheartedly believe in facilitating #TalkPayIRL.

And I believe in continually holding them, because the market is not static, and various economic injustices continue to permeate the tech industry.

Since I’ve been asked about #PayTalkIRL, one of the changes I recently made
was collecting the data via a Google Form: this significantly reduces sorting time (because #computers), and allows us to get the salaries written on the poster board more quickly. It also means we don’t have to do data entry, if the group wants the data afterward. (You do, however, need to redact data people asked not be shared; don’t forget to do this!)

(Unfortunately, because of the way Google Forms works, I can’t share the editable form, but if you DM me on Twitter, I’ll duplicate the form for you and make you the owner, so you can easily run your own #TalkPayIRL!)

Oh, and I’d love to hear how any #TalkPayIRL events you run go: feel free to tweet your experiences with the hashtag and tag me at @jpaulreed!

--

--

J. Paul Reed

Resilience Engineering, human factors, software delivery, and incidents insights; Principal at Spective Coherence: What Will We Discover Together?