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.

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.

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.