I was once asked to give a talk on how men can support women in the tech industry. At first I was uncomfortable with the idea: 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 at the 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 publish 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 Luke Kanies, 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 learned a lot as the project evolved, and it felt better to me to talk about how I learned.
The initial brief for those guides was to make it easier to understand how to use our open door policy at all. I was asked to work with HR to deliver something 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 gatekeeping 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 Luke:
… 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:
- 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?
That’s 20 percent “process” and 80 percent human factors.
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 messed 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 was 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 see the dynamic playing out; 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 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.”
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 to remember that listening isn’t about asking whether someone is right, but how they’re right.
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.
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.