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.

It’s one of my go-to questions because it cuts quickly to things that matter to me in a leader on my team.

As with all things there is a balance that’s sometimes lost over time as we progress through our careers and do the things we believe we have to do to scale ourselves and our management practice, and to demonstrate that we think at scale so we can keep accruing opportunities and influence.

In an ideal world careers are a layering process: We pick up a skill, we use it day-to-day, and when we take a step up we learn how to teach that skill so we can delegate it; we fold the values it taught us into the cultures we’re building in our growing teams.

When it comes to change management, we pick up a few skills early on, as line managers and small team leaders:

• Building resilient, adaptable teams. Some of that is about creating a culture of continuous improvement, some of it is about not swiping the change credit card frivolously, and some of it is about building trust that you’re the team’s champion and advocate.
• Learning how to carry the message from more senior leaders authentically, even when you wish they’d chosen a different path.
• Learning how to listen effectively when people on your team bring concerns about a change.

All of this is high-touch, “retail” work that involves coaching and developing an individual voice even as you master a “disagree and commit” mindset. You have to develop the essential skill of being authentic and honest with your team, and you have to be able to sit with other peoples’ emotional reactions to change, even as you led them through that change.

I’ve seen two ways leaders can go wrong as they take the next step, especially when they move to a role with a more diverse set of functions:

One kind of leader never sets aside those high-touch habits – they stay “retail:”

Instead of learning to ask their managers and leaders “how’s the team?”, or “what are the hotspots?” (not who are the hotspots, but what are the hotspots), their first reaction is to jump in and bring each person along, or hold group meetings where they’re anxiously scanning the crowd for the resisters. They turn one-time open door meetings into standing 1:1s. They short-circuit their line managers’ ability to build trusting relationships on their own. And sometimes they give away the farm, undermining the change they asked their team to drive because they are too wrapped up saving people who are not coming along.

Another kind of leader runs in the opposite direction, and goes “wholesale” with a vengeance:

They might have been good at building teams with high esprit de corps and high trust, or they might have just been good at getting to “good enough” alignment without so much attrition that it raised any eyebrows. They might look over at the leader who never got away from that “retail” work and see them consumed by its demands. They take away a lesson that some people just don’t want to come along, that it’s on line management to carry the message and accept some losses, but to them it’s just a line management problem. Sometimes they even coach their line managers to think about trust-building, transparency, and active listening as a little wasteful – something to grow out of.

A sustainable path that doesn’t lose sight of the humans in your organization involves balance, and taking advantage of your growing influence and experience to build a management practice that supports line managers and creates space to do good small-team work.

1. Move your “retail” practice up a level: Help your managers see the difference between active, empathetic listening and indulgence or axe-grinding. Help yourself by keeping the conversation general – what is happening, not who is doing or saying what.

2. Set the bar for intervention higher than you might be comfortable with, whether your impulse is to get in and sooth resistant people, or to coach the manager to draw a bright line and quit “wasting time on feelings.” People management is just as vulnerable to micromanagement as delivery management.

3. Take time to develop change management communications and action plans in consultation with your management team. They’ll probably have a better grasp of the “what’s in it for me” issues on their teams than you, and they’ll be more confident and assertive if they have some ownership in both developing the needed change and creating the message around it. If one of your managers is content to say “I don’t think they’ll have any concerns; they just need to accept it,” they’re not doing their job as one of your team stewards.

4. Remember your role as a supporter, and marshal resources for your team: Take the time to help the specialists around you – communications, HR business partners, program managers – engage with your team with communications planning, “dress rehearsals” for delivering a change message, change management, and followup.

5. Invest in training and support before managing a big change: Programs like Crucial Conversations or Fierce Conversations help managers learn how to manage their anxiety ahead of a difficult conversation through normalizing the existence of conflict and practicing hard conversations. HR business partners and experienced leaders can coach managers on what it’s okay to say and how to say it that helps boost their confidence when they have individual conversations.

6. Develop a continuous improvement practice that shows each change is considered, intentional, and communicated both in terms of the need for it, and how it will be carried out, measured, and iterated on.

As that list indicates, I still put a lot of stock in preparation and good operations for change management. But once you’ve moved through the execution phase and are on to measuring and iterating, line managers are the ones who bear the burden of settling and focusing their teams. You should be there for them, supporting them and building their confidence in their ability to lead, but the time to show your own growth happened when you built supportive practices that keep humans in mind while driving the change your organization needs.

I was talking to a friend about her work with a new-to-her team of managers. She had proposed “doing an experiment” with a change to how their teams were working, and they were all resistant.

The change she was asking for was small and incremental – there wasn’t any misplaced “change agent” or “boil the ocean” energy behind it. Still, the quiet ones just stopped interacting and the more vocal ones began listing all the reasons their teams weren’t up for yet more change. None of it was very concrete, and it left her thinking she’d picked up a team of people who just didn’t want to change how they work.

I remember running into the same problem with a new-to-me team.

It was frustrating because I’d felt like we were off on a good foot: They knew me by reputation before I joined and there was a foundation for trust. But when we came across a hitch in an old process that hadn’t changed with the business around us, I breezily said “well, why don’t we try an experiment” and proposed a potential improvement. I could see them shut down.

My first thought was “what on Earth is the problem here,” so I asked and they were forthcoming:

For years, “experiment” had been shorthand for “let’s just do this thing and see what happens.” Leaving aside the definitional problems Webster might raise, it came with other baggage.

• The “experiments” never seemed to be testing anything in particular. You could just as easily replace “let’s try an experiment” with “let’s throw some spaghetti at the wall.”
• They were never bound by time, success criteria, or retrospection.
• Because of that lack of structure, they’d eventually melt into the practice of the team whether they improved anything or not, becoming zombie processes or unexamined “that’s just how we do it” norms.

I had my own damage over undefined “experiments,” so it wasn’t too hard to wheel it back. They were right to be suspicious of the word, and I admitted that, then I laid out for them the same thing I suggested to my friend:

First, ask the question “what problem are we trying to solve?”

In a room full of people, you’ll probably get a few versions, so asking helps get the team aligned. As a manager or leader, you’ll give yourself an opportunity to unwind a few assumptions you’ve already made.

Second, decide how and when you’ll know the change had its intended effect.

• If it’s something you have metrics for, that’s great. If it’s not, keep any potentially helpful metric you identify light. You can go full Zeno’s Paradox over metrics.

• If it’s in the realm of the more qualitative give the change a little time, then periodically survey the team. 1:1s are better than team meetings for this. Just keep track of sentiment and lay out your observations when you lead the review.

Sometimes you’ll get immediate feedback, other times – if the change is going to touch a lot of things or lives in a complex process – you’ll have to give it more time. Leave room for a few repeats either way:

‘Once is happenstance. Twice is coincidence. The third time it’s enemy action a pattern.’
—James Bond

Third, set a concrete date to review the change and make a decision about it:

• It satisifed our success criteria, let’s keep it.
• It didn’t satisfy our success criteria, but there are ways we could adjust it. Let’s think about those changes and re-up the change for another period.
• It didn’t work at all. Let’s discuss why, then go to the next candidate.

Then stick to that decision.

If you decide to end it, end it, tell the team it is done and keep any documentation you have about what happened, how it worked, and why. Some teams keep a “decision registry” for this kind of thing. Other teams have an RFC process of some kind. However you do it, make it easy to find your notes: Future new team members or even your successor will thank you.

It’s important to stick to that decision because people who are hungry for change – or even just amenable to it – will lose their enthusiasm if they perceive that each “experiment” will become yet another geological layer of unexamined process or practice to contend with.

I’d always considered myself a good listener, but came to realize that perhaps I wasn’t an effective listener.

I went into that year as more of a fixer, imagining that my job was to give advice, or take care of problems for people if they couldn’t follow my advice. As the year progressed, the way I assessed my own effectiveness as a leader and a listener evolved. I spent less time giving advice, I measured the success of a given interaction by how much less I said than the previous one, and I shifted from offering to intervene to offering help with developing a strategy for a difficult situation or conversation the person I was listening to needed to handle for themselves.

Every now and then, you come across a phrase that helps you make a shift. That year, I came across this one:

“Listen like you don’t know the answer.”

I once had a boss who always anticipated the problem I was bringing to him, finishing my sentences then jumping to his personal playbook to offer a solution. Because his playbook was his playbook, built up over years of him solving problems with the gifts and tools particular to him, it didn’t do me a lot of good.

The great thing about that relationship was that I eventually learned to say, “I don’t think that will work for me,” and I’d explain why, and he’d settle into a more constructive, conversational mode, helping me break down the problem and figure out how to solve it in a way that worked for me.

When you’re in the listening leader role in a conversation, you become a lot more accessible when you listen without judgement, or without conveying the sense that you’ve seen and done it all, or that the problem someone is experiencing is trivial.

Over that year, I developed a set of principles. After moving on from that role, a senior leader in the company came to me and told me that people had told him they considered me an effective listener, so he asked me to give a presentation for other managers.

Below is an outline of that presentation.

People deserve to know their choices. Focus on that instead of fixing things. 

Nobody likes it when people who do good work leave, and some people don’t even like it when people who do mediocre work leave. During a time when there’s a lot of focus on attrition or concern about morale, people will sometimes soft-pedal bad news, avoid making hard decisions, or try to defer unpleasant or hard conversations to keep everybody happy. 

When you do that, though, you’re just kicking the can down the road and possibly withholding what people who are genuinely unhappy need to get “escape velocity,” make a decision, and move on. 

Don’t withhold in the hopes they’ll just calm down for a while. If they’re faced with a situation that simply isn’t going to change, they should know that, whether it’s “that’s not how we work here anymore,” or “we’ve made that decision and aren’t revisiting it.” 

Anything less is just allowing them to stay in a state where they think something will change that won’t, and it’s keeping them from making a better decision than “hang around until the thing I hate goes away.” 

You’re having these conversations because there are strains in relationships, and you should be working to make those relationships whole again

Ideally, you’re giving them someone to talk to, and encouraging them to take their problems to the person best equipped to solve them as they’re able to get enough perspective to do so. You engage in constrained and discrete action or intervention as a last resort. 

In other words, the interactions you’re having with any given person aren’t the desired end-state: It’s an interim situation. 

Some rules

You have to sit and listen

It’s tempting to come to think of yourself as a fixer, whether it’s of a broken manager/report relationship, a system or process, or even just someone’s faulty perspective. 

When someone first agrees to sit down with you and tell you what’s going on, though, the thing they’ve asked you to do in that moment is listen. They might ultimately want you to fix something, and the hope that you’ll fix something is probably part of why they’re sitting there talking to you, but in that moment the thing they want you to do is listen. Their problem probably feels unique to them, in the particulars if not as a general kind of problem. Something about it feels like it’s outside their experience or ability to handle, or they’re simply not sure what their expectations should be. 

Just listening can be pretty hard. You might have some idea of what their problem is before they even begin to speak. You might be able to see where they’re going before they get very far in to what they have to say. It’s important to let them talk it out: They need to talk through their feelings and they’ve asked you to help them do that. Sometimes they’ll even talk themselves into a solution or end up better understanding what they want to ask for. 

You don’t always have an answer, and you need to admit to that

Sometimes you don’t know. It’s okay to say you don’t know and need to go learn more. 

You have to learn how to find the balance between acknowledging their feelings and being part of a management team

Sometimes, you’ll believe another manager made a mistake in their handling of a situation. The times that’s obvious and clear-cut are pretty few. More often, there are a bunch of perspectives on the problem. In some ways, it just doesn’t matter: Your primary function in the moment someone has brought a problem to you is to listen. (If they’re reporting unsafe behavior or a violation of policy, you definitely need to escalate.)

It’s still possible to show empathy and kindness without making comment on a colleague’s decisions: 

“How did you feel when they said that?”

“How do you feel now?”

“I understand that didn’t feel great. Looking at it from your perspective, I’m not sure I’d like that either.” 

You can’t ambush your colleagues with the things you learn

To most good managers, having a good understanding of the dynamics on their team and the state of the people on the team is essential to their professional self-respect. When it turns out they’ve missed a situation, or they’ve just learned that one of their folks is having problems without bringing it to them first it can feel embarrassing. 

One way to make sure people are in a good place to take in what you’ve learned about a situation on their team is to share it with them discreetly, not around a meeting table where they’re hearing about a problem at the same time as everybody else. If you use information you have about their team dynamics or one of their employees to show them up or contradict them, all you’re doing is creating resistance to finding a solution. 

You’re listening to everybody, but you have a network and need to acknowledge that

Even if you’re touching base with a lot of people, you probably have a few people you talk to most. They’ve got a particular perspective and while they may be pretty key and influential people, it’s still just their perspective you’re hearing. 

When asked “what’s going on on the floor,” acknowledge that: “The folks I’m closest to are saying this but I’ve also heard that.” 

A Workflow

When someone needs to talk, there are a few things you have to do: 

Listen

Just listen. Try not to say much outside the usual “active listening” stuff:

“What did you do next?”

“What went through your head when you heard that?”

Stay off your phone and stay out of your laptop, or set an expectation (e.g. “my son needs to call me from school this afternoon so I’ll have to pick up my phone when I get a notification.”)

Play it back

Once they’ve told their story, playing it back to them in a few sentences shows them you were listening and helps ensure that you’ve actually spotted the issue. You may have missed it, especially if you went into the interaction thinking you already knew what the problem was. 

Just play it all back in a few sentences, and make sure you got it all:

“What I heard was a, b, and c. Did I miss something in there?” 

Keep your own emotion out of it

Sometimes people bring some stuff that’s frustrating to hear. A lot of strong emotion from an authority figure can put people on high alert, or cause them to shut down. They’re often afraid they’re going to trigger some sort of reaction out of proportion to what they were hoping for. It’s not wrong to show empathy, or say “I can see how that would be upsetting,” (or frustrating, frightening, etc.) but don’t take on their emotions (that’s bad for you) and don’t make a big display of your own anger or frustration (they’re there for help, not to watch you process your own emotion). 

Let them know what they can expect

I always make clear their story stays with me unless there’s a policy, legal, or safety issue. Some managers don’t like that, but it’s one way to insulate the person doing the listening from being turned into a back channel: If the employee was hoping for that back channel, they know they won’t get it. 

Call it out when what they saw was wrong or unusual

Sometimes, you’ll learn of things that are plainly unprofessional or inappropriate. It’s not wrong to offer an opinion. Just make clear that it’s your opinion. 

I once dealt with an employee whose manager a. claimed that there were secret criteria for being promoted that he couldn’t tell her and she hadn’t met; and b. told her teammates she wasn’t mature enough for promotion. 

I called those things out as a. untrue and b. inappropriate. I made clear that she had an expectation of confidentiality around performance conversations, and that the behavior wasn’t normal.

Ask for permission to raise the issue with people who can fix it

We don’t want to be used as back channels for manipulation, and it also reassures people there asking for help with problems they can’t resolve that they won’t get someone in trouble or “call down the thunder” when they aren’t even sure there’s really a problem. 

Set expectations

Tell them:

• Who you’ll talk to, if they’re okay with that
• What you propose as a next step
• What you’ll do next
• When they can expect to hear from you

Follow up right away

Let them know once you know something useful, whether that’s “this is fixed,” or “I can’t do much more here, but here’s who probably could …”

There are a lot of practices, tactics, perspectives, and playbooks on “how to go remote” or how to work in a hybrid environment, and there are examples of companies that run a relatively narrow playbook or embrace a few particular practices: Shifting to a written culture, promoting asynchronous work, assorted social interaction techniques to capture what is lost when the office falls away as the center of work life, decision-making techniques, etc. There is a definite case to be made that some of these techniques will work better or worse or take more or less change to succeed. But at the core of the issue in front of us is how we are going to bring everyone along in a distributed, hybrid environment in a way that honors the equity and inclusion we prize.

So let’s start by admitting that behaving inclusively can be hard.

If you’re a manager, you’re probably thinking about your “budget” with your team: How much can you spend on introducing and supporting change?

If you’re a senior or more tenured person on the team, you’re used to things going a certain way, and don’t always catch it when something your team does isn’t working for someone else.

If you’re brand new, it is daunting and hard to speak up when you feel left out, or think something needs to change.

If you’re not part of the dominant group on a team – and enumerating the many ways people will feel that way about themselves is out of scope for this particular essay – you may feel like your perspective will simply be too alien to your teammates to share, or too frustrated from past attempts to share it to want to try again.

Even if everything aligns, and everyone agrees a change needs to be made, it requires intentionality to stick: There are habits to break, patterns to unlearn, and new behaviors to adopt.

Sometimes the things you have to do to be more inclusive – taking turns taking notes, or facilitating the meeting, or making sure everyone has had a chance to speak, or helping more talkative teammates tone it down while trying to draw out the more retiring ones or leave space for “the people on the screen” – aren’t that easy to do: They feel awkward and uncomfortable. Sometimes they even put people in conflict because it is one thing to intellectually embrace the need for change, but quite another to actually make the change.

But these changes will not just happen. Your good intentions or desire to do better don’t really matter. What matters is what you actually do.

Where are the leaders?

What’s required in all this is leadership.

It is by now a business article cliché to note that managers are not necessarily leaders, and leaders are not necessarily managers. I am going to return to this in a second because it is true, important, and only so useful an observation to make.

Anyhow: What’s required in all this is leadership.

Leadership, when we are talking about the problem of fostering inclusive behavior, can come from a lot of different places. It can be as simple as someone looking around, noticing that things aren’t quite right – not everyone gets a turn to speak, or that not all ideas are heard, or that someone speaks much more than everyone else – and says something about it. Leadership is when someone simply volunteers to pick up the marker and turns the camera to make sure “the people on the screen” can see the whiteboard during a brainstorming session. Leadership is pointing out that some studies indicate “brainstorming sessions” don’t actually work the way we think they do and proposing an alternative that actually works better when you can’t all be in the same room. Leadership is when someone simply starts taking notes because nobody else is.

The most inclusively minded person I ever had on a team was not a manager. When we established a team norm that everyone, including the director, was to take a turn taking notes, he noted the times I missed meetings and made sure I took my turn when I did manage to make one. He was the one who would look around the table and ask someone who had been sitting quietly what they made of the topic. He was the one who warned me, in private after a meeting, that my profane tirade about a self-evidently backward department elsewhere in the building might have undermined peoples’ sense of safety.

Some people like to call this “servant leadership,” and that’s fine. Reasonable arguments have been made that “servant leadership” is more a way to keep being the boss while presenting as self-effacing and humble, and I take their point. My favorite leader in the military always insisted on eating last when our unit was out in the field because it was the right thing to do – “mission first, people always” – but he did not need us to believe he was anything other than in charge.

Whatever kind of leadership you want to call it, if you have someone on the team regardless of their title or level who is simply getting out and pushing on inclusivity, even if it feels awkward or weird or makes people a little uncomfortable, that’s the leader.

Given that model of leadership – that it’s the person who simply does the needful when nobody else is – there’s sort of a resourcing problem: Leaders like that can be thin on the ground.

There are a lot of reasons for that scarcity.

Sometimes teams are too comfortable with old patterns. Sometimes the manager or leadership or loudest voices are resistant to change and try to shut it down. Sometimes everyone is just suffering in silence, or stuck in a feedback loop of escalating poor behavior because everyone is struggling to be heard over everyone else’s attempts to be heard. Sometimes teams are so homogenous that they simply cannot understand that not everyone thinks like them, or – as I once saw – believes it best to simply put the “different people” together so they’ll “be more comfortable.” The “they” is ambiguous there. The “different people” were definitely not more comfortable, so I think it was the team that put them on the island that was seeking comfort.

Another set of problems comes with simply being people in business, which often comes with a huge amount of overthought baggage around roles and responsibilities: Managers and assorted program or project managers or scrum masters aren’t sure who’s really running the meeting, or have conflicting mental maps of who delegated what authority to whom in what team context. If the process czars have been loose in the org, there may be a paralyzing amount of ritual or reporting that tolerates no deviation, no room to breathe, no room to challenge. Team retrospectives may be heavily focused on little process fixes, because those things are easier to talk about than whether the team is fundamentally fair and inclusive in its behavior.

All those things – sour team dynamics and weird corporate hangups about who’s in charge – impede the development of leadership or the growth of leaders because they are all kinds of headwind, or extra gravity to transcend.

Bootstrapping leadership

This is where I am going to return to the topic of management vs. leadership, because I’ve got a dim view of how much leadership there is on the planet at any given time. It’s a rare quality, made all the more rare by the extraordinary period we are living through. Isolation, disconnection, worry, sickness, and trauma are all profoundly flattening, humbling things.

Nothing about being a manager, or a leader, makes you any less human or susceptible to those things. In some ways, they might even go double because leaders are often the ones picking others up and carrying them when they just can’t go on. That isn’t without cost.

So if nobody is stepping up and exhibiting natural, self-motivated leadership – if nobody is doing the needful and leading others toward inclusive practices – something has to happen to begin that cycle. In our case, I’d argue that’s managers.

Why?

Because they have power. Sometimes it is constrained. For instance, managers will often defer to scrum masters or program managers on issues of team practices, or allow the the lead engineer on a small team to drive a lot of the team’s workflows and prioritization. But in our context, and in general, a manager who is not doing something in violation of policy or in a way that is shockingly misaligned with our values has plenty of power and can expect to be heard if there is a problem or even if they just think we need a change.

Further, managers have the most access to real power in the company, meaning the most senior leaders and the people running the administrative apparatus. They are first in line for company news, the first who are engaged with and enlisted to help during a major change, and they have the most privilege. They are, with some checks and balances in place, the arbiters of who gets to progress and who does not. Their word is taken when the question of someone’s promotability is raised.

Despite having this power, there are some missing ingredients:

• Empowerment to drive equitable and inclusive behavior
• Enablement
• Accountability to deliver what they’ve been empowered to drive

In turn:

Empowerment

Some people are great at simply driving change. They don’t spend a lot of time asking around or forming commitees or what have you. They just see what they believe needs to be done and they do it. There’s a tempation to ascribe this to corporate sorting hat “personality type” stuff, but it’s also a function of leadership shifts, changes in company culture, and rising or falling personal stock.

Other people are more retiring, or they’ve been through enough changes (or failed attempts at change) that they’re not so sure this is all going to work. They need some sense that if they implement a change or try something new, they will be supported. It is hard for some people to imagine, but sometimes being the manager is sort of disempowering: Someone on your team has more social juice than you, or enjoys a frequent 1:1 with your boss, or has the team’s ear and sets a tone you find hard to counter.

To drive changes in behavior, managers need to believe that if they push their teams to make important changes, and that if they are working from a menu of best practices, they’ll have support.

How do you give them that?

• You explain the changes you want to see or tell them the things you want them to care about.
• You tell the organization the same thing and set expectations that managers have been told this stuff is important.
• You model the behavior yourself. If a member of the SLT, a VP, or a director can’t be bothered to do this stuff, why would a line manager expect to be supported?
• You insist on measurement to make the point that this matters to you. Set goals, survey sentiment, measure change.

Enablement

People don’t always know how to do this stuff.

More homogenous teams tend to struggle because they have a level of personal comfort that has undermined their curiosity. They feel awkward or afraid that attempts to understand someone they’ve inadvertently othered will provoke conflict, or that they’ll do it wrong and get in trouble.

Anyone I can imagine sharing this with directly will probably have some fluency in the language of microaggression, unconscious bias, and perhaps assorted theories of oppression. Not everyone does. The bar is higher than it used to be, and while that is good – we will collectively stretch to a better and better place – it’s a standard of conduct some people are just now getting around to understanding.

Enablement is about helping people foster inclusive practices by giving them tools – guides, concrete steps to take, ways to measure their success or indicate that they need to iterate once more.

It has been pointed out that not every team is the same. Not every region works the same way. That the challenges for one group may be quite different from another. We have wisely recognized that one size doesn’t fit all, and that it would be a mistake that would keep us from succeeding if we simply dictated a uniform set of behaviors and expected everyone to comply.

• Some teams, for instance, are great at taking turns talking; they just get hung up recognizing every source of ideas.
• Some teams have a round-robin note-taking practice, but they quietly other the women on the team by always pairing them together.
• Some teams are great at mentorship, but the people on the team who call in never get a word in over the people sitting in the conference room.

When teams have a practice that is working, and if that practice is meeting our goals because the team is 100 percent self-reporting feelings of inclusion and equity, they shouldn’t have to stop because that particular practice isn’t in the playbook.

But they’re all going to have blind spots, so they will need tools to diagnose the things we believe are important – what the characteristics are of an inclusive, safe, equitable team – and a set of tools they can use to up their practice until they are hitting all the marks.

Accountability

Finally, managers simply must be held accountable:

• Do they have personal and team goals that reflect the right focus areas?
• Do the practices they’ve identified to improve their team even happen?
• Do they measure?
• Is doing this stuff the difference between “Improving” and “Achieving” on their performance review?
• Do they understand that downtalking “the how” because “they prize delivering over being nice” is not a good look for them?
• Do they understand that “generally high scores” in assorted pulse and engagement surveys don’t mean they’re done and that all of the above still applies to them?

This is the hardest part for any working group in a corporate environment, because lecturing about empowerment and ideating about enablement are not about doing, they’re about talking and thinking. To compel people to do, you have a few sets of conditions that might work:

1. A culture of grassroots, bottom up accountability: Teams holding themselves, their leaders, and their managers to a standard, and undertaking the work of changing their behavior and measuring their improvement.
2. Direction from the top: Senior leadership agreeing and committing to the importance of inclusive behavior as a matter of the health of the company, and making sure that peoples’ incentives so align.

I believe that because of Puppet’s size, the many kinds of management culture you can see throughout the company, the uniquely challenging nature of the times, and a few anecdotes from people who have tried to turn the hybrid-remote crank over the years that while we have people in corners of the company who are setting the right example and doing the right thing, it’s not enough to get us over the top and create a culture of sustained and continuously improving inclusive, equitable behavior.

Initial thoughts on how, a.k.a. tl;dr

Establish managers as the first line of change

We must focus on managers as the people who will drive the changes we need teams to make. They have to be convinced of the need for change, trained in how to deliver it, and established as the ongoing stewards of the improvements we make. They’re the first step in all things.

Define equity and inclusion

What does an equitable and inclusive team look like? How does it behave? What kinds of practices does it embrace, and which does it eschew? How do you measure?

Develop the toolkit

There’s plenty of literature and prior art on hybrid-remote work practices. Any curated list must center their value in fostering inclusivity and equity. There are, for instance, lots of voices in favor of shifting to a written culture – I’m one of them, which makes sense for someone who fed himself with his writing for a decade – but viewed through an equity lens, that’s not always going to work well in teams with power dynamic challenges or different modes of communication.

That doesn’t mean tossing things out because they won’t always work or because they have tradeoffs, but it does mean that any toolkit should note the tradeoffs inherent in each of its constituent parts, and suggest to managers ways to assess their teams.

Set the expectation

We agree there should be no expectation that a given team will use a particular set of practices, but we must expect that every team will center equity and inclusion in its practices, and that there are some constants in what it means to center anything:

• That you’re going to do things that serve equity and inclusion.
• That you’re going to introspect your team periodically using a blend of quantitative measurement and rigorous qualitative assessment.
• You’re going to use that introspection to improve your practices.

Align incentives

Developing, supporting, and iterating on inclusive and equitable practices must be core to every manager’s definition of success.

• They must recognize and support people on their teams who model the behavior, and show that they’ve done so.
• They must be evaluated and rewarded (or not) based on their support and promulgation of these practices, showing their work as part of regular performance reviews.

Measure

Some combination of quantitative and qualitative measurement must be a requirement. The question should not be “percentage completed of a checklist of practices,” because things will descend into parody and “pencil-whipping.” Instead, we should mandate experiments and documentation of the outcomes or team reactions.

We should also develop useful, universal survey questions that help us understand how equitably and fairly people believe they are being treated, specifically in team contexts. One challenge we’ve had in survey language in the past has been malleable or blurry distinctions between leaders, organizational units, “teams,” etc.

Instead, we must be very concrete: Define the team, define “my manager,” define “leaders,” and make sure we are focused on the lower levels of the organization, where people form their impressions of everyday work, and where managers enjoy a great deal of latitude (and hence have the most power to effect change that impacts peoples’ impressions of everyday work.)

We don’t want to build an “ivory tower.”

We want the group to be inclusive, meaning that it involves the right people at the right time for a given problem. 

We want to constrain the size of the standing group.

When we have too many people looking at too broad a collection of problems, we can’t be sure we have the right people for each problem, and we lower the quality of decisions due to lack of engagement and/or context. 

We want to make sure the group can continue to work week-to-week in anyone’s absence.

The group should be able to operate asynchronously, taking homework away, reliably engaging the right people outside the group’s standing meeting cadence. 

We want the group to work in the open, with open access to notes, artifacts, and decisions.

The group should have a Confluence space that allows for use of meeting notes with assigned actions and links to artifacts and pertinent docs. 

We want to ensure that the work put in front of the group is actionable, tied to customer value, and prioritized in a global context.

The group should not be a place to scratch itches or grind axes. Its backlog should be the result of collaboration between the group’s leader (the CTO, Chief Engineer, etc.) and “senior customers,” (e.g. the Product leader, the Engineering leader, etc.) 

We want the group to reflect our diversity goals by giving people from under-represented groups access to technical leadership

Too often, we frame advancement as a progression to management. By making an effort to include under-represented people, the arch group can be a forum for technical mentorship that increases engagement and retention. 

A lot of organizations are settling into a hybrid-remote work cultures, which means that a lot of in-person means of getting things done, making decisions, and communicating ideas are under some strain. Finding ways to allow people to work asynchronously and outside of a lockstep meeting cadence will help with the transition.

A request for comment (RFC) is a way to propose an idea to a group of stakeholders that uses writing and dialog to help get your idea across, expose it to other ideas, and ensure that everybody is aligned and committed by the time the process is over. RFCs can also serve as “case law” for an organization, allowing people to review not only what you did, but why you did it.

You can use RFCs for a number of things:

• proposing a change to existing tools or processes
• proposing a new tool, practice, or process
• getting buy-in on a change to a team’s work

When you write an RFC, you are committing to:

• Seeing the RFC through from beginning to end.
• Making sure you identify the right stakeholders (perhaps by using a DACI.
• Holding others accountable for contributing through comments or proposed changes.
• Holding yourself accountable to hear out all your contributors and make sure their questions or concerns are answered, even if they won’t necessarily agree.
• Communicating the results of the process.

Here’s how, step-by-step, to write an RFC and see it through.

Grab an RFC template

Hashicorp provides an excellent template, or you can use this simpler Markdown version.

Figure out who your stakeholders are with a DACI

“DACI” is a framework for understanding peoples’ roles and responsibilities in a given decision-making situation. It stands for “driver, approver, contributor/consulted, informed.” In short:

• Driver: Who is responsible for making sure this happens or that a decision is made?
• Approver: Who authorized this and/or is responsible for approving it?
• Contributor/Consulted: Who is expected to weigh in or contribute?
• Informed: Who needs to know about this?

It’s important to figure out your DACI, so it’s worth spending some time thinking about it, and even taking time to talk things through with people to understand where they feel they should fit into it. A lot of the hard work of keeping people feeling like they’re included and ultimately aligned involves making sure everyone’s clear on their individual role in the RFC.

Here’s a quick guide to DACI. Some highlights:

• It’s okay to name groups as approvers. Sometimes the next level up in a decision-making situation is a group.
• It’s okay to circulate just the DACI to the people on it for a quick check that it makes sense to them, and that you’ve been as inclusive as needed. Sometimes someone you thought just needed to be informed actually needs to be consulted. Sometimes people are happy just to know what the outcome is and don’t care to consult.
• It’s a good idea, especially for something with cross-functional impact, to ask the approver for a review. They may have context about other departments or stakeholders that can help you craft a better, more inclusive DACI.

Write your RFC

The two templates I linked to include explanatory text for each part of the RFC:

• Summary: One or two sentences
• DACI: See above
• Deadline/timeframe: Make clear when feedback is expected by, and set a date for when all comments and questions will be resolved or closed.
• Background: A few paragraphs to a page that provides links and context to explain why this change or proposal is necessary.
• Proposal: The meat of the RFC. What you want to do and how you want to do it.

Share and set contributor expectations

Once you’ve written your RFC, it’s time to let your stakeholders know about it by sharing it with the approver and the people you’re asking to contribute/consult.

You can choose to share in a couple of ways:

• Everyone all at once. Generally this is the way to go.
• Bringing people in by function or where it will be most useful to them. For instance, it may make sense to bring an initial set of contributors in who can help provide shaping and direction through their early feedback before bringing in people who are better at looking down from 10,000 feet and seeing how the whole thing hangs together once more details are resolved. Just be aware that if there are trust issues or unease about roles/responsibilties, this approach could provoke those tensions.

Either way, each time you share, make sure you communicate a few things:

• What’s the deadline for contributing? Make clear when you’d like to see everyone “pencils down” with their initial contribution. This is meant to be an asynchronous document, so a minimum of a week is best to let people fit time for reflection and commentary into their already busy schedules.
• What’s the deadline for closing out comments and questions? Make clear how long you are going to take to answer questions, resolve comments/concerns, etc. You may need to adjust this. Some groups can pull this off in a day or two, others need more time. Sometimes you realize that something was more complex than you thought and needs more time to work through.
• How can people best contribute? People have a lot of different styles, and Google Docs enables a few different approaches:
  • Comment only: People can ask questions and propose changes as comments, but not change the document.
  • Suggest changes: People can alter the text in “suggest mode,” meaning that the editor or owner has to approve changes. The advantage is that the proposed changes can help shape dialog. The drawback is that a document with a lot of this kind of markup is hard to parse, especially if you’re working in waves.
  • Just make changes: This can quickly take you off course if your RFC is strongly opinionated, but if you’re doing authoring in waves and your first contributors/consultees are key to setting direction before sharing more widely and getting more input, this can work.
• Will there be a meeting? Sometimes you can’t work through everything asynchronously and your contributors will need to show up and talk out things that would take too long or be too complex to fit into comments. If there’s a chance that your RFC will require some face-to-face to truly resolve all questions and concerns, say so.

Gather feedback, monitor your document

Once your contributors are participating, you should spend a few minutes a day answering questions or concerns as best you can. If your contributors identify other stakeholders who were left out of the initial DACI, add them to the DACI if you think that’s appropriate. If you think someone else is better equipped to respond to a comment or question, +name them in the comments to pull them in.

You should remind your contributors of their deadlines mid-way through the process.

Close out comments and questions

Once everyone is pencils down, hopefully on the deadline you set, look for open questions and comments and resolve them. As the driver, this is a point where you may want to work with your approver to review the open items so you can get their support to make decisions on open items.

Part of work life is the simple fact that we sometimes have to disagree and commit. The approver may be useful for sussing out when you can simply close out a line of questioning, reject a proposed change, or make a decision where one needs to be made.

Meeting or not?

At some point during the close-out period, you’ll probably have to decide whether or not to have a meeting. Some questions and concerns are too big to fit in a comment on a doc, or you need people to bring data to inform a decision, or you can just tell that you need to talk it through.

If that’s the case, schedule it as quickly as possible, be clear about what’s in scope for the meeting, and push through. Calendars can be hard, but try to keep your momentum. If someone can’t make a meeting for whatever reason, try to spend a few minutes getting their input or concerns and do your best to advocate for their position or share their information; or see if they can send someone in their stead.

This is another case where pre-aligning with your approver will help you decide how important someone delivering feedback or commentary in person is. They can support your decision to exclude someone, bring in an alternate, etc. especially if, as sometimes happens, there’s an attempt to derail the decision.

Finalize it

It’s a best practice to not consider an RFC “done” until all comments, questions, and suggestions are closed out. At the top of this document, we said RFCs can serve as “case law” for an organization, so it’s important to make sure loose ends are cleaned up.

Some things you may want to include in an outcomes section:

• Where the work the RFC proposed now lives (e.g. JIRA tickets, a strategic intiiative workstream, an OKR)
• Issues you couldn’t resolve, but that aren’t so material you couldn’t decide to table for another RFC.
• Circumstances under which the RFC shouldn’t be applied. For instance, you may be addressing a one-time issue with a solution that won’t work for similar situations.
• Conversely, related circumstances under which the RFC should be applied. Sometimes RFCs result in general principles that apply to similar situations.

The idea here is to do the work of collaborating and thinking through a common problem once, and making that thinking and collaboration available to others in a way that saves them doing that work all over again for this particular situation or things that are similar to it.

Post somewhere

If your organization or team has some a documentation space, post the RFC there, share it with the “informed” parties with a mail pointing to where they can find it, and consider sharing a link in your departmental or organizational Slack if the RFC is of broad interest.

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.

• If you’re a manager in a busy place with a lot of customers or partners, you might have lost track of all the things you’ve committed to. If you don’t have a good practice of recording outcomes and next actions in meetings, you’ll find things creeping around behind your back.

• If you don’t maintain boundaries with customers or partners, it’s going to be an issue for you, too. If you’re the type who’s open to being grabbed in the hall and put up to something on the basis of a nodding agreement, or if you regularly let people outside your team head straight to people who report to you without checking in on the interaction later, you’re not really maintaining boundaries.

• If you and your manager or you and your team don’t have a culture of requiring a conversation about priorities with each new commitment, prioritization will be difficult.

If these patterns look familiar to you, you probably also know some of what comes next:

Your team will start to run hot as they struggle under the load of an undifferentiated (and possibly incomplete) list of their deliverables. That will take the form of stressed-out behavior and guilt over what’s not being done. The folks with a workaholic streak will double down on their effort and become frustrated with people on the team who don’t follow suit. The ones who aren’t going to be pushed into working past reasonable hours will go into a defensive crouch.

Lacking a way to talk about your priorities with customers or partners, it’ll become easier and easier to flip from a posture of relative openness and helpfulness to one where it’s simpler to just say “get back to me in six months” (or never, if you’re being honest).

You’ll begin to focus on headcount as the cure to your problems: You know enough to know you’ve got a ton on your plate, and that your team’s morale is beginning to suffer, and that a few extra hands could at least take some of the pressure off.

Looking back, I don’t think I’ve ever worked anywhere that was doing a great job with prioritization, to the extent “great” would mean you’d be able to get affirmative answers to all these questions:

• Do the managers have a list of everything they’ve committed to?
• Is that list prioritized to at least the level of high/medium/low/not, and is it shared with everyone on the team?
• Do managers periodically reassess the list and clearly identify things that can fall down into the “not a priority” bucket?
• Do people on the team feel empowered to ask about the relative priority of new things as they come in without being made to feel like that’s an insubordinate or unfair/gotcha question?
• Does everyone on the team treat those priorities as real?

Consequently, just about everywhere I’ve worked has shown some of the symptoms of poor prioritization, too. The ones that bother me the most are guilt and recrimination.

Guilt affects peoples’ ability to be open and honest about their work, and it erodes a team’s ability to celebrate what it has accomplished. Guilt also eventually blocks people from being able to ask for what they need from others, because the person feeling the guilt worries that they’ll be viewed as a hypocrite when they have their own impossible list of unfulfilled obligations.

Recrimination – anger turned on teammates for not doing enough – destroys trust, makes it hard to get people to pull together, and creates a toxic environment.

Taken together, guilt and recrimination from poor prioritization will grind a team down.

A Prioritization Exercise

I don’t think I’ve ever felt the challenges around prioritization more acutely than at a startup, where there’s a huge amount of energy, a massive appetite to solve big problems, and a desire to buckle down and become profitable (which means the “toss a few more bodies on the problem” solution to poor prioritization is losing its currency).

After some painful and frustrating conversations around the work my team was doing and the hands we had available to do it, I did an exercise that helped a lot.

The goal of the exercise is to get everything you’ve got going into a list, figure out how important each of those things is to you, describe how much effort you’re putting into it, and then start figuring out what really matters and what needs to come off.

The exercise uses a very simple model that helps you see the gaps between the priorities you think you have, and the work you’re actually doing.

Once you’ve completed the initial steps, you’ll have something that can serve as the foundation of a conversation with your team and your manager, as well as a tool to build an ongoing practice of thinking about what’s important and how what you’re actually doing lines up with that.

There’s no real magic here. The thing that strikes me about this process, however, is that when I describe it to people and show them the tools I use, it strikes a nerve. I think a lot of people are used to carrying their priorities in their heads, or expect their manager or some other leader to let them know what their priorities are (and steer them back when their actions don’t line up with priorities). So I’m writing about it in the hopes that people who are struggling with the stuff they have to do will see something they can use (or modify, or at least get some inspiration from).

This is also written from the perspective of someone managing one or more teams. If you don’t manage anybody, you can still run through this exercise with the projects and tasks you’ve been given.

I’d recommend you do this using a spreadsheet: You’ll want ways to sort the information you gather for the exercise. I wrote an app to help me with it, and I’ll share a little about that in an upcoming entry.

1. Make Your List

If you’ve ever tried to do the Getting Things Done approach to task management, you know that one of the first things you’re supposed to do is get everything out of your head and into a list. That can go a long way to helping you feel less overwhelmed right away.

What goes onto the list is going to vary by the kind of work your team does. Since I manage services organizations, I tend to break the team’s work down into these areas:

• Customer commitments: The teams and projects we’re supporting.
• Professional practices: The actions we layer on top of the basics. For a writing team, for instance, it might involve multi-stage editing. For a team of IT developers, you might want to focus on testing or change management.
• Team maintenance: Things the team does to maintain itself, e.g. professional development, maintaining and developing tools and processes, etc.

You definitely want to include the things you’re doing or have committed to do. You should also include the things you want to do but have no current plans for, and things you’ve recently refused to do.

It might be helpful to add a column listing who on your team is working on what. Who you’ve put on a given task is an implicit comment on its importance to you.

2. Prioritize Your List

Once you’ve got your list, prioritize it. That doesn’t mean you need to force rank everything. Instead, use a simple high/medium/low/not scale. Don’t try to come up with some formula for how much of your list should be at a given priority: That’s overthinking it, and you’re going to address that soon enough, anyhow.

If you’re using a spreadsheet, using numbers for your priorities is a good idea. I’d recommend a 0 = none to 3 = high scale, because you can do math on this a little later on. For instance:

• 0 = No priority at all. You know it’s a thing but you don’t have any plans to do anything about it any time soon.
• 1 = Low priority. This is something that would be nice to have some day, and that isn’t at all necessary now.
• 2 = Medium priority. This is something that requires at least some maintenance on your part as a secondary duty for someone, even if it doesn’t warrant your full attention. If it slips for a little while, it won’t cause too much pain, if any.
• 3 = High priority. You have to actively work on this, either to build it or to maintain it to a high standard.

3. Qualify the Effort You’re Giving Each Priority

Once you have your prioritized list, you should take a look at each item and ask how much effort and attention you’re giving it. I’d recommend, once again, using a 0 = none to 3 = high scale.

There are a few ways to think about this number. Here’s a scale to consider:

• 0 = The item in question is getting no effort at all. Nobody’s paying attention to it.
• 1 = The item is getting very little effort. Someone – maybe not the same person every time – checks in on it now and then, there’s a long backlog of issues with it that are addressed irregularly. Quality may be relatively low.
• 2 = The item is getting some effort. It has a clear owner but it’s not getting their full attention. Quality may be “best effort” as opposed to “high.”
• 3 = The item is getting full effort. The person or people working on it are expected to prioritize it above other things, it consumes a significant portion of their time, and it’s being completed to a high degree of quality.

4. Think About the Disconnect Between Priorities and Effort

At this point, if you’ve got everything in your list prioritized and if you’ve recorded how much effort you’re putting into everything, you can do a little math that will help you think about the health of your priorities list.

You can assess the relative health of everything on your list by looking at the disconnect between your priorities and your actual effort. I call this “risk,” but “health” is fine, too. The main point is that you want to capture how wide the delta is between your stated priorities and the actual work you’re putting toward them.

A quick formula in your spreadsheet will do it:

item priority - item effort = risk

• Risk > 1: High Risk
• Risk == 1: Medium Risk
• Risk <=0 : Low Risk

5. Talk About it With Your Team</h4>

At this point, you probably need to sit down with your team, put the spreadsheet up on the screen, and start talking through the work you’ve done so far.

This conversation is going to require a baseline of trust between you and the people on your team. If you’ve been having problems with poor prioritization, you’ll probably find that there’s a certain amount of guilt and defensiveness. Some people might be worried that you’re doing this work to document blame.

You need to make clear that you’re not using this exercise to place blame or judge people for what they’ve been doing. Rather, if prioritization has been a challenge for you, you need to own your own leadership gaps in this area. Explain that you’re looking for help to get a good picture of everything your team thinks it’s supposed to be doing, and to make sure you understand where relative levels of effort are going.

If you’ve got a few layers of management, you might want to keep this initial conversation to leads or managers, especially if you’re dealing with a demoralized team or one with a poor performer. You don’t want the “effort” question to devolve into one of individual performance. Rather, you want to have a clear idea of how much work is being done around a thing, good or bad.

For that reason, I’ve taken a stab at modeling and then shied away from things that look like story points. They just make people nervous and it slows down the conversation.

Things to ask the team include:

• Is the list complete? Make sure you haven’t missed something, or mistakenly lumped a few things in together in a way that hides effort or complexity.
• Is the amount of effort you recorded accurate? Sometimes you find that someone on the team has been putting a lot more into something than you realized. Alternately, you may discover something has been allowed to slide for months. Note those, move on, and if they represent a performance issue deal with them in a 1:1.

Once you’re done with this, you’ve got a snapshot of the team’s state you can use to drive conversations with your own manager.

6. Take It To Your Manager

Once your team has vetted your snapshot, it’s time to take it to your own manager for review. If you’ve got everything in a spreadsheet and have a little conditional formatting to help make it easier to scan, the conversation can go line-by-line:

• Describe the item in question.
• Explain why it has the priority it does.
• Explain why it’s getting the level of effort it does.
• Point to the calculated risk/health field and ask if it reflects an acceptable outcome for the item in question.

Your manager probably won’t agree with all your priorities, or the amount of work you’re expending on a given item. That’s great! You did all the work up to this point to make it easy to find those disconnects.

The thing you need to do, though, is think in terms of tradeoffs. If your manager wants to bump something up in priority or apply more effort to it, you should press them to explain which items you can back off on to shift capacity accordingly.

As you work through the list and make adjustments, take advantage of the spreadsheet: Sort by different columns to offer a picture of the things with the highest priority, or the things consuming the most time, or that are at most risk because of a disconnect between priorities and effort.

Once you’ve worked through the list, give it a final sort by the risk/health field, and take a hard look at the things you see as high risk/poor health. The questions you and your manager need to be asking at this point are:

• Is this in an acceptable state right now?
• Is there anything happening in the near term that might change this? (e.g. planned hiring that will provide more capacity)
• Is this something we can drop to a lower priority, deprioritize altogether, or actually drop from the list?

7. Take It Back to Your Team

Once you’ve run through the list with your manager, identified misaligned priorities, made adjustments to priorities, and identified a plan to correct misalignments, make sure to close the loop with your team.

For each item that changed, talk about an action plan to make the needed adjustment. That might involve communicating with stakeholders, shifting work around on the team, or simply resolving to quit thinking about something for a while.

The main thing you want to do, though, is communicate a clear sense of permission for each thing that ends up getting less priority or effort. If you’ve been having problems with prioritization and people on the team are dealing with guilt over what they haven’t been able to do, let them know it’s okay to put those things down, that you support them in doing so, and that you’ll defend the team’s priorities and effort to your manager and the rest of the company.

8. Support and Maintain Your Priorities

Once you’ve been through this process, you have to support the work you did.

Review your list periodically: Once a month give it a look and think about each item. Once a quarter, pull your team back in and review. If things change and you need to reassess, bring it back up with your manager.

If you have some sort of progress/status reporting routine, ask everyone on the team to specifically report against the priorities on that list. They might not be doing everything on that list every week, but a section of their report should include things from that list. Work that wasn’t done against any of your priorities needs to show up in its own area because you’ll need to assess whether it was truly a one-off, or something that needs to go onto the list.

Make priorities part of your weekly 1:1s. You don’t want 1:1s to devolve into tactical discussions or 30-minute readouts, but a snapshot of the week’s priorities delivered in the first few minutes keeps everyone thinking in terms of what’s important.

Build a healthy practice of discussing priorities both on your team and with your own manager. If a new piece of work turns up, talk about its relative priority, discuss how much work should go toward it, and add it to the list so you can assess it against everything else you’re working on.

In Practice

For myself, as a manager, the act of getting everything into a list is so clarifying. There are often other sources of truth for the work a team is doing, mostly in JIRA, but they’re seldom as focused.

For the conversations I’ve had with my managers, the exercise gives us a way to interactively discuss our priorities and where the work is going. We often end up finding places where the team has been working to a higher standard than required, and it helps managers give permission to offload some of that work to other teams. Some things come up in priority as a result of that shifted capacity, but that enriches staffing conversations. Sometimes you’ll remind your manager of something they handed off to you and they don’t need any longer.

For the team, it’s helpful to see the results of that discussion. They can see that a constructive conversation is happening about their commitments. It gives you an opportunity to express to them in very clear terms that the snapshot you’ve described is a contract you’ll honor.

I’ve had more senior people say that the hour or so that goes into the initial review of priorities and the ensuing followup are the most useful meetings they can be in, because they finally understand the things they can stop worrying about after years of having them on a mental list.

Services orgs get a lot of incoming tickets telling them what they “should” be doing, and the people filing those tickets aren’t always mindful of the things they’re piling onto someone else’s plate. Having a prioritized list published somewhere that was easy to point to also made it a lot easier to educate people around the company about our work and priorities.

Finally, the exercise has been useful for having headcount conversations both up and down. Once, when I had to consider trading some eventual headcount away in favor of a big overhaul on an aging toolchain, we had a source of truth to turn to. In the absence of a new team member, we had some stuff that was in a state of marginal or poor health that might have to remain that way. Was it worth it? We had a way to validate our hunch that it probably would be, and even a way to see the ways in which some things in the “no time soon” backlog would probably be helped along more by better tools than more people.

Playing with priorities

If you’re interested in trying this approach to prioritization out, you’re welcome to take a look at an app I wrote that makes it possible to record goals and projects, go through the Priority/Support/Effort scoring exercise, and get visual feedback on misalignment of your stated and actual priorities.

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.