A Title Means Nothing Until It's Attached to a Permission

"Can you help me run this?" is usually the entire negotiation. Nobody lists what help will mean, which is fine right up until the first moment help is actually needed - a member to remove, an event to cancel at eleven at night, a question to answer while the organiser is on a plane. That is when a title either means something or doesn't.

Quick answer

A co-organizer who cannot cancel an event is not a co-organizer. They are a person with a word attached to their name and none of the access that word implied.

Meetup's own documentation splits leadership into two real tiers: a Co-Organizer can manage group settings and change the leadership team, while an Assistant Organizer can run members and events but not reshape the group. Neither holds financial control.

The lower tier is almost always the right first move - it grants everything needed to genuinely help, without handing over the parts that are hardest to walk back if the partnership does not work.

The word arrives before the ability does

The moment a group outgrows one person is usually obvious in retrospect and invisible at the time. Somebody keeps arriving early to help set up. Somebody answers questions in the group that you would have answered. The natural response is to give them a title, and the natural mistake is to stop there.

A title is a social object. It communicates standing to the rest of the group and gratitude to the person receiving it. What it does not do, on its own, is change what that person is able to do at eleven at night when the venue cancels.

So the group ends up with two organisers on paper and one in practice, and the second one discovers this at exactly the wrong moment - usually while messaging the first one to ask them to press a button.

If your co-organizer has to text you to get something done, you do not have a co-organizer. You have a well-informed member.

What the permissions actually are

It is worth reading a real permission model closely, even if your group runs somewhere else, because the line it draws is the same line every group eventually has to draw for itself.

Meetup's documentation on managing a leadership team describes two roles. A Co-Organizer holds nearly everything the Organizer does: they can add, change and remove other leadership members, manage group settings, accept, remove and ban members, view attendance history, contact members, and schedule, edit and cancel events. What is withheld is financial and subscription control.

An Assistant Organizer sits one level down. They can still accept, remove and ban members, view attendance history, contact members, and schedule, edit and cancel events - genuine, meaningful authority - but they cannot touch group settings or change who else holds a leadership role.

Can do - Co-Organizer - Assistant Organizer

Accept, remove or ban members - Yes - Yes

Schedule, edit or cancel events - Yes - Yes

View attendance history - Yes - Yes

Contact members - Yes - Yes

Manage group settings - Yes - No

Add or remove other leadership members - Yes - No

Financial / subscription control - No - No

Look at what the two tiers share rather than what separates them. Both can run a single event end to end: accept people in, communicate with them, and cancel if something goes wrong. That is the whole of what "help me run this" needs to mean operationally.

Everything above that line is about who gets to shape the group itself - its settings, its leadership. That is a genuinely different decision, made on a different basis, and collapsing the two is what produces most co-organizer trouble.

Why the lower tier first is not a lack of trust

Handing someone full settings access and the power to add or remove other leaders on day one, before they have run a single event, is more authority than the moment calls for. Not because they are untrustworthy - because nobody, including them, yet knows how they will handle the actual job.

The distinction matters because organisers often experience the staged approach as an insult they are reluctant to deliver. It is not. Enthusiasm at event zero and follow-through at event five are different qualities, and there is no way to observe the second one in advance.

There is also an asymmetry worth naming plainly. Promoting someone after they have proven the smaller role is a pleasant conversation. Walking authority back once it has been given is one of the worst conversations in community organising, and it is the one the staged approach exists to avoid.

Promoting someone is a good conversation. Demoting them is a terrible one. Sequence accordingly.

What actually breaks a co-organizer relationship

It is rarely a bad person in the role. It is an undefined one.

Two organisers who never explicitly divided event-day logistics from member communication from long-term direction end up both doing some of everything, unevenly, with neither quite sure what the other has already handled. Two people both message the venue. Nobody messages the speaker. A member gets two different answers to the same question.

The instinct is to describe this as a communication problem and to fix it with more communication. That rarely works, because the underlying issue is not that information failed to travel - it is that no decision had an owner, so every decision required a conversation.

Domain - Owned by one person - Requires both

Event logistics: venue, timing, setup - Yes - one named owner - No

Member questions and communication - Yes - one named owner - No

Removing or banning a member - Either can act - Notify the other afterwards

Cancelling an event - Either can act - Notify the other afterwards

Changing group settings or direction - No - Yes

Adding another leadership member - No - Yes

The middle rows are the interesting ones. Both organisers can act alone, and the requirement is notification rather than permission - because an event that needs cancelling at eleven at night cannot wait for a quorum, and a group where it can is a group with one real organiser again.

The conversation to have on day one

It takes about twenty minutes and it is uncomfortable in the way that all useful early conversations are. The alternative is having a much longer version of it during an actual disagreement.

• Divide the two or three recurring domains explicitly. Logistics, communication, programme. Each gets one name, not two.
• Name the decisions either person can make alone. Cancelling, removing a disruptive member, answering a member question. These need speed more than they need consensus.
• Name the decisions that need both. Direction, settings, adding a third organiser, anything that changes what the group is.
• Agree what happens if this doesn't work out. Not because you expect it to fail - because deciding it now is trivial and deciding it later is not.
• Set a point to revisit. Three events, or three months. A staged role with no review date is just a permanent demotion with extra steps.

The fourth item is the one people skip and the one that pays for the whole conversation. "If either of us wants to step back, the other keeps the group and we say so publicly" takes ten seconds to agree in advance and can take months to resolve in retrospect.

How many organisers a group actually needs

There is no ratio, and anybody offering one is guessing. What can be said is which variables drive it.

Frequency drives it more than size. A monthly group of thirty often runs comfortably on one organiser plus occasional help, because the workload arrives in a predictable monthly lump. A weekly group of the same size needs a real team, because there is no recovery window between events.

The other driver is single points of failure. A group where only one person can unlock the venue, only one person has the speaker's phone number, and only one person can cancel the event is a group that is one illness away from a bad evening - regardless of how many people hold titles.

• Count the things exactly one person can do. Venue access, platform permissions, payment methods, speaker relationships. That list is your real fragility.
• Count the things that happen every single event. If one person owns more than about three of them, the group is already understaffed regardless of headcount.
• Check whether anyone else could run next month alone. If not, the leadership team is decorative.

When a co-organizer stops being active

This happens constantly and is handled badly almost universally, because there is no clean vocabulary for it. Someone with a title stops showing up, and the group ends up in an awkward state where authority is held by a person who is not exercising it.

The reason this matters practically rather than socially: a dormant co-organizer with full permissions is a permission the group cannot use and cannot easily reclaim, and in the Meetup model that includes the ability to change the leadership team itself.

The graceful version is to build the exit into the entrance. A role with a review point has a natural moment to say "is this still working for you?", and the answer "not really, life got busy" becomes an ordinary administrative update rather than a personal rejection.

Three questions before you hand someone a title

• Could they cancel Thursday's event tonight, without texting you first? If not, they have the word and not the access.
• Do they know which decisions are theirs alone? Two people making unilateral calls on the same decision is a worse system than one person making all of them.
• What happens to their access if this doesn't work out? Deciding it now costs ten seconds. Deciding it during a disagreement costs considerably more.

What to take from this

Stop treating "co-organizer" as a thank-you. It is an access grant, and access grants have to be specific to function: which member decisions someone can make alone, which event-day calls are theirs, and what happens to all of it if the arrangement ends.

Give real permission before you give the larger title. Let it prove itself across an event or two. Then hand over the parts of the group that are hardest to walk back - its settings, its leadership - to someone who has already shown you what they do with the parts that are not.

Frequently asked questions

When should I bring on a first co-organizer?

Once the same person keeps helping without being asked, or once logistics take more of your time than the group's actual purpose. Both mean the workload has already outgrown one person.

What is the difference between a co-organizer and an assistant organizer?

In Meetup's model, both can accept, remove and ban members, view attendance history, contact members and schedule, edit or cancel events. Only a Co-Organizer can manage group settings and change the leadership team; neither has financial control.

Should a new co-organizer start with full access?

Usually not. The lower tier grants everything needed to genuinely help while withholding the parts that are hardest to reverse, and promoting someone later is a far easier conversation than walking authority back.

What if my co-organizer and I disagree?

It is much easier if you decided in advance which decisions belong to which of you. Disagreements are manageable when scope is settled and difficult when scope is being negotiated for the first time mid-dispute.

How many organisers does a group need?

Frequency matters more than size. A monthly group of thirty often runs on one person plus help; a weekly group of the same size needs a real team because there is no recovery window between events.

What should either organiser be able to do alone?

Anything that is time-critical: cancelling an event, removing a disruptive member, answering a member question. These need speed more than consensus, with notification afterwards rather than permission beforehand.

What happens if a co-organizer goes inactive?

It becomes a permission the group cannot use and cannot easily reclaim. Building a review point into the role at the start gives a natural, non-personal moment to change it.

Should the decision to add a third organiser require both existing ones?

Yes. Anything that changes what the group is - its settings, its direction, its leadership - belongs in the category that needs agreement rather than the category either person can act on alone.

Ontaym Editorial Team

Ontaym builds tools for organising real-world gatherings, so the team spends its days on the coordination problems this article describes. Articles are researched against primary sources, reviewed before publication, and revised when the underlying facts change rather than on a schedule.

Give your co-organiser real access, not just a title.