The soul of our politics is the commitment to ending domination. — bell hooks
Next week I’m going to give a talk on how men can support women in the tech industry. I was uncomfortable with the idea when first approached: My thoughts turned to images of me clicking through a deck and reading off bullets of things you shouldn’t do that I probably did myself at some point before someone undertook the effort required to get me to stop. I hated the idea of standing in front of a room and implying there’s something I get that maybe the men I’d be speaking to don’t.
After a brief back and forth with one of the organizers, though, I proposed building a talk around a project I undertook a few years back to author guides for a company open door policy. She was supportive of the idea, and that made me more comfortable: Even though I had designed and led the project, it was never “mine:” It happened at all because our CEO had been listening to women who were telling him what they needed to feel more safe and heard at work, and I was just there to help make it happen.
I suppose this entry is to help me firm up some of my thoughts before I present, but it’s also to provide a link to a repo that has the output of that project that’s consumable by anybody who’s interested in having a supplement to whatever fossil of an open door policy their company has tossed up on the intranet. I wanted to be able to share the work with the folks at my talk, so I scrubbed the guides down and dropped them on GitHub (along with a small todo list of things that could make them better in the project issues). I’ll link to it a bit later, too, but here it is right now in case you’re curious and don’t care about anything else I’ve got to say on the matter:
The initial brief for these things was to create a guide that made it easier to understand how to use our open door policy at all. I was asked to work with HR to deliver something that we could position within the open door policy itself, perhaps as a diagram or flowchart. I met with our VP of HR and one of our HR business partners, and we tried to whiteboard a basic “open door process flow.”
As an aside, that initial diagramming session was one of the best things that’s ever happened to me. Up until then I had a pretty dim view of HR. I’d worked in places where the HR org wasn’t just “there to serve the company’s interests,” but had become a sort of political center in its own right, controlling the path to promotion by gate-keeping mandatory training or obscuring promotion standards and practices. I’d never spent a lot of time thinking about the nuances of the HR discipline.
By the time I was done working with that VP and business partner, I had a new appreciation for the complexities HR people deal with (and a huge amount of admiration for those two in particular, because they had an architect’s perspective on some of the problems we were discussing but were as engaged with making the architecture amenable to people as I was).
I’d also decided the idea of just making a diagram or flow chart was a terrible idea: It was too rife with edge cases, and no amount of detail at the “step 1, step 2, step 3” level suggested an awareness of how it actually feels to have a problem you can’t fix for yourself that you have to go get help with. I took that idea away, digested it, talked to a few women around the company, and sent a note to the CEO:
… the issue is less “what are the steps?” and more “how do we get everybody to an equal place in terms of their confidence that when they use the steps they’ll get a good outcome?” Your public statements about non-retaliation a few months back are important, but there are things beyond retaliation that matter, too, and these came out in interviews:
That’s 20 percent “process” and 80 percent human factors.
- Will my manager place the burden on me to fix the problem once they hear me out?
- Is my manager attuned to the idea of discriminatory behavior that flies below the radar of outright bigotry? (microaggressions, which are not universally understood to be “real”)
- Is my manager attuned to the idea that bringing my concerns to them sometimes feels like I might be marking myself as a troublemaker/”difficult,” if not to them then others. (confidentiality as a cardinal component of the process)
- How will I know what’s going on with my issue once I bring it to someone?
- How can I know I’m not going to inadvertently bring a hammer down on someone?
The next few months involved some document design, some writing, and a lot of listening. One of the people who worked for me had the misfortune of experiencing one of my people management failures, and I was incredibly lucky that we’d reestablished enough trust that she thought it was worth her time to explain to me how I’d fucked up.
Another woman told me a deeply personal story about what it was like to be condescended and talked down to by a male colleague. We spent an hour talking about her experiences, and even then I was catching myself drifting toward thoughts about the ways in which her patronizing male colleague probably didn’t mean any harm, or surely hadn’t acted that poorly. We ended the meeting and went back to our desks. A few minutes later, I saw her at a nearby whiteboard with that colleague, so I stayed at my desk and listened to the interaction from afar, and it worse than she described, which caused me to realize that even in a relatively safe context she was still protecting someone who had treated her terribly. I’m glad I was able to engage in some empirical verification; I’m sorry I felt the need to.
As the work progressed, I invited more and more people into the documents to help shape them. At one point I had three copies of each document so stronger voices wouldn’t drown out quieter ones in the comments. When it was clear that the very idea of “microaggressions” was controversial, I asked women to help me list some examples: The documents don’t have that word in them (even if they probably should), but they articulate the idea and provide examples from womens’ experience.
After a few months of work, either writing, listening, or reconciling the viewpoints we’d brought into the project, the VP of HR signed off and we shipped them to the CEO. He said he liked them, and he named four women he wanted me to meet with to get final approval. I was a little chagrined because I’d already talked to each person on his list as part of the work, but I invited them all to meet and discuss the finished docs, anyhow. They turned up a few more small things and we fixed them on the spot, which taught me it never hurts to listen for just a bit longer.
We ended up with two guides, meant to be used as a supplement to a generic open door policy of the sort you can just go download from the web:
The first guide is for employees. It’s written to strongly suggest our values around the process of escalation. The language is about “expectations,” and you could think of it as a bill of rights that compels certain behaviors from managers. The language is meant to be supportive and affirming. It’s made clear that if those expectations aren’t met, the interaction is in trouble and the employee can bail on it, escalating to the next level.
The second guide is for managers. Structurally, it closely parallels the employee guide. The language is less on the “supportive and affirming” end of the spectrum than it is quite imperative.
The employee guide references the manager guide a few times, not to avoid repetition and certainly not as a requirement to understand the employee guide, but to accentuate things we’re telling employees: “We told you to expect this behavior, and here is where we’re telling managers, in imperative language, to do exactly what we told you to expect. If you observe your manager not doing these things, you can see right there in the manual we wrote just for them that they’re supposed to be doing those things.”
Since releasing them just over two years ago, HR has made them part of the management training program, and our HR business partners make sure new employees hear about them when onboarding. When I’m involved in a conversation with an employee about something sensitive, I will often share the link after telling them about their rights to confidentiality, and I’ll make clear to them that the bedrock values of those docs include consent and confidentiality.
I don’t have any way of measuring their success. Personally, I find them comforting: Even though I helped write them, I still find myself going to them to remind myself of my obligations to the people who work for me, and people have told me that they’ve been glad to read them.
And they’re also a valuable reminder to me of a few things:
First, the piece of work I’m most proud of during my time at Puppet wasn’t really my work at all: It was the result of deciding I didn’t know everything I needed to know, that I didn’t have all the answers, and that my reputation as someone who understood womens’ concerns and was a good manager in that regard wasn’t something that I had—something that was part of my nature—but rather was the result of knowing to listen, and accepting the idea that “I know that I know nothing.”
Second, that the thing I’m most proud of as a manager came not from “taking charge” and leading, but from deciding the best use of my authority was to assert my right to be guided by others who hadn’t been given that authority.
Anyhow, if you see some values in these guides, they’re on GitHub. The README has a few suggestions on how to use them that preclude simply downloading them and tossing them up. Instead, I’d suggest you fork them and make them your own, preferably after talking to people in your organization and learning what would make such a guide more useful to them.