At Asana, alongside our Ambassadors program, we ran a program called Certified Pros. It was built for people who consulted on Asana as part of their own businesses, and we put a lot of time and effort into building it out. There wasn’t really another team to run it, and I’d been a consultant myself and had run programs like it before, so in lieu of a true partnerships team at the time, community took it on.
It was a great program, and the members in it really loved it. It also wasn’t really community in nature. As the company grew, a few of my teammates and I decided it would be better served by the partnerships team, so we wound it down on the community side and transferred it over. It was a difficult decision, and the logistics were difficult too (moving a program people love is a bit like moving apartments while everyone’s still sitting on the couch). It was also the right thing to do.
How programs pile up
That’s a pretty common way for a program to land on a community team. When something needs doing and no one else is around to do it, community often ends up with the pieces other teams can’t or won’t take on. Add the programs a team starts on its own, and the list grows quickly:
An event goes well, so it becomes a monthly event.
A stakeholder asks for a webinar series, an advisory board or a local chapter program.
A program gets inherited because it had nowhere else to go.
Each one makes sense when it starts, and eventually the team is running a portfolio that was never designed as one (a bit like the kitchen drawer where everything in it was useful once).
Starting something is visible, with a launch, an announcement and someone’s name on it. Ending something has none of that, and I’ve yet to see anyone put “wound down the Thursday webinar series” in a quarterly review with a confetti emoji. So in my experience, the decision to keep a program is rarely made out loud. It gets made by default, every quarter the program doesn’t come up.
Where the team’s time goes
Most community teams are one or two people, so every recurring program is a real slice of somebody’s week. That’s fine while the program is doing its job, and a problem when it’s keeping the team from something members need more. Maybe newer members are struggling to find their footing while the team spends a week every month on an event that mostly draws the same thirty regulars. More headcount sometimes helps, but sometimes it just means you get to keep running everything, including the parts that should have ended.
Good reasons, and reasons that only feel good
When I’m deciding whether a program should keep going, these are the questions I ask:
Does it still have a clear job, for members and for the business?
Is something else already doing that job?
Can the team actually run it well with the time it has?
Has the need moved on, or would it be better served somewhere else in the company?
That last one is what happened with Certified Pros. The program still mattered to the people in it, and it made more sense with a team built for partners.
The reasons that keep programs alive anyway are a different list: someone senior likes it, it’s always been there, or ending it would mean an awkward conversation. I get all three (I’m not a big fan of awkward conversations either), but none of them says anything about whether members are getting something out of it. I’d add one caution going the other way, too. Small isn’t the same as failing, and a program for a handful of people can matter a lot if they’re the right handful.
How to end one well
Rolling things back is risky, because you never really know how a change is going to land, and the people who loved the thing you’re ending are usually the ones who care most. If you don’t share the reason for a decision, members will come up with one of their own, which in my experience is rarely the flattering version. A good wind-down note covers a few things:
What’s ending, and when.
Why, in plain language.
What takes its place, or where the program is going.
Thanks to the hosts, speakers, volunteers and members who made it work.
A heads-up before anything changes goes a long way, too. And ending a program on purpose can be a sign things went well. The version I’d worry about is the one that slowly fades because the call never got made, which leaves members wondering what happened and the team wondering whether it ever worked.
Making stopping normal
The teams I’ve seen handle this best treat stopping as one of several regular options, alongside keeping, improving, scaling, consolidating and pausing. Two habits help a lot: give every new program a review date at launch, and ask “would we launch this today?” about each program, out loud, with the team.
I’m putting together a tool for doing this across a whole set of programs. In the meantime, I’m curious which program on your list would be the hardest to stop, and what makes it so hard!
Try this
Pick the one program you’d be least likely to launch if you were starting from scratch today. Write down, in a sentence each, what it’s for, who it serves and how many hours a month it takes your team. If the first two are hard to write, it’s worth putting on the agenda for your next planning conversation. And if you’re worried about cutting the only option some members use, I wrote about that in Why One Community Format Will Never Reach Everyone.
Decoded Takeaways
Community programs pile up. Some start because an event went well, some because a stakeholder asked, and some land on the community team because no other team was there to take them. Over time the team runs a set of programs that was never designed as a set, and keeping each one becomes a default rather than a decision.
Because most community teams are tiny, every recurring program uses real capacity. The useful questions are whether a program still has a clear job, whether something else already does that job, whether the team can run it well, and whether it would be better served elsewhere in the company. A stakeholder’s fondness, tradition and the discomfort of an awkward conversation aren’t reasons to keep something, and small programs deserve care, since a small audience can be the right one.
How a program ends matters. Explaining why, giving notice, saying what replaces it or where it’s going, and thanking the people who made it work protect trust. A review date at launch and a regular “would we launch this today?” make stopping a normal option.