Specific ideas they’ve brought to their organization in the past few months include:

• Decision-making frameworks (like DACI).
• Continuous improvement (but not open-ended faux experiments).
• Intentional change management (which is the subject of a longer post I’m just now getting outlined).
• Being curious about the ways in which a seemingly benign process doesn’t work for the intended beneficiaries.

People don’t always associate those things – decision-making frameworks, change management – as enablers. Instead, they see a mountain of forms, process docs, and specialists asking them to start from the beginning so “the process” can have a chance to work.

I’m not here to write a defense of process, because too many people have a lived experience of process that is indefensible. The kind of people I have spent most of my career working with or managing don’t need to read a defense, anyhow: operations teams, IT groups, and services teams all understand the value.

Instead, I’m here to talk about some practices cross-functional leaders can apply to their work and behavior to foster inclusion and help everybody do their best work. This applies to be people whose roles are inherently cross-functional – they lead a centralized service of some kind – and people who are stepping up to lead from within their day-to-day work in a functional group.

As that conversation I am having about governance, change management and inclusion has unfolded I have heard a lot about an organizational history full of weaponized, disempowering process. Conversations around new initiatives were full of distrust, nobody wanted to bring in supporting specialists from finance or HR, and every meeting was stacked with senior leaders who didn’t participate or contribute but weren’t willing to turn their back on the situation.

As we talked things through, I identified some key mindset and practices that have helped me as I’ve led cross-functional initiatives over the years, starting with three key attitudes.

Clarity, curiosity, generosity

I have a practice of going through my calendar and making pre-notes for meetings at the start of each day. I write down the purpose of the meeting, then I answer the question “how do I want to show up?” Over a year of doing that, I found three words showing up more than any other:

• Clarity: I want to focus on what’s important and help keep other people focused, too.
• Curiosity: I want to understand what the people around me need and how they may see things differently from me. I want to learn more about how they work and what their jobs require of them. I want to understand how their version of “common sense” differs from mine.
• Generosity: By knowing what’s important to me, I can be generous: I can share control, or information I might otherwise hoard to keep control of things that don’t matter, or show flexibility to change how I work because my particular processes and practices aren’t good unto themselves; they’re only as good as the outcomes they enable.

These are all aspirational states, for me at least, but when I leave a meeting or 1:1 feeling like I kept them all in sight and honored them in some small way, that goes down as a “firing on all cylinders” interaction. They’re the foundational mindset of leading inclusively, helping me to welcome people in and behave like someone people want to collaborate with.

Being clear on what matters

Our needs and incentives don’t always align with the people around us, even in very directed, disciplined organizations. We may share the same top-level OKRs or goals, but underneath that are all the contradictions that come with multiple specialized groups with different jobs. Being clear on what we need for ourselves and our own teams at the start helps remove a lot of distractions and ease the tendency toward uninclusive behavior.

When I’m sitting down in front of a blank piece of paper thinking about how to start building out an initiative or describe a project, I like to ask myself one question before any other:

“What problem am I trying to solve?”

It gives me a moment to think about where I need to end up. It focuses me on the thing at hand, helping me disentangle this particular work from all the other things I’ve got to think about. When I don’t start that way … when I start with a list of outcomes or a set of preconceived milestones the writing takes on an improvisational air as I try to cover all the elements of a vision I still only see as an aggregate.

This is useful as a way to focus and think, and it’s also key to showing up well when working with stakeholders. Knowing what you really need going in – understanding what problem you’re trying to solve, what outcome you need to achieve – helps you remember what’s important and set aside things that aren’t. In return, the list of things you have to control or worry about shortens, and you can act with more generosity.

Cast a wide net

Grounded in your goals and objectives, you need to cast a wide net as you organize your stakeholders.

This is less a question of “what:”

• People working in other business units with a stake in the outcome who have to contribute and even drive parts of the work.
• People working in support functions (e.g. finance, HR, IT) who can provide support in the form of communications best practices, access to centralized resources, or just smoothing out the path through things like tool adoption or expenses that have to be shared.

It’s more a question of “how:”

• Talking to the obvious stakeholders ahead of time and asking them if you’re missing anyone in their organization, or someone they regularly work with in another.
• Sharing your stakeholder list early, ahead of any kickoffs, so the network you just created for your project or initiative can help you fill gaps.

I like to think in terms of “day 0”: Pre-kickoff socialization and check-ins, before the story goes from you asking, “should I include you?” to them saying, “I heard there was a meeting I wasn’t invited to.” I know which conversation starter I’d prefer.

Communicate roles and responsibilities clearly

Another part of “day 0” is taking an initial swing at understand roles and responsibilities: Describing where everyone fits in, how they can best contribute, and where in the work they should be shifting between offering input or consultation, or actually owning and driving.

It’s helpful to learn how to think in terms of the DACI decision-making framework, even if you never sit down and write up an actual DACI matrix:

• Who decides this is done to standard?
• Who makes sure things are getting done?
• Who needs to be consulted for this to be successful?
• Who needs to know what we’re doing (or what we decided)?

It’s helpful to distribute this ahead of a kickoff, too, along with the initial agenda. It will often jog peoples’ memories about other potential stakeholders, and it will give them a chance to have the conversations they need – with their teams or leadership – to get clarity on their own goals, or to speak up if you missed how they can best contribute.

Assertiveness is okay

Assertiveness about roles and responsibilities sometimes feels like the opposite of “inclusive” or “welcoming.” You’re telling people where they fit into a project or process. Sometimes, if you’re being realistic, you know they might not like what you have to say or they may be working for a leader who coaches toward keeping control of a situation.

Remember a few things:

• They might not even react that poorly. People are often relieved when they learn that all you want is consultation, provided they also see a good-faith effort to listen and act on what they told you.

• Some people are resistant to “merely” being informed because they’ve lost confidence that that will even happen, and that they’ll miss out on something important to them. That’s why you take the time to cast a wide net in the first place: You’re on a better footing to build trust if you included them to begin with.

• Being clear on what you need makes it easier to say “you know what, for this part of the process where you’re the one doing most of the work you should drive design and approach – what matters to me is over here, and I’ll drive that.”

It’s a fine balance, being assertive around roles and responsibilities while also remaining curious, and generous. The clearer you are on what you really need, and the less attached you are to an abstract conception of what it means to “be in control,” the easier it is to be a kind of “assertive” people respect.

Be ready to negotiate

In organizations trying to scale up there are a lot of business processes unique to each group that were never built with other groups in mind. Specialists in support services layer on processes and practices meant to smooth out their own work. They’re also frequently oversubscribed, and struggling to figure out how they can participate. Sometimes they can come off as rigid or disinterested in deviating from their particular processes. Curiosity is a useful mindset. You can ask:

• If we need to move faster than your process allows, which parts matter the most to you?
• Can we do some of this in parallel?
• Will you accept a commitment to do a fast followup and “fix it in post” if we need to deliver something before all your work is done?

Just lead with the goals and objectives you made sure you were clear on before you even sent out the first invitation and make clear you’re curious and interested about their own goals and objectives.

Record and communicate your decisions

Once you’re up and running with your stakeholders, there’s still a possibility you’ve missed someone:

• A person who should be participating but isn’t – your network just didn’t catch them.
• Someone who’s affected by what you’re doing and needs to be informed, even if they aren’t in a position to make decisions about your work.

People become anxious and controlling when they’re not informed, and the people who need work on consistent communications learn the wrong lessons from the anxious and controlling people around them: They double down on their uncommunicativeness and unwillingness to include people. It’s the worst kind of negative feedback loop.

To head that off, you should be documenting your decisions in the open, whether that’s a regular communication in the right forum or just making sure your decisions are captured in a wiki or accessible project board.

It’s helpful to think of project meetings and documentation in a manner similar to the “sunshine laws” you find in government:

• Meetings and communications in the working project group are relatively privileged: People should feel free to express concerns, address potential management and communications challenges, and “think aloud” in a way that enables creativity.
• Agreed-upon actions and decisions have to be publicly communicated in a forum that allows feedback.

I like RFCs because they make the ideation and decision-making process more transparent, and because they provide an opportunity to explain roles and responsibilities up front. Seeing the history of a decision – then seeing who made the decision, and understanding whom to appeal a decision with – gives people more confidence in the decision. If they feel like they are valued stakeholders in the process who are being informed about things that might affect them they’ll feel better about participating.

As with every tool that adds an element of structure and formality, people might feel uncomfortable:

It’s sometimes hard to work in the open, especially if there are trust issues to deal with. It often helps to book time with people new to written collaboration and talk through expectations, or to share prior art as a model. It also helps to simply take a few minutes to let people talk out a concern they’re struggling to commit to writing. We often experience tension between telling people what we need and framing it in a way that’s okay in the context of showing up collaboratively. Giving people a little space to just say it out loud helps them figure out how to think about it more constructively.

Another tool to consider is a simple decision registry: A place where decisions are consistently recorded, including who made the decision and links to supporting documents or meeting notes, for anyone to review.

Learn why passive voice isn’t just a grammar teacher’s hangup

In a nutshell, “the passive voice” involves sentences where nobody does anything and everything is acted on by … something or someone unspecified.

The grammatical reason to avoid the passive voice is that it is usually less efficient and elegant:

“It was decided to proceed with the alternative proposal” is a poor choice when “Joan decided to proceed with the alternative proposal” is sitting right there.

The social reason to avoid the passive voice is that it obscures accountability, dilutes responsibility, and hides the decision-makers. People sometimes think it is a trust-building choice because of a mistaken belief that it sounds more formal and business-like, but it has the opposite effect.

The operational reason to avoid it is that it makes a process document impossible to read or use, because people start from “what is my part in this process?” It is very hard to search for your team’s responsibilities in a document that never says who’s doing anything.

Be ruthless in eliminating complexity

If you’re a process person – if you thrive on thinking through a flow chart, covering all the angles, de-risking each step – then you are more likely coming from a place of comfort with a certain kind of complexity, and of some familiarity with all the systems you have to interact with.

That is not everybody.

As I’ve worked on an essay about a change management document I have used a lot, I’ve thought a lot about the times I put that document in front of a leader trying to figure out how to make a needed change then watched their faces fall as they saw two pages of questions and tables. I pared it down over time as I reminded myself of the idea that “if it’s not obvious to the person you’re trying to help, it is not obvious.” The version I’m looking forward to sharing shifts a lot of the questions people were expected to answer completely to prompts they could think through without writing a novel.

One team I joined had a particular JIRA workflow that couldn’t start until the customer successfully completed a 12-question form that substantially repeated itself and made clear that no matter what you said in each of the “three or four paragraphs recommended” fields, you were going to have to re-explain.

When I was put in a position to do something about that, I changed the twelve questions to three:

1. What problem are you trying to solve?
2. (Optional) Have you identified any solutions you’d like to try?
3. Does your departmental leader know you’re asking for this?

Anything else we could handle by sending a business systems analyst or architect to ask, and we stopped the practice of making people fill out associated tickets: BSAs, project managers, and other specialists knew what we cared about and offered to capture that in a meeting where people could just talk out their needs.

I wish I could have collected better metrics about that change, but it was easier to toss the old workflow with all of its conditional logic and triggers than try to preserve the 25 (!!!) tickets one customer request would generate. What I do know is that group reviews of the backlog shifted from months-old requests languishing to a more frequent “we opened this last week, did we …” “Yes, it’s moving on to a PoC.”

When you’re working hard to make the process more accessible to the people you’re supporting, most of them can tell. That makes asserting roles and responsibilities easier, and it makes communicating decisions easier, because you’re building trust that the process is there to serve and accommodate them, not marginalize and disempower them.

So, bias toward simplicity, and if you’re responsible for designing or driving a process, take some responsibility to ease peoples’ interactions with it. If you know writers or UX designers, they’re great people to bring in for a quick consultation: Writers can help clarify language and expose faulty reasoning, and good designers excel at taking workflows apart and considering how people can interact with them more successfully.

… and be patient

Part of an cross-functional leader’s job is untangling mistrust and resistance. Getting people to participate in a more inclusive process can be challenging because they may have learned over years that “The Process People” are best worked around or avoided, or that they have to think in terms of control instead of outcomes.

When I first introduced RFCs to a group as a way to make ideation and decision-making more transparent, some people didn’t participate: They didn’t see the point and hadn’t seen cross-functional conversations about shared problems work. Within a quarter, though – having seen a few play out and having learned they could talk through things like a disagreement about roles and responsibilities – people who’d been conspicuously silent were kicking off their own RFCs and driving accountable behavior around them.

When I first introduced decision registries to a governance group, the initial few responses around the company were “who the hell put this group in charge,” but because we were sharing meeting notes and tickets publicly, and then writing down our decisions, people went from that early hostility to, “I’m affected by this decision and I don’t see myself in any of the docs, can I be included?”

Of course they could. We wanted to help everyone do their best work, and that started by trusting people to be collaborative, and making sure they saw the structures we built and the way we worked as something that enabled their participation instead of locking them out.

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.

A peer from another department called a meeting, began to draw a grid on the whiteboard, and casually said over his shoulder, “this isn’t a land grab, but we need to get clear on ownership.”

Then he filled out the grid with who was in charge of what, who was responsible to do what, and who didn’t really need to participate in the work but needed to know what was going on.

It felt like a land grab. I’d been at that startup for a bit over a year, and had acclimated to the shift from a larger business where people “just knew what to do” and generally stuck to their remits, to a much smaller, more entrepreneurial business where people just grabbed stuff if it aroused their curiosity. In that more relaxed, less functionally siloed environment, it seemed a little rude for someone to come put us all in boxes in a grid.

I’ve come to believe it was necessary, even if it was jarring.

In the early stages of an organization, certain roles and responsibilities can live in one function or team, then migrate to new ownership as the company grows. As these changes occur, roles and responsibilities can become muddled or unclear, and it’s not uncommon for a group of people embarking on a new project to become confused about “who owns what.”

Setting aside the challenges of young organizations, as companies shift to hybrid-remote models it will become more and more important to develop practices that work well for people who work somewhat asynchronously. That includes writing things down and creating written records of decisions. 

Decision-making frameworks, like the one my peer was using, can help clarify roles and responsibilities and chip away at the need for synchronous meetings by encouraging you to ask a few questions when you’re designing a project, planning work, or making a decision:

• Who is responsible for making sure this work is happening?
• Who authorized this work and is responsible for approving it?
• Who is expected to weigh in or contribute to the project?
• Who needs to know about this work?

RACI, DACI?

There’s a large number of decision-making frameworks out there. Many people are familiar with the RACI model. Personally, I prefer the DACI model to record roles and responsibilities for any work that requires more than one team or department.

I also find DACI’s roles (driver, approver, contributor, informed) to be a little more intuitive to people new to these sorts of frameworks than RACI’s (responsible, accountable, consulted, informed). “Responsible” and “accountable” are hard concepts for people to tease apart, whereas “driver” and “approver” are easier to understand and distinguish from each other.

It’s important to note that this is not worth some sort of weird project governance nerd fight. The mere act of sitting down with a project plan and applying either of these frameworks will do some good, so if you’re at the point where it would be helpful to have a tool that helps you think about roles and responsibilities, you should just pick one and muddle through. It can be awkward at first, and there’ll be a lot of different preferences and understandings, but the immediate benefit is that you’re talking openly and transparently about something that often makes people uncomfortable.

What is DACI?

DACI stands for “Driver, Approver, Contributor/Consulted, Informed” and is used to describe the roles of people involved in a project, decision, or task. Here’s each role in a little more detail:

• Driver: A single driver of the overall project: the person steering the car. The Driver develops the DACI for the project, identifies the high-level work that needs to be done, and leads the project throughout its lifecycle.
• Approver(s): One or more people who make most project decisions, and are responsible if it fails.
• Contributors: The people responsible for deliverables; and with whom there is two-way communication. Some people also refer to this part of the DACI matrix as “consulted” to account for people who should probably be asked to weigh in even if they aren’t delivering anything besides advice or context.
• Informed: The people who are impacted by the project and are provided status and informed of decisions; and with whom there is one-way communication.

How do you make a DACI?

At its very simplest, a DACI can be a list. Just write down the four roles and fill it in with the people who should occupy them. That’s it. Some people like to make tables or forms, but it’s not necessary and can add extra work if you’re not proficient with using tables to organize information. Rather than wrestling with formatting, you should be spending your time thinking through roles and responsibilities.

Some DACI practices

It’s a good practice to put a DACI at the top of your project documents and talk it through with people when you hold a kickoff meeting.

If a group you’re working with hasn’t used DACI themselves, sharing something like this guide or one of the articles I list below as a pre-read can go a long way to making it seem a little less strange. In organizations where there’s a lack of trust or a lot of contentiousness, it can be strange and awkward to openly discuss this kind of thing.

For complex projects with a number of work streams, you may need to create a high-level DACI for the entire project, then DACIs for each work stream.

It’s not out of line for the “Approver” in a DACI to be a group (e.g. a senior leadership team), in which case the “Driver” is accountable for wrangling consent and finalization from the team in the “Approver” role. This isn’t an invitation to descend into consensus culture or require unanimity to make a decision: Sometimes people have to make the choice to “disagree and commit.” The Driver has the privilege of determining when productive conversation is exhausted and the work is ready for review by the Approver.

It’s a best practice for the person in the Driver role to make the DACI available for review and comment.

While the Driver is the ultimate decider of roles and responsibilities, asking for comment and feedback can help settle the sometimes tricky question of who’s consulted and who’s informed by giving stakeholders a chance to think about and comment on how they’re impacted by a project. That sort of review will often unearth somebody who might have gone missing otherwise. That can help ensure, when you get to the point you’re pushing ahead with an RFC or project document, that you’re not missing something.

If you’re doing something with broad implications for an entire organization or multiple departments/teams, asking the Approver for a quick review of the DACI before sharing widely is a good idea. They may have context about other departments or stakeholders that can help you craft a better, more inclusive DACI. In contentious environments, they can do some diplomacy with their peers.

Finally, remember that a little goes a long way, especially at first. DACIs and RACIs provide a level of structure that can feel awkward and stilted. If one team is used to talking in terms of roles and responsibilities but another isn’t there yet, a DACI can feel unusually assertive. So if you’re bringing DACIs to people who are new to them, be patient and be as kind as you are clear about the boundaries these frameworks represent.

More reading on DACI and decision-making frameworks

• Using DACI Framework for Better Group Decisions - a quick overview of DACI
• The DACI Decision-Making Framework Explained - another overview and brisk walkthrough of how to build a DACI
• Trello’s take on DACI and another guide to how to build a DACI matrix.

I say 'I consider myself a feminist,' because I really do. But I always feel like I'm taking a big risk when I say 'I AM a feminist,' because there is always, always some other feminist out there who will show you that you're wrong. Usually they'll also show you that you're awful for it. — Someone somewhere I visit regularly

Another feminist here. That’s an understandable sentiment.

Personally, I hate calling myself anything at all, ever. I spent four years trying to reconcile what I thought I was, what I wanted to say to people I was, what I wanted people to think I was underneath, and what I wanted to be with what I was being every single day by just waking up where I was waking up and doing what I was doing.

I spent even more years after that trying to work through whether I’d ever known or could ever know what I was: Maybe I’d stopped listening to my better angels. Maybe the better angels had never been real. Gandhi had suggested that nonviolent behavior could be motivated (and tainted) by cowardice, so I wondered to myself if what I’d thought had been a nonviolent worldview hadn’t actually been a sort of cowardice, and that by enlisting maybe I’d just embraced what I’d always been.

Some understandings about myself and the world around me crystallized, some things just got more complicated:

Could I jump out of an airplane at night? Yes. And for the last year I was jumping out of airplanes, it’s fair to say I was frightened every time. By the time I got to that point, I’d healed up a lot. I wasn’t who I’d been when I walked into the recruiter’s office: If the controlled environment of the army had been a splint or a cast, it ended up setting my bones into shapes they hadn’t been before I enlisted. So I gained some understanding of what it is to be deeply afraid and yet still do the thing you set out to do. For a period, living that pattern allowed me to say to myself that I wasn’t a coward, that I had a core I could depend on. So I started looking beyond where I was, and having thoughts about what could be next, and wanting it. I didn’t want to give up and disappear into the army.

Then I was out, and rather than going back to be near the people who had cared about me and supported me while I was in, I chose somewhere else. I couldn’t just go back to where I had been, among people who might have been tempted to say, “well, that’s all over now and you’re back.”

I was loved and cared for, but not a lot of people knew me. They just had the biography, and that question of cowardice was still very real, and was suddenly unresolved again because I figured out that physical courage isn’t moral courage. So, I wanted the new people in my life to know something more about me than where I’d been, but I was still struggling with what it was I’d want them to know, and if it was possible for there to be anything more to know. After all, there was what I thought I was, what I wanted to say to people I was, what I wanted people to think I was underneath, and what I wanted to be, but there was what I had been every single day for four years by just waking up where I was waking up and doing what I was doing:

I’d been the guy who got sent to the chaplain because he wouldn’t sing the baby-killing cadences, and then invited to declare himself a conscientious objector. Didn’t do it, though, because I wasn’t. I just didn’t like baby-killing cadences.

I’d been the guy whose boss told him he should seriously consider taking a subordinate into the woods to beat him up, and briefly wondered if it would need to come to that, then learned how to make anger and its energy palpable; maybe to help avoid taking that step and maybe to make it easier if I had to.

I’d been the guy who told a barracks bully that I’d take an eye or an ear, and needed to believe it.

I’d been everything that environment demanded of me, and I chose to stay in it.

I nearly started typing, “but in the end,” because that would allow this to be narrativized and resolved. But there’s no end because I’m still sitting here typing. There’s an ever-unfolding now that I needed to learn about.

There were all the moments where I looked back on some of the things I said and did and hated them. When I’d tell stories about things I’d seen or done and I’d realize people were repelled by the mere fact that I’d been there to see them. There was the year where I needed to get help because I’d see a picture of a maimed child in an Iraqi marketplace bombing, or read about a murder-suicide on an army post from some solider who’d come back from the wars changed, and I’d think about how I’d wanted to be some part of that, and that’d be it for the day, stopped by anger and grief. I’m so glad I worked at home: I don’t know what I would have done with people around when those moments came. Maybe I would have just swallowed it whole instead of composing some polite fiction of a status message and going to sit in my room.

Then there was just more life, and a slowly growing recognition that I couldn’t ever un-be those things. When he was little, Ben thought I’d once been a knight. It was heartbreaking to explain that I hadn’t been. But it was strengthening to realize that the more truthful I could make myself be with him, the better a parent I could be to him.

I figured out that I had to start being the person I wanted to be in that ever-unfolding now. I had to accept that some people would see the biography and think things they’d be justified to think, and that I had to set that aside: There’s no erasing it, and to erase it would be to erase me. Instead, I had to learn how to be open to the things that I can hear and feel are right, and accept that they might be incongruous with what I’ve been.

Because of all that, because I once set aside everything I said I was and became something else, and because I then spent years trying to make all of that make sense, I’ve got a deep aversion to saying I’m anything at all. To the extent it’s any of my business how people talk about themselves or what they are – and it almost never is – I wish there’d be less “speaking as a …” and more “because I live my life thus.”

At the same time, self-identification helps people, right? It helps us hold each other – and ourselves – accountable.

I read bell hooks’ Feminism is for Everybody where she writes “the soul of our politics is the commitment to ending domination,” and I thought to myself “yes, that’s right, I want to live that and teach my son that.” I put down the book and thought “I agree with her, and other people who call themselves feminists,” and then I felt okay saying “I’m a feminist.”

Despite my aversion to saying “I’m this” or “I’m that,” I think “I’m a feminist” is a thing worth saying.

Because I’m a man, steeped in this culture and taught habits of thought that are anti-feminist, I’ll sometimes do things that aren’t feminist things to do. I’ve been lucky to have people in my life who have been gentle and patient with me when I’ve done this. Some day I’ll meet someone who won’t be as kind, or who will want to prove that I’m not a feminist at all. Depending on who that comes from, that could be upsetting or embarrassing.

The alternative, my heart tells me, is to be less supportive than I could be; to be an “ally” who can still maybe slip back and forth, maybe never having to own being wrong or hypocritical ever again because I remember how hard it was to put a sense of self together again after being something besides what I wanted to be.

All we can do is be what we are in the ever-unfolding now. We can open ourselves to hearing what’s right, and we can try to choose what’s right, or at least choose what’s less wrong. We can accept that we’ll sometimes fail at that. We can allow ourselves to be held accountable. We can try again.

prologue

When I lived in Bloomington, IN, some guy spent a week in one of the student neighborhoods attacking women. The one account I read from a victim was that he walked up to her with keys sticking out from between the fingers of his balled fist, slashed her cheek open, and said, “not so pretty now” before running off.

i.

#YesAllWomen BC on campuses all over the US women are leaving their schools because their confirmed rapists are not expelled. — Soraya Chemaly (@schemaly) May 25, 2014

A while back, before Ben was born, I took a few night classes. A few of us getting out of class together had to walk four or five blocks down a quiet side street to get back to a common parking area.

So, class would let out and we’d make our way down to the street. Throw in some random travel variables — like getting backpacks repacked or chatting with classmates on the way out the door or whatever — and you’d end up with four or five of us spread out over two blocks headed the same way down a side street after dark.

Most nights, there wasn’t much to think about: Out the door, down the street, into the car, home.

One night, I ended up falling in behind a woman from my class. She was about half a block ahead. I don’t think she noticed me at first, but I stepped onto a loose metal plate and it made a big noise. She glanced over her shoulder and appeared to notice me for the first time, and I think the next several blocks were very frightening for her.

Within a block, everybody else had headed down another street. It was just the two of us. She kept glancing over her shoulder, and I could tell I was making her anxious. There was no way it made any sense to pick up the pace to just get past her — I was engaged enough to realize that — but there was a smaller, stupider part of me that was pretty fixated on just getting to my car and going home. That part wasn’t doing much problem-solving that didn’t involve getting to go the direction I wanted to go as quickly as possible.

Well, let’s not dissociate.

I wasn’t doing much problem-solving that didn’t involve getting to go the direction I wanted to go as quickly as possible.

In the end, she ended up picking up the pace, she got to her car a block ahead of me, and it finally occurred to me that if I slowed down just a bit she’d be able to get into her car without feeling quite so much like she was racing me to get something between us but distance on a dark sidewalk.

So I slowed down and she got into her car and she drove away and I quietly congratulated myself for the five percent of our separate but shared walks where I had really thought about her and what she might be going through.

ii.

Every time I get in a cab I send the cab number, and cab drivers name to someone, just in case #YesAllWomen — expert subtweeter (@meaganewaller) May 25, 2014

The next week, class let out and I went out the door with another woman in the class who’d been in my workshop group. We’d enjoyed each others' work and we were talking about it. We walked out onto the sidewalk and I noticed we were headed the same direction. I didn’t want the conversation to end quite yet, so I pointed the way she seemed to be headed and said to her, “are you headed this way, too? I’ll walk with you.”

Her face tightened for a moment, but then she agreed. We walked a few blocks, she got to her car before I got to mine, and I had yet another belated realization that she’d been nervous the whole time. She couldn’t say goodbye fast enough.

iii.

Because "Text me and let me know you got home safe" is standard, necessary and normal. #YesAllWomen — pleasedonteatjo (@pleasedonteatjo) May 25, 2014

So, when class let out on the third week it was back down onto the sidewalk and assorted variables came together to put me about half a block behind the classmate I’d walked with the week prior, just the two of us on the quiet and dark sidewalk. And — just like two weeks prior — she didn’t notice me until I made a sound. Then we spent a block with her looking over her shoulder at me, noticeably picking up the pace.

So I stopped and put my backpack down on the sidewalk to get my keys out of it, which helped her put a block between us. Then I crossed the street so I’d be on the opposite side from her, and slowed way down until she made it to her car.

iv.

I’ve done pretty much the same in similar situations ever since: If I end up behind a woman on a quiet sidewalk, I just go across the street. If I see that she’s noticed me behind her before I can do that and seems to be watching me, I’ll backtrack to the last intersection to do so.

It’s the smallest, saddest thing.

#YesAllWomen