Remembering Nóirín Plunkett

Head and shoulders photograph of Nóirín Plunkett, a pale skinned white person with glasses and dyed pink and orange hair, wearing a white lacy blouse. They are smiling straight at the camera.
Nóirín in 2011, by Paul Fenwick CC BY

This article was originally published on the Geek Feminism wiki . It is republished here according to the terms of its Creative Commons licence, with a revised title and slightly edited.

Nóirín Plunkett (1985–2015, also known as Trouble Plunkett and for a few years as Nóirín Shirley) was a Apache Software Foundation VP, technical writer, public speaker, FOSS documentation contributor, and software and technology industry project manager. They died in July 2015.

Memorials

Warning: not all memorials used Nóirín’s preferred pronouns: they/their/them.

Obituaries: Irish TimesMassachusett

External links

Internet Archive: Nóirín’s blog

Creative Commons License
Remembering Nóirín Plunkett by Geek Feminism Wiki contributors and Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Based on a work at https://geekfeminism.fandom.com/wiki/N%C3%B3ir%C3%ADn_Plunkett.

Be selfish: if it needs to be done someone else can do it

In 2009, in “Girl stuff” in Free Software, I recounted a conversation with Brianna Laugher:

[Brianna] said — paraphrased — that she didn’t feel that she should have a problem or be criticised for doing what she is good at, or what’s so desperately needed in her communities, and have to be just another coder in order to be fully respected. And I said that while this was certainly true, women also need to have the opportunity, to give themselves the opportunity, to be selfish: if we want to code, or do something else we are currently either bad at or not notably good at, or for that matter which we are good at but in which we’d have competitors, we should consider doing that, rather than automatically looking for and filling the space that is most obviously empty

(See also Brianna’s response.)

Since then, I’ve seen this pattern recur, most recently in some of the discussion around Valerie Aurora’s Advice for women in tech who are tired of talking about women in tech: women who are doing things because, well, the thing needs to be done and no one is doing it, even if what drew them to the job or the project was something else entirely than the chores they’ve ended up with. This is particularly true when the chore has some benefit to others: writing documentation, welcoming newcomers, setting up the translation team, establishing the not for profit and such.

This not only can make women miserable as they find themselves doing a lot of things out of a vague sense of duty, it quite frequently leads to no rewards whatsoever. For others, it’s really nice when the documentation gets written or the notes get taken or the funds get raised without having to figure out how to give someone a promotion or a keynote slot for it, or how to build up a healthy chain of people moving through the task and onto other things! How fortunate for your boss or your project, and how unfortunate for you.

Quite often a good dollop of selfishness is what this situation deserves, and what you deserve too. There is of course a tight limit to which women can or should personally solve the problem of being handed or expected to quietly assume chores and hover around in the background making sure all the wheels are greased, but let’s explore how far you can get, when it’s time to be selfish.

Note throughout this entry that “chores” are very relative. You may not be a natural fit for translating conversations or documents just because you’re fluent in multiple languages! You might want to write some code or do the accounting or answer the phones instead! But this doesn’t mean that documentation or translation are worthless activities that no one should do, just that they’re something that, at this time, and for this project, you want to stop doing.

Figure out what you’re getting out of the chore, and keep doing it.

I’m very often the notetaker in meetings that I’m in. While this is quite gendered (and I’ve occasionally had senior male colleagues notice and call it out, which is appreciated), I do get something out of it. I have trouble paying attention to and understanding conversations I’m present in that I don’t also write up; and, while we’re talking about being selfish, one of the more effective ways to control the agenda is to write it, and one of the ways to control the findings is to write them too.

So, I keep taking notes quite often, but I’m clear on what I’m getting out of it. I don’t take the notes for their own sake, and if I find myself in a situation where I’m losing the ability to participate in or lead a meeting due to being its notetaker, I’m more likely to reconsider whether there need to be notes and if so, whether I need to take them.

But let’s say you’ve thought about it, and you’re not getting something out of the thing, and you want to be done. But the thing is important, it is in some way making the world a better place. If so…

Accept that the project could fail without the chore.

Something to work through is knowing that the chore might be important to the success of the project, and that you’re deciding not to do it anyway.

Maybe the conference will be better with a more diverse lineup and so will the careers of the speakers. If no one sees the notes of the meeting then some important decisions will be missing context. A major security flaw might be hiding in those untriaged bugs.

But if the project’s success seems to depend on you, a single person, quietly stepping in and doing what must be done while everyone else does fun things, the project is either so fragile that it’s at high risk of failure regardless of your exceptional bug triaging and speaker finding skills, or it’s somewhat quietly robust, and will actually carry on just fine.

A related failure mode — “I’m so valuable that my boss won’t let me take vacation” — is something of an Ask a Manager perennial. As she tends to advise: what if you quit? If you quit and your chores are super important, your boss will either find a way to get them done after you leave, or the project will fail, and if it fails in your absence, it probably wasn’t that likely to succeed in your presence either.

So. If you’re the only thing standing between success and failure, you’re not on a great project. It might have great aims or ambitions, but it’s not a great project. So now it’s time to…

Stop doing the thing.

Just don’t do it. Let the bugs go untriaged, the newcomers go unwelcomed, the documentation go untranslated, the meeting go unrecorded, the conference not schedule any unicorn talks, the conference not have any women speakers at all.

While you worked through thoughts about the project failing above, many times, you’ll find that the thing wasn’t that important in the first place. No one much read the notes of that meeting, so maybe there didn’t need to be notes, and in fact, on reflection holding the meeting wasn’t that important either. The conference copped a lot of justified heat on Twitter for their all-male all-white lineup and… probably they deserved it since they were using you to shield them from it before. Speakers of your other fluent language migrated to other software that had a translation team dedicated to their needs, and were better off for it. And so on.

How to just stop:

  • Unsubscribe from the project email list.
  • Block your browser from letting you look at the bug tracker.
  • Delete the request for help finding women for the panel.
  • Read back over your personal notes from the meeting, update your own todo list, but don’t type them up to send to the team.
  • Go on a long holiday.

Give some warning you’re going to stop doing the thing.

If you’re not truly silently labouring away alone, you might want to let people know you’re stopping. That’s fine; but be firm about it, give a date at which you’ll stop, and resist conditioning leaving on another volunteer stepping up. “I’d love someone to take over the server and I’m happy to train you” may work, but it also may not. In embracing selfishness per this post, you need to step down even if no one else is stepping up.

Some scripts:

  • “I’m not available as a volunteer sysadmin after the 1st. I’d love to hand off cleanly to a new sysadmin if possible. However if there’s no volunteers by the 1st, I will shut down the server and provide the data backups to [other person].”
  • “This is the last newsletter from me! If someone else wants to pick it up, here’s a one pager to get you started.”
  • “After some reflection, I’ve decided not to contest the next board election. I’m looking forward to seeing where a new president takes us.”

Ask if you can hand off the thing.

The above two strategies work less well in hierarchical situations like workplaces. If you’ve silently taken on chores or you’re volunteering for things outside your core position you can still use those strategies, but if your boss or another authority figure has told you to do the chore (especially if they told you to recently), probably you shouldn’t just stop and see what happens, let alone send an email unilaterally announcing you’ve decided to stop doing your job from the 1st.

But that doesn’t mean you need to silently do what you’re told at the expense of important work, or do unrewarded tasks while your peers get shiny things. There’s some alternatives you can explore with your workplace:

  • Ask if you can stop: make a case for the chore not being important at all, or not being as important as the other things you need to do
  • Rotate chores: set up a formal rotation of the chore between teams or members of the team
  • Pay someone: pay a bookkeeper for your organisation rather than relying on a series of burned out volunteer treasurers
  • Pay a specialist: hire a project manager or an office admin or a backend dev or a fundraising lead
  • Transition to a more junior staff member: maybe there’s someone who’d learn from writing those docs or triaging those bugs
  • Transition to a team: maybe there’s so many chores that there needs to be a project team addressing the chores and the source of them, and maaaaybe you could lead that team?

That said, in workplaces and other hierarchical organisations, ethical leadership should be avoiding disproportionately handing unrewarding tasks to women, younger people, and members underrepresented minorities, and should be actively considering these solutions themselves. If you’re in a situation where your leadership is happily reaping the rewards of you patiently picking up scutwork unrewarded…

Quit your entire position.

If your current position (paid or volunteer) is full of chores you aren’t rewarded for but that no one can be bothered sharing around or finding someone who’d be a better fit, and you’re fortunate enough to be able to find another position or you don’t need to, quitting is something to seriously consider. Head out the door and selfishly go find somewhere where what they need someone to do is the same thing that you want to be doing.

US tech resistance cheatsheet for Australians

I gave an Australian friend a rundown on my sources of information about US opposition to the incoming Trump administration, focussed on tech workers, and she pointed out that my resources were worth sharing; the “Australian technology worker following US tech industry organising” position is not very common. Here’s my little collection of links:

Tech Solidarity. Tech Solidarity is a series of meetings being run in major US cities for technology industry workers on the subject of solidarity with other workers and with technology users, against an authoritarian Trump regime. There’s a Tech Solidarity website, but the best place to find out about their meetings is their Twitter account, and the best place to find out about their politics is the @Pinboard Twitter account run by Tech Solidarity co-organiser Maciej Cegłowski.

Neveragain.tech. This is a specific pledge by technology industry workers to not be involved in building technology for the US government to target individuals based on race, religion, or national origin, as well as advocating for specific policies in our workplaces and protesting unethical practices. I am a signatory and several of my friends are organisers. A Tech Solidarity meeting was key in launching the pledge.

Indivisible Guide. A guide to influencing members of Congress when your goals are largely defensive and obstructionist, ie, to hinder the dominant party in Congress or the President’s party in implementing their policy platform.

While this guide is interesting, I think considerable caution is called for in applying much of it to Australian politics without asking Australian activists and staffers for their advice. For example, party discipline in Australia is extremely strong — your representatives, if members of a major party, almost invariably vote with that party — and Cabinet and the ministry are appointed from amidst the members rather than separately. The executive being drawn from the legislature is very very different to how the US executive branch works. The chapter on four local advocacy tactics that actually work may have some inspiration for beginning to engage with your state or federal MP’s local activities if you haven’t done so before.

There are several guides to opposing specific Trump administration policies and initiatives, such as Resistance Manual and the re:act newsletter. There must be more of these appearing every day; I’m not following them closely since the calls to action usually require being a constituent of US members of congress and/or being a US resident.

Learning more about a remote working position

I’m in the process of wrapping up a long period of working remotely at least part-time from home, beginning in 2006 when I enrolled in a PhD program and continuing through my time at the Ada Initiative and at Stripe to this year.

My take on working remotely in future is really “it depends on the details” (and likely different details for different organizations). To that end, I contributed some suggested questions you could ask to Hypothesis’s Working remotely guide, which they’ve incorporated in a slightly edited form. Here’s my original questions; I’ve also added a few more at my end after some feedback from Andrew (himself a veteran of around seven years of remote work).

Introduction

Before you start working remotely at a new organization, you should explore how they structure remote working and if there are any expectations mismatches between you and the organization. A particular remote job may or may not be a match for a particular remote worker.

Important: I don’t think there is any one right answer to any of these questions. It’s a question of fit between your working style, the position itself, and the relationship of the position to the rest of the organization. But the answers are worth knowing so that you can evaluate your fit and make plans for effective remote working.

Sources of information

This entry has a lot of questions, too many for a “do you have any questions?” section of an interview. But you can use other sources of information to get most answers, especially about organization-wide questions:

  • the job description, and descriptions of similar roles
  • the organization’s website, particularly the About and Careers pages
  • the section of the employee handbook dealing with remote work
  • the LinkedIn pages or websites of your future manager and colleagues
  • longer, separate, conversations with your recruiter or hiring manager
  • your offer conversation or letter, or your contract

Some questions you also may only need to ask if you hear of concrete plans to make a change to the organization (eg, you learn that a new office is about to open near you).

Questions

How are you remote and who are you remote from? This post is using ‘remote’ to mean something like “most days, you are not in face to face contact with any colleagues.” But you should be aware of the details: will you be working without in person contact with teammates or with the wider organization almost all of the time? Do you have any colleagues in your team or your wider organization in your city or region, or who regularly visit? Will you work on any joint projects with them? Will you be able or be expected to sometimes work with them in person even if there’s not a permanent office space?

Separately, is in-person contact with vendors or customers part of the job?

Is your immediate team remote? Is your manager remote? Being a remote member of a team that is all working remotely from each other is different from a team which is mostly located in an office with each other. Likewise, being managed by someone who is in an office has some potential advantages (for example, access to information circulating through verbal grapevines, being able to access answers from colleagues for you quickly), as does being managed by someone who is themselves remote (a direct appreciation for experiences specific to remote workers, a personal interest in advocating for them).

How many remote workers are there at the rest of the organization? What percentage of teams you will work closely with are working remotely, and what percentage of employees overall are working remotely? Working as one of very few remote workers for an organization where most employees are in an office together is different from a mostly or entirely remote-working organization.

What’s the future of remote work at the organization? If the organization is mostly or entirely remote, are there any plans to change that? If the organization is mostly office-based, are there any plans to change that? If an office is likely to be founded in your city or region soon, will you be able or be expected to work from it?

You may be considering a job on the understanding that the remote work will be of very short duration (eg, an office is opening in your city in two months time). Is there any chance the time will be longer, and are you OK with that?

What is your manager’s approach to remote workers? How frequently will they speak with you and through what media? Will they expect you to travel to them? Will they sometimes travel to you? Have they managed remote workers before?

How long have there been remote workers for? Is the organization new to having remote workers or has it had remote workers for a long time and bedded down a remote working style?

What is the remote working culture like? Is most collaboration over email, text chat, phone, video conf, or some other means? Are there watercooler-equivalents like social IRC channels or video chats? How active are they? Are remote workers mainly working from home or from co-working spaces? Are there occasional team gatherings for remote workers to meet colleagues in person and are they optional or compulsory?

How flexible are the hours? Not all remote work has flexible hours; you may have mandated work hours, or core hours, or shifts, as in any other role.

Are the remote workers spread across multiple timezones? If so, are your team and closest collagues in your timezone or another one? Are you expected to adapt your working hours to overlap better with your colleagues? How are meetings and other commitments scheduled across timezones? Do they rotate through timezones or are they always held in a certain timezone? Are you ever expected to attend meetings well outside your working hours, and if so, how often is this expected and do your colleagues in other timezones face the same expectations?

What are the benefits for remote workers? Will the organization reimburse any of your remote working expenses, such as membership of a co-working space, home office furniture, or your home Internet connection costs? If you’re working in a different country from most of your colleagues, will you get equivalent benefits to your colleagues (eg, health insurance coverage)?

What are the travel expectations for remote workers? Are you expected to travel to headquarters or other offices or customers, and if so, how often and for how long? What are the travel policies and allowances for remote workers? How do these travel expectations compare to those of non-remote colleagues?

Sometimes you will be remote from an organization with an office or even headquarters in the same city as you. Will you be able or expected to visit the office? How often? Will there be resources for you (eg, hot desks, meal provisioning)?

What are the career progression possibilities for remote workers? As a remote worker in a partly non-remote organization, could you move into more senior positions over time, such as team leader, middle manager, or executive? Could you move into other teams in the organization, and if so, which ones? Are there some roles that are closed to remote workers? Match these answers to your own career goals.

What’s the training process like? Must you or can you spend a period of time in an office or visiting a colleague for training? Must you or can you do your training remotely using documentation, videos and similar? Will a trainer or colleague have some time assigned to remotely train you?

Is there support for first-time remote workers? If you haven’t worked remotely before, will the organization support you in learning how to work remotely, and if so, how?

See also

A very partial list of resources, focussing on individual remote workers and their experiences and strategies:

Creative Commons License
Learning more about a remote working position by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

No more rock stars: how to stop abuse in tech communities

This was co-written with Leigh Honeywell and Valerie Aurora, and was originally published on hypatia.ca. It’s also available en français sur repeindre.info.

Content note for discussion of abuse and sexual violence.

In the last couple of weeks, three respected members of the computer security and privacy tech communities have come forward under their own names to tell their harrowing stories of sexual misconduct, harassment, and abuse committed by Jacob Appelbaum. They acted in solidarity with the first anonymous reporters of Jacob’s abuse. Several organizations have taken steps to protect their members from Appelbaum, including the Tor Project, Debian, and the Noisebridge hackerspace, with other responses in progress.

But Appelbaum isn’t the last – or the only – abuser in any of these communities. Many people are calling for long-term solutions to stop and prevent similar abuse. The authors of this post have recommendations, based on our combined 40+ years of community management experience in the fields of computer security, hackerspaces, free and open source software, and non-profits. In four words, our recommendation is:

No more rock stars.

What do we mean when we say “rock stars?” We like this tweet by Molly Sauter:

Seriously, “rock stars” are arrogant narcissists. Plumbers keep us all from getting cholera. Build functional infrastructure. Be a plumber.

You can take concrete actions to stop rock stars from abusing and destroying your community. But first, here are a few signs that help you identify when you have a rock star instead of a plumber:

A rock star likes to be the center of attention. A rock star spends more time speaking at conferences than on their nominal work. A rock star appears in dozens of magazine profiles – and never, ever tells the journalist to talk to the people actually doing the practical everyday work. A rock star provokes a powerful organization over minor issues until they crack down on the rock star, giving them underdog status. A rock star never says, “I don’t deserve the credit for that, it was all the work of…” A rock star humble-brags about the starry-eyed groupies who want to fuck them. A rock star actually fucks their groupies, and brags about that too. A rock star throws temper tantrums until they get what they want. A rock star demands perfect loyalty from everyone around them, but will throw any “friend” under the bus for the slightest personal advantage. A rock star knows when to turn on the charm and vulnerability and share their deeply personal stories of trauma… and when it’s safe to threaten and intimidate. A rock star wrecks hotel rooms, social movements, and lives.

Why are rock stars so common and successful? There’s something deep inside the human psyche that loves rock stars and narcissists. We easily fall under their spell unless we carefully train ourselves to detect them. Narcissists are skilled at making good first impressions, at masking abusive behavior as merely eccentric or entertaining, at taking credit for others’ work, at fitting our (often inaccurate) stereotypes of leaders as self-centered, self-aggrandizing, and overly confident. We tend to confuse confidence with competence, and narcissists are skilled at acting confident.

Sometimes rock stars get confused with leaders, who are necessary and good. What’s the difference between a rock star and a leader? We like the term “servant-leader” as a reminder that the ultimate purpose of a good leader is to serve the mission of their organization (though this feminist critique of the language around servant-leadership is worth reading). Having personal name recognition and the trust and support of many people is part of being an effective leader. This is different from the kind of uncritical worship that a rock star seeks out and encourages. Leaders push back when the adoration gets too strong and disconnected from achieving the mission (here is a great example from Anil Dash, pushing back after being held up as an example of positive ally for women in tech). Rock stars aren’t happy unless they are surrounded by unthinking adoration.

How do we as a community prevent rock stars?

If rock stars are the problem, and humans are susceptible to rock stars, how do we prevent rock stars from taking over and hijacking our organizations and movements? It turns out that some fairly simple and basic community hygiene is poisonous to rock stars – and makes a more enjoyable, inclusive, and welcoming environment for plumbers.

Our recommendations can be summarized as: decentralizing points of failure, increasing transparency, improving accountability, supporting private and anonymous communication, reducing power differentials, and avoiding situations that make violating boundaries more likely. This is a long blog post, so here is a table of contents for the rest of this post:

Have explicit rules for conduct and enforce them for everyone

Create a strong, specific, enforceable code of conduct for your organization – and enforce it, swiftly and without regard for the status of the accused violator. Rock stars get a kick out of breaking the rules, but leaders know they are also role models, and scrupulously adhere to rules except when there’s no alternative way to achieve the right thing. Rock stars also know that when they publicly break the little rules and no one calls them out on it, they are sending a message that they can also break the big rules and get away with it.

One of the authors of this post believed every first-person allegation of abuse and assault by Jacob Appelbaum – including the anonymous ones – immediately. Why? Among many other signs, she saw him break different, smaller rules in a way that showed his complete and total disregard for other people’s time, work, and feelings – and everyone supported him doing so. For example, she once attended a series of five minute lightning talks at the Noisebridge hackerspace, where speakers sign up in advance. Jacob arrived unannounced and jumped in after the first couple of talks with a forty-five minute long boring rambling slideshow about a recent trip he took. The person running the talks – someone with considerable power and influence in the same community – rolled his eyes but let Jacob talk for nine times the length of other speakers. The message was clear: rules don’t apply to Jacob, and even powerful people were afraid to cross him.

This kind of blatant disregard for the rules and the value of people’s time was so common that people had a name for it: “story time with Jake,” as described in Phoenix’s pseudonymous allegation of sexual harassment. Besides the direct harm, dysfunction, and disrespect this kind of rule-breaking and rudeness causes, when you allow people to get away with it, you’re sending a message that they can get away with outright harassment and assault too.

To solve this, create and adopt a specific, enforceable code of conduct for your community. Select a small expert group of people to enforce it, with provisions for what to do if one of this group is accused of harassment. Set deadlines for responding to complaints. Conduct the majority of discussion about the report in private to avoid re-traumatizing victims. Don’t make exceptions for people who are “too valuable.” If people make the argument that some people are too valuable to censure for violating the code of conduct, remove them from decision-making positions. If you ever find yourself in a situation where you are asking yourself if someone’s benefits outweigh their liabilities, recognize that they’ve already cost the community more than they can ever give to it and get to work on ejecting them quickly.

Start with the assumption that harassment reports are true and investigate them thoroughly

Over more than a decade of studying reports of harassment and assault in tech communities, we’ve noticed a trend: if things have gotten to the point where you’ve heard about an incident, it’s almost always just the tip of the iceberg. People argue a lot about whether to take one person’s word (the alleged victim) over another’s (the alleged harasser), but surprisingly often, this was not the first time the harasser did something harmful and it’s more likely a “one person said, a dozen other people said” situation. Think about it: what are the chances that someone had a perfect record of behavior, right up till the instant they stuck their hand in someone else’s underwear without consent – and that person actually complained about it – AND you heard about it? It’s far more likely that this person has been gradually ramping up their bad behavior for years and you just haven’t heard about it till now.

The vast majority of cases we know about fit one of these two patterns:

  1. A clueless person makes a few innocent, low-level mistakes and actually gets called on one of them fairly quickly. Signs that this is the likely case: the actual incident is extremely easy to explain as a mistake, the accused quickly understands what they did wrong, they appear genuinely, intensely embarrassed, they apologize profusely, and they offer a bunch of ways to make up for their mistake: asking the video of their talk to be taken down, writing a public apology explaining why what they did was harmful, or proposing that they stop attending the event for some period of time.
  2. A person who enjoys trampling on the boundaries of others has been behaving badly for a long time in a variety of ways, but everyone has been too afraid to say anything about it or do anything about other reports. Signs that this is the likely case: the reporter is afraid of retaliation and may try to stay anonymous, other people are afraid to talk about the incident for the same reason, the reported incident may be fairly extreme (e.g., physical assault with no question that consent was violated), many people are not surprised when they hear about it, you quickly gather other reports of harassment or assault of varying levels, the accused has plagiarized or stolen credit or falsified expense reports or done other ethically questionable things, the accused has consolidated a lot of power and attacks anyone who seems to be a challenge to their power, the accused tries to change the subject to their own grievances or suffering, the accused admits they did it but minimizes the incident, or the accused personally attacks the reporter using respectability politics or tone-policing.

In either case, your job is to investigate the long-term behavior of the accused, looking for signs of narcissism and cruelty, big and small. Rock stars leave behind a long trail of nasty emails, stolen credit, rude behavior, and unethical acts big and small. Go look for them.

Make it easy for victims to find and coordinate with each other

Rock stars will often make it difficult for people to talk or communicate without being surveilled or tracked by the rock star or their assistants, because private or anonymous communication allows people to compare their experiences and build effective resistance movements. To fight this, encourage and support private affinity groups for marginalized groups (especially people who identify as women in a way that is significant to them), create formal systems that allow for anonymous or pseudonymous reporting such as an ombudsperson or third-party ethics hotline, support and promote people who are trusted contact points and/or advocates for marginalized groups, and reward people for raising difficult but necessary problems.

Watch for smaller signs of boundary pushing and react strongly

Sometimes rock stars don’t outright break the rules, they just push on boundaries repeatedly, trying to figure out exactly how far they can go and get away with it, or make it so exhausting to have boundaries that people stop defending them. For example, they might take a little too much credit for shared work or other people’s work, constantly bring up the most disturbing but socially acceptable topic of conversation, resist de-escalation of verbal conflict, subtly criticize people, make passive-aggressive comments on the mailing list, leave comments that are almost but not quite against the rules, stand just a little too close to people on purpose, lightly touch people and ignore non-verbal cues to stop (but obey explicit verbal requests… usually), make comments which subtly establish themselves as superior or judges of others, interrupt in meetings, make small verbal put-downs, or physically turn away from people while they are speaking. Rock stars feel entitled to other people’s time, work, and bodies – signs of entitlement to one of these are often signs of entitlement to the others.

Call people out for monopolizing attention and credit

Is there someone in your organization who jumps on every chance to talk to a reporter? Do they attend every conference they can and speak at many of them? Do they brag about their frequent flyer miles or other forms of status? Do they jump on every project that seems likely to be high visibility? Do they “cookie-lick” – claim ownership of projects but fail to do them and prevent others from doing them either? If you see this happening, speak up: say, “Hey, we need to spread out the public recognition for this work among more people. Let’s send Leslie to that conference instead.” Insist that this person credit other folks (by name or anonymously, as possible) prominently and up front in every blog post or magazine article or talk. Establish a rotation for speaking to reporters as a named source. Take away projects from people if they aren’t doing them, no matter how sad or upset it makes them. Insist on distributing high status projects more evenly.

A negative organizational pattern that superficially resembles this kind of call-out can sometimes happen, where people who are jealous of others’ accomplishments and successes may attack effective, non-rock star leaders. Signs of this situation: people who do good, concrete, specific work are being called out for accepting appropriate levels of public recognition and credit by people who themselves don’t follow through on promises, fail at tasks through haplessness or inattention, or communicate ineffectively. Complaints about effective leaders may take the form of “I deserve this award for reasons even though I’ve done relatively little work” instead of “For the good of the organization, we should encourage spreading out the credit among the people who are doing the work – let’s talk about who they are.” People complaining may occasionally make minor verbal slips that reveal their own sense of entitlement to rewards and praise based on potential rather than accomplishments – e.g., referring to “my project” instead of “our project.”

Insist on building a “deep bench” of talent at every level of your organization

Your organization should never have a single irreplaceable person – it should have a deep bench. Sometimes this happens through a misplaced sense of excessive responsibility on the part of a non-abusive leader, but often it happens through deliberate effort from a “rock star.” To prevent this, constantly develop and build up a significant number of leaders at every level of your organization, especially near the top. You can do this by looking for new, less established speakers (keynote speakers in particular) at your events, paying for leadership training, creating official deputies for key positions, encouraging leaders to take ample vacation and not check email (or chat) while they are gone, having at least two people talk to each journalist, conducting yearly succession planning meetings, choosing board members who have strong opinions about this topic and a track record of acting on them, having some level of change or turnover every few years in key leadership positions, documenting and automating key tasks as much as possible, sharing knowledge as much as possible, and creating support structures that allow people from marginalized groups to take on public roles knowing they will have support if they are harassed. And if you need one more reason to encourage vacation, it is often an effective way to uncover financial fraud (one reason why abusive leaders often resist taking vacation – they can’t keep an eye on potential exposure of their misdeeds).

Flatten the organizational hierarchy as much as possible

Total absence of hierarchy is neither possible nor desirable, since “abolishing” a hierarchy simply drives the hierarchy underground and makes it impossible to critique (but see also the anarchist critique of this concept). Keeping the hierarchy explicit and making it as flat and transparent as possible while still reflecting true power relationships is both achievable and desirable. Ways to implement this: have as small a difference as possible in “perks” between levels (e.g., base decisions on flying business class vs. economy on amount of travel and employee needs, rather than position in the organization), give people ways to blow the whistle on people who have power over them (including channels to do this anonymously if necessary), and have transparent criteria for responsibilities and compensation (if applicable) that go with particular positions.

Build in checks for “failing up”

Sometimes, someone gets into a position of power not because they are actually good at their job, but because they turned in a mediocre performance in a field where people tend to choose people with proven mediocre talent over people who haven’t had a chance to demonstrate their talent (or lack thereof). This is called “failing up” and can turn otherwise reasonable people into rock stars as they desperately try to conceal their lack of expertise by attacking any competition and hogging attention. Or sometimes no one wants to take the hit for firing someone who isn’t capable of doing a good job, and they end up getting promoted through sheer tenacity and persistence. The solution is to have concrete criteria for performance, and a process for fairly evaluating a person’s performance and getting them to leave that position if they aren’t doing a good job.

Enforce strict policies around sexual or romantic relationships within power structures

Rock stars love “dating” people they have power over because it makes it easier to abuse or assault them and get away with it. Whenever we hear about an organization that has lots of people dating people in their reporting chain, it raises an automatic red flag for increased likelihood of abuse in that organization. Overall, the approach that has the fewest downsides is to establish a policy that no one can date within their reporting chain or across major differences in power, that romantic relationships need to be disclosed, and that if anyone forms a relationship with someone in the same reporting chain, the participants need to move around the organization until they no longer share a reporting chain. Yes, this means that if the CEO or Executive Director of an organization starts a relationship with anyone else in the organization, at least one of them needs to leave the organization, or take on some form of detached duty for the duration of the CEO/ED’s tenure. When it comes to informal power relationships, such as students dating prominent professors in their fields, they also need to be forbidden or strongly discouraged. These kinds of policies are extremely unattractive to a rock star, because part of the attraction of power for them is wielding it over romantic or sexual prospects.

Avoid organizations becoming too central to people’s lives

Having a reasonable work-life balance isn’t just an ethical imperative for any organization that values social justice, it’s also a safety mechanism so that if someone is forced to leave, needs to leave, or needs to take a step back, they can do so without destroying their entire support system. Rock stars will often insist on subordinates giving 100% of their available energy and time to the “cause” because it isolates them from other support networks and makes them more dependent on the rock star.

Don’t set up your community so that if someone has a breach with your community (e.g., is targeted for sustained harassment that drives them out), they are likely to also lose more than one of: their job, their career, their romantic relationships, their circle of friends, or their political allies. Encouraging and enabling people to have social interaction and support outside your organization or cause will also make it easier to, when necessary, exclude people behaving abusively or not contributing because you won’t need to worry that you’re cutting them off from all meaningful work or human contact.

You should discourage things like: semi-compulsory after hours socialising with colleagues, long work hours, lots of travel, people spending almost all their “intimacy points” or emotional labour on fellow community members, lots of in-group romantic relationships, everyone employs each other, or everyone is on everyone else’s boards. Duplication of effort (e.g., multiple activist orgs in the same area, multiple mailing lists, or whatever) is often seen as a waste, but it can be a powerfully positive force for allowing people some choice of colleagues.

Distribute the “keys to the kingdom”

Signs of a rock star (or occasionally a covert narcissist) may include insisting on being the single point of failure for one or more of: your technical infrastructure (e.g., domain name registration or website), your communication channels, your relationship with your meeting host or landlord, your primary source of funding, your relationship with the cops, etc. This increases the rock star’s power and control over the organization.

To prevent this, identify core resources, make sure two or more people can access/administer all of them, and make sure you have a plan for friendly but sudden, unexplained, or hostile departures of those people. Where possible, spend money (or another resource that your group can collectively offer) rather than relying on a single person’s largesse, specialized skills, or complex network of favours owed. Do things legally where reasonably possible. Try to be independent of any one critical external source of funding or resources. If there’s a particularly strong relationship between one group member and an external funder, advisor, or key organization, institutionalize it: document it, and introduce others into the relationship.

One exception is that it’s normal for contact with the press to be filtered or approved by a single point of contact within the organization (who should have a deputy). However, it should be possible to talk to the press as an individual (i.e., not representing your organization) and anonymously in cases of internal organizational abuse. At the same time, your organization should have a strong whistleblower protection policy – and board members with a strong public commitment and/or a track record of supporting whistleblowers in their own organizations.

Don’t create environments that make boundary violations more likely

Some situations are attractive to rock stars looking to abuse people: sexualized situations, normalization of drinking or taking drugs to the point of being unable to consent or enforce boundaries, or other methods of breaking down or violating physical or emotional boundaries. This can look like: acceptance of sexual jokes at work, frequent sexual liaisons between organization members, mocking people for not being “cool” for objecting to talking about sex at work, framing objection to sexualized situations as being homophobic/anti-polyamorous/anti-kink, open bars with hard alcohol or no limit on drinks, making it acceptable to pressure people to drink more alcohol than they want or violate other personal boundaries (food restrictions, etc.), normalizing taking drugs in ways that make it difficult to stay conscious or defend boundaries, requiring attendance at physically isolated or remote events, having events where it is difficult to communicate with the outside world (no phone service or Internet access), having events where people wear significantly less or no clothing (e.g. pool parties, saunas, hot tubs), or activities that require physical touching (massage, trust falls, ropes courses). It’s a bad sign if anyone objecting to these kinds of activities is criticized for being too uptight, puritanical, from a particular cultural background, etc.

Your organization should completely steer away from group activities which pressure people, implicitly or explicitly, to drink alcohol, take drugs, take off more clothing than is usual for professional settings in the relevant cultures, or touch or be touched. Drunkenness to the point of marked clumsiness, slurred speech, or blacking out should be absolutely unacceptable at the level of organizational culture. Anyone who seems to be unable to care for themselves as the result of alcohol or drug use should be immediately cared for by pre-selected people whose are explicitly charged with preventing this person from being assaulted (especially since they may have been deliberately drugged by someone planning to assault them). For tips on serving alcohol in a way that greatly reduces the chance of assault or abuse, see Kara Sowles’ excellent article on inclusive events. You can also check out the article on inclusive offsites on the Geek Feminism Wiki.

Putting this to work in your community

We waited too long to do something about it.

Odds are, your community already has a “missing stair” or three – even if you’ve just kicked one out. They are harming and damaging your community right now. If you have power or influence or privilege, it’s your ethical responsibility to take personal action to limit the harm that they are causing. This may mean firing or demoting them; it may mean sanctioning or “managing them out.” But if you care about making the world a better place, you must act.

If you don’t have power or influence or privilege, think carefully before taking any action that could harm you more and seriously consider asking other folks with more protection to take action instead. Their response is a powerful litmus test of their values. If no one is willing to take this on for you, your only option may be leaving and finding a different organization or community to join. We have been in this position – of being powerless against rock stars – and it is heartbreaking and devastating to give up on a cause, community, or organization that you care about. We have all mourned the spaces that we have left when they have become unlivable because of abuse. But leaving is still often the right choice when those with power choose not to use it to keep others safe from abuse.

Responses

While we are not asking people to “cosign” this post, we want this to be part of a larger conversation on building abuse-resistant organizations and communities. We invite others to reflect on what we have written here, and to write their own reflections. If you would like us to list your reflection in this post, please leave a comment or email us a link, your name or pseudonym, and any affiliation you wish for us to include, and we will consider listing it. We particularly invite survivors of intimate partner violence in activist communities, survivors of workplace harassment and violence, and people facing intersectional oppressions to participate in the conversation.

2016-06-21: The “new girl” effect by Lex Gill, technology law researcher & activist

2016-06-21: Patching exploitable communities by Tom Lowenthal, security technologist and privacy activist

2016-06-22: Tyranny of Structurelessness? by Gabriella Coleman, anthropologist who has studied hacker communities

We would prefer that people not contact us to disclose their own stories of mistreatment. But know this: we believe you. If you need emotional support, please reach out to people close to you, a counselor in your area, or to the trained folks at RAINN or Crisis Text Line.

Credits

This post was written by Valerie Aurora (@vaurorapub), Mary Gardiner (@me_gardiner), and Leigh Honeywell (@hypatiadotca), with grateful thanks for comments and suggestions from many anonymous reviewers.

Tech interviews, too much homework, and the motherhood question

There’s a fascinating discussion around technical interviews recently; would both candidate experience and hiring signal be improved by revising the current round of (basically Google-inspired) non-runnable algorithm-centric coding examples completed under time pressure?

I’ve been following Thomas Ptacek’s tweets about it for a few months, for example:

Then last week Julia Grace wrote A Walkthrough Guide to Finding an Engineering Job at Slack:

We’ve put a great deal of effort into designing our interview process so that it is comprehensive and consistent, and are working hard to remove as many points of bias as possible. To date we’ve found it successfully identifies people who will succeed here — those with a high degree of technical competence who also embody Slack’s values: empathy, courtesy, craftsmanship, solidarity, playfulness, and thriving[…]

We’d like to get an idea of how you write code in the real world, since we feel this is the best indicator of how you’d write code day to day here at Slack. Granted, the Slack codebase is larger and more complicated than any technical exercise, but we have found the technical exercise to be a good indicator of future performance on the job. There are great engineers at big name companies and at small ones, so this gives everyone a chance to shine independent of where they are now.

This varies by position, but generally you’ll have a week to complete a technical exercise and submit the code and working solution back to us.

Uncritical praise of take home exams started to ring alarm bells for me. I recall take home exams from university; one of my majors was philosophy, which tended to assign a long essay (eg, 4000 words) to be completed over 6 weeks or so, and a take-home exam (eg, 2 essays of 1000–2000 words) to be completed with a four day deadline. I moved out of a rural town to go to university and lived on my own. From age 19, I also financially supported myself. I loathed take home exams, because I was competing with people who would get the exam, go home, and work on it all week in the house they lived in with their parents. No job. No housework. (Admittedly, no self-imposed decision to take 125% of a normal course load every year for four years of university either, that one was on me.)

And that was before I had two children. I’m not at all excited about tech interviews moving to a model where I’m doing a huge amount of work in my own time, because I do not have a huge amount of free time. Anecdotally, I have already heard of people spending in excess of 20 hours on Slack’s coding exercise. Freeing 20 hours in a week is a non-starter for me, especially if I’m not a clear finalist for the job. Slack is administering these take home assignments prior to on-site interviews, and is a very sought after workplace; it’s quite possible their process will be widely copied and people will regularly be doing a couple of days of coding before in-person interviews, for many many jobs.

To be fair, I have also read through Steve Yegge’s Get that job at Google and estimate that, at my current levels of free time, it would probably take me a couple of years to complete the preparation he recommends. (I have an undergraduate degree in computer science and mathematics — the philosophy major was a separate degree — and a PhD in computing, but at this distance I am far from passing an exam in discrete maths.) But I also wouldn’t be required to submit work samples proving I’d spent that time.

I am also aware that other positions require extensive preparatory work for job interviews for senior candidates, such as preparing sample budgets or strategy presentations or similar, but it’s at least more common only to give such large amounts of work to later-stage candidates for the position.

Let’s not get uncritically excited about adding (yet another!) screen for “isn’t a mother of young children”. I am thrilled that Camille Fournier has made several similar points in Thoughts on Take Home Interviews (also available on her blog):

On twitter, a discussion ensued about whether asking people to spend time at home doing exercises didn’t itself cause bias, against those who did not have a lot of spare time to be doing take-home exercises. Julia mentioned that they expect it to take 2–4 hours, but admitted that some people got really into the project and spent far longer than that[…]

The creative take-home also seems likely to select for those with free time, because if it is really an exercise that some people want to overdo, they will overdo it and you will have a hard time not rewarding that enthusiasm (why shouldn’t you!). And while it’s ok to ask for a few hours, building something that rewards those who can spend far longer is likely to bias against those who have, say, kids to take care of after work and on weekends, or other activities that limit their free time.

Gaëtan Voyer-Perraul also notes in a reply:

If this thing catches on, then it’s going to become a gating mechanism for every developer job in existence. New grads will be faced with hundreds of hours of “take-home” work that goes into the same black hole as their resumés.

Also worth a read: Rod Begbie gives a postmortem of a take-home interview question he used to administer.

I’m excited about revising the technical interviewing process, which will require both experimentation and evidence. While experimenting, and as the tech industry actively seeks candidates from under-represented backgrounds, the ability of candidates to interview with your organisation without tens of hours of free time for take-homes in addition to time for on-site interviews should be a core design principle for your interview process.

Remembering Telsa Gwynne

Telsa Gwynne, whom I knew through my time in the LinuxChix community between 2000 and around 2007, died this week:

Telsa is the direct inspiration for the entire 15 years of content on this website, especially the personal diary. Before joining LinuxChix, I first knew Telsa through her online diary (its archival title, “This was a diary, once”, is painful to read now), which I heard about through someone who read Alan Cox’s diary, and I was struck by how striking daily life could be in written form. Telsa’s diary was full of personality and snark, and singlehandedly inspired me to begin writing about my life online too.

I thought of her as a net celebrity, although not in the usual way of “married to Alan Cox”, but as “writer of one of my favourite websites”. I was therefore a little bit shy about directly interacting with her when I initially joined the LinuxChix lists in 2000, but I first met her in person in 2001 at linux.conf.au when she and Malcolm Tredinnick were hanging around debriefing and complaining about CVS, on which he was teaching a tutorial that year which Telsa later wrote up. She was grumpy and kind and normal, even if she did know CVS.

Andrew saw her again at LCA in 2003, but I didn’t go and I think I only met her one more time, in Wales in 2004 when we visited their house and due to poor planning with trains, ended up staying the night. Telsa and Alan were kind hosts and we enjoyed Telsa’s huge knowledge of local history as we walked all around Swansea.

Telsa’s final diary entry in 2006 says she “plain[ly] and simpl[y] los[t] interest in running to stand still just to understand how to use anything mechanical.” However hard she worked for it, I remember her as profoundly technically knowledgeable and an excellent teacher. A great deal of my initial learning about both CSS and character encodings came from her, and she was well known as a high level user of DocBook. A friend shared one of her posts to a private LinuxChix technical list today, walking through the differences between library packages and -devel packages in Linux distributions, and their implications for compiling software.

I hadn’t been in contact with Telsa since she or I variously withdrew from our common online communities, so since 2007 or before. I kept an eye on the very occasional updates to her website, and was pleased to think that she had found a more satisfying life outside her Free Software community volunteering. I still find this a happy thought.

Telsa was also a critical inspiration to me as an activist: in the early 2000s (and still) it was hugely controversial to either believe that open source communities could still work if they were more civil (the entire LinuxChix project was partly an experiment with that), and even more so to insist that they should be. Telsa is the earliest person I can think of who stood up in an open source development community and asked it to change its norms in the direction of civility. I don’t know how heavily her online harassment experiences played a part in her departing Free Software and some online communities — I hope it wasn’t a large part — but I’m sorry it happened and I’m angry.

Telsa was a brilliant and kind and strong person, and I am sorrier than I can say that we will never be in contact again. To Alan, Debbie and others who loved her: my profound sympathies for the loss of an amazing person.

Other memorials:

Telsa online:

Creative Commons License
Remembering Telsa Gwynne by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Quick hit: Google publishes their EEO-1 diversity data

This article originally appeared on Geek Feminism.

As promised earlier this month, Google’s diversity data is now up on their blog.

They write:

We’ve always been reluctant to publish numbers about the diversity of our workforce at Google. We now realize we were wrong, and that it’s time to be candid about the issues. Put simply, Google is not where we want to be when it comes to diversity, and it’s hard to address these kinds of challenges if you’re not prepared to discuss them openly, and with the facts.

Their numbers — globally — are 70% male, 30% female (this seems to add up to 100%, which suggests that either Google or the EEO-1 process need to review their gender categories), dropping to 17% female among their technical employees. We’ve tabulated some data at the Geek Feminism wiki. You can compare with female-male breakdowns from some other companies (many quite small) at We Can Do Better.

Google’s US workforce is also 2% Black, way below US national figures of 13% nationwide and 3% Hispanic against 17% nationwide. (Nationwide figures from US Census numbers dated from 2012 and rounded to the nearest whole number to have the same precision as the Google figures.)

What do you think? Is disclosure a meaningful action here? Are you surprised by Google’s figures? Do you think the rest of the tech industry will or should follow?

Remembering Malcolm Tredinnick

I flew home from the US yesterday and when I arrived in Sydney I got a message from my husband saying that Malcolm Tredinnick had died. According to this piece by Simon Dulhunty, he was found on Monday to died at home in Sydney, possibly after a seizure, while I was at PyCon 2013.

Malcolm Tredinnick speaking to an audience
Malcolm Tredinnick speaking at DjangoCon 2008 (by Sebastian Hilling CC BY-NC)

I’ve known Malcolm slightly since my first linux.conf.au in Sydney 2001. In late 2004 I interviewed for a job at CommSecure (since closed) where he was then working, having been a lead developer of and continuing to maintain and develop a real-time data delivery system for the Hong Kong stock exchange. (The eventual end of that contract was the reason CommSecure later closed.) He was also my boss for about half of 2005 until I left to begin my PhD in early 2006.

I still caught up with him at technical events, the last long conversation I remember with him was at PyCon AU 2011 where my husband Andrew and I had a very Malcolm conversation with Malcolm, which roved over the paperwork hassles of having no fixed address (Malcolm travelled a lot and went through periods where he housesat or lived in serviced apartments for a while), the Australasian chess community, and some gentle mutual trolling between him and Andrew over narrative testing.

What I will remember most about Malcolm is that he was a teacher at heart. I never personally had this relationship with him, but I knew several people at CommSecure and elsewhere who Malcolm had tutored or mentored in programming, often over a very long period of time. Elsewhere I know he had taught mathematics (long before I knew him, he very nearly completed a PhD in mathematics when his area suddenly became fashionable and about 50 years of work was done in 6 months by incoming mathematicians) and chess. I will also remember his dry and sadonic approach to nearly everything (for a very recent example, Malcolm gives useful parenting advice), combined with “really, how hard could it be?” used both straightforwardly and distinctly otherwise. Goodbye Malcolm.

Update, funeral plans: Ray Loyzaga who was Malcolm’s close friend, and long-time founder-CEO of CommSecure, has announced that Malcolm’s funeral will be at 2:30pm Thursday April 4, at Camellia Chapel, Macquarie Park Cemetary, North Ryde, Sydney.

Other memorials:

Malcolm online:

Creative Commons License
Remembering Malcolm Tredinnick by Mary Gardiner is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Fun at LCA 2013: my picks for Thursday and Friday

Thursday

I rarely go to LCA’s tutorials, but really, after years of not having to worry too much about distributed version control systems due to having in-house technical support from my husband, a (now former) Bazaar developer, it’s probably time that I came to grips with git. Hence Git For Ages 4 And Up (Michael Schwern) is tempting, hopefully it’s OK for those of us who do use terms like “directed acyclic graph”. This does mean missing Wiggle while you work (Neil Brown) though: apparently you can’t be a git beginner whilst being interested in newfangled patching algorithms.

After lunch The IPocalypse – 20 months later (Geoff Huston) calls to me: it’s the sequel to his LCA 2011 keynote, which is the one that stood out to me. (Well, and Mark Pesce’s, yes, but funnily enough his actual content largely passed me by.) All that doom and gloom, and now what? Has IPv6 cost us our Internet?

A Tridge talk (Building a free software telemetry radio system) is an even more obvious pick than a Matthew Wilcox talk. (Although why did we put that particular talk up against Buffer Bloat? Tridge is going to talk about TCP performance issues.)

In the afternoon Keith Packard has a new passion (Teaching Robotics and Embedded Computing with Legos and Arduino) and then Ristretto: run-time types for JavaScript (Shane Stephens) sounds alarming. In a good way.

Friday

It might also be a two-tute LCA, with Beyond Alt Text: What Every Project Should Know About Accessibility (Denise Paolucci) up first. BUT NovaProva, or How I Did Six Impossible Things Before LCA (Gregory Banks) is the good crack (“NovaProva implements true reflection in C/C++”???), so… difficult!

After lunch, Asheesh Laroia’s Quantitative community management is closer to what I do but I am also curious about The real story behind Wayland and X (Daniel Stone). In the final session, probably Building Persona: federated and privacy-sensitive identity for the Web depending on how my conference energy is going.

And then where?

I’m headed back to the USA in March for PyCon, and I’m looking forward to having way (waaaaaay) less commitments than I did at Wikimania 2012, and therefore being able to catch more of the talks. And not dragging myself to my hotel room at 4pm to order crème brûlée room service because I am too tired to figure out how to work the lifts. (It was good crème brûlée though!) The Ada Initiative will probably be running some non-talk activities though, so it won’t be wall-to-wall talks. And then a second return to the USA for AdaCamp SF. And that really might be enough for one year, but if not, there’s always Kiwicon.