10 min read

Here are some of the most common questions we hear about MOCHA. Before you dive in, learn more about Clarifying Responsibilities with MOCHA.

FAQs About MOCHA Roles

What is the relationship between manager and owner?

Project owners thrive and grow when they have real responsibility for project success—and it’s the manager’s role to support them. This means trusting owners to fully own the work and setting them up for success.

Typically, the manager and owner of a project should be different people since the manager’s role is to serve as a coach. In most other cases:

  • The owner coordinates the people and logistics to move a project forward. They may not make all the decisions, but they will spot decision points that emerge and involve others appropriately. They have overall responsibility for success and make sure each person knows what’s expected and how to engage (whether they are an M, H, C, or A). They manage up and sideways in the process.
  • The manager’s job is to intentionally transfer the weight of responsibility to the owner and set that person up for success. This means providing support and resources, asking probing questions, giving feedback, and only intervening when there’s a real risk the project is off-track. Depending on the project, they may or may not be the owner’s supervisor. The manager also helps the owner get clear on the comparative advantages that make each helper, consultant, or approver a good fit for their project role.

Use our Delegation Worksheet and Getting Aligned to figure out what information and resources you need to share. See also, Deciding What to Delegate with Comparative Advantage.

What’s the difference between helper and consulted?

Helpers do concrete pieces of work. They are mini-owners on their piece of a project. Consulteds offer opinions and advice at critical moments in the project or need to be kept in the loop. It’s often helpful to use parentheses after names to clarify the type of help or input the person will be asked for. For example: You might clarify Helper: Jamie (outreach) and Consulted: J’Nae (event venues). Then follow up with your team to say, “I (the owner) will finalize details after J’Nae has a chance to weigh in on the pros and cons of possible event venues. From there, Jamie will be leading outreach including X, Y, and Z.”

How many consulteds is too many?

Often a well-intentioned desire to make everyone feel included leads to too many people being looped into a project. Think about emails you’ve received with 20 other people cc’d! This can drain time and resources. Start by asking: who is best positioned to help us get the results we want? Who is most impacted and therefore needs to be consulted or informed? Be strategic and precise about who you’re consulting and what level of input you’re asking for. From there, consider other ways to keep the broader group of people informed, inspired, and excited about a project. For more, see “What about people I just need to inform without consulting?”

Can I assign more than one owner?

Resist the urge to put more than one owner on a project at the same time. You might think that doubling or tripling the number of people looking out for the overall success of a project would increase its chances of success but—more often than not—the overall responsibility gets diffused unless there’s clear role delineation and one clear owner. Instead:

  • Decide which person is best positioned to own the work (plan, coordinate others, keep balls moving, etc.) and clarify how others will contribute as consultant, helper, or approver on concrete pieces of the project.
  • Use a cascading MOCHA to acknowledge helpers who are “owning” big streams of work. Break your project responsibilities down into subcategories. Assign one person to lead the overall project and then identify which helpers own a significant or discrete piece of the work that warrants its own MOCHA. (See Clarifying Responsibilities with MOCHA for a sample).
  • For larger projects, or whenever there is a clear relay in ownership from one phase to the next, create a MOCHA for each phase. Clarify an owner for phase 1 and a different owner for phase 2 of the project. Depending on your project, the owner from phase 1 might stay in the mix as a manager, consulted, or approver for phase 2—or, they might fully pass the baton. Where there is a clear relay, consider having at least one consistent manager or approver in the mix to hold the bigger picture across phases.

Should I use MOCHA if it’s just me and my manager?

MOCHA is a tool for getting role clarity on a project with 3 or more people. Getting clear on the roles of owner and manager is important for any project, but you don’t have to pull out a MOCHA chart for that. Just talk about it.

As a manager, I plan to weigh in and help out. Should I be on the MOCHA as consulted, helper, and manager?

If you’re managing well, you shouldn’t need to be listed as a consulted. Part of delegating is making sure you share any background context, opinions, and resources you have with the owner as part of setting them up for success. As the manager, you’ll consult, spot, give feedback, and ask questions throughout the project. When it comes to helping, it will depend on the project. You might be assigned a helper role when the task is concrete and outside the scope of the manager role (for example, confirming a speaker for an event or being assigned to book the caterer).

Managers should be careful not to jump in and take over a project when something isn’t going smoothly (unless it’s a high-stakes situation, in which case the manager having to step in should prompt reflection afterwards about why that was necessary). For instance, if a manager sees that a fundraising letter isn’t working well, they shouldn’t take over ownership by rewriting it. Rather, they should talk with the owner about the elements that need changing and the owner should do the rewrite.

Can there be multiple approvers?

Yes. When possible, be clear about what each approver is approving. One person might be approving the budget while another approves programming.

If you find yourself with a long list of approvers, ask yourself who really needs to be on that list. Often you’ll realize that some of those people should be consulted, but don’t need to be approvers. If your organization is structured in such a way that multiple approvers are unavoidable, acknowledge that and plan around it. Figure out a plan for how they will get aligned and resolve differences of opinion, so the owner doesn’t have to shuttle back and forth resolving differences. Clarify your team’s decision-making process, which is separate from your MOCHA.

I’ve heard you talk about a cascading MOCHA. Do you have an example?

A cascading MOCHA is like a mini-MOCHA. When a helper needs other people to accomplish a piece of work, they become an owner on this second tier. Here’s an example of a typical MOCHA chart with each person’s contribution clarified in parentheses. In a cascading MOCHA, a helper from tier 1 (in this case, Alex) becomes the owner of a second stream of work. They own everything related to music for the event with their own group of people to consult and help. In this case, the owner of the overall event (Jayden) becomes the manager and approver supporting Alex. You can adapt this for your own context as needed.

Tier 1: MOCHA for Back to School Night
RafaelaJaydenShevy (logistics, special circumstances)

Amalia (PTA chair, outreach and program)
Eric (outreach and registration)

Alex (music)

Cheyenne (program logistics)
Tier 2: Back to School Night—Musical Performance
JaydenAlexShevy (special circumstances)Henry (set up)

Anya (tech and equipment)


FAQs About MOCHA Implementation

How is MOCHA different from role expectations or job responsibilities?

MOCHA is not a job description or a division of labor for your team, which typically outlines more static job roles among a group of people. If you are using MOCHA regularly for your projects, MOCHA language can certainly be a component of your team’s division of labor—and your check-ins (“Hey, would you mind owning that? I’ll help with X and Y.”). The tools complement each other, but we don’t recommend introducing MOCHA at the team level until you’ve tried it on projects. With MOCHA, roles could shift during the course of a project or someone could be owning a project that falls outside their normal job description.

If you notice someone popping up on multiple MOCHAs to help with something outside their job role, it might be an area of work you want to recognize by adding it to their role expectations, so their labor can be recognized.

We have a MOCHA. Now, how do we make decisions?

Your organizational decision-making process will inform how project decisions get made. Your MOCHA will help you clarify who is involved in which areas, but it won’t create a process for decision-making. That’s because MOCHA isn’t a decision-making tool; it’s a project planning tool.

MOCHA works best when everyone is empowered to make decisions about their area of work. The owner ensures everyone knows what they are being asked to do, consult on, or decide—and then makes some or all decisions, either individually or in coordination with their manager/approver. Where your decision-making norms call for consensus, you might name the working group or leadership table as your approver so long as you have a clear process for resolving disagreements so the work doesn’t bottleneck. Where you have a hierarchical decision structure, you might consider which projects could be owned and approved by a more distributed team of staff leaders closest to the work.

Whatever your organizational decision process, we recommend owners clarify modes of decision-making to get everyone on the same page at key points during the project. You can also pair MOCHA with Fair Process as you consider who plays which roles.

How can we use MOCHA in a highly collaborative or consensus-based setting?

We’ve found that MOCHA is especially helpful in highly collaborative settings where groups make decisions through discussion and consensus. In these cases, you can MOCHA specific pieces of work that don’t need full group consensus, or MOCHA the first steps in a project before it needs to come before the full group. For example, a statewide coalition could decide who owns outreach and communications for a policy forum (press release, media list, online registration, social media plan) and who should be a helper or consulted. Then, the coalition (or a subset of the coalition) might be the overall approver. The MOCHA team acts as a working group moving the communications work along, so the statewide coalition can focus its meeting time on other work (e.g., decisions about strategy, policy recommendations, or goal setting).

MOCHA seems hierarchical. Do senior leaders always need to be approvers or managers?

Your MOCHA doesn’t have to reflect the way power is already organized within your organization. For example, on an upcoming fundraiser, your ED might be a helper making confirmation calls to major donors, your most junior staff person can be the event coordinator (owner), and a middle manager who’s hosted several successful fundraising galas could be the best manager and approver for this project.

If all of your projects seem to bottleneck with a single approver or reveal disparities around who’s often helping or consulted without opportunities for greater ownership, pause and reflect. Look for a project where you can interrupt patterns by adding different approvers and breaking projects down in ways that get more people involved and distribute ownership more equitably across your organization.

What about people I just need to inform without consulting?

We often get asked about the difference between the C in MOCHA and the I in DARCI—and it’s true there are differences. When you MOCHA, you may find there are people you need to inform (before, during, or after) a project but not fully consult. Here are two options for keeping folks in the loop:

  1. Twin the C! In the C column, distinguish who you will consult versus who you will communicate with.
  2. Add an “I” to make a MOCHAI. This makes it clear that a co-director, partner, or other stakeholder will be kept in the loop.

In either option, use the parenthesis to get explicit about what information just needs to be shared and when you’ll share it.

Resource Metadata