This post is part of a series contributed by MJ Bear Fellows, journalists under 30 who are driving innovation in digital news.
Winners never quit. Giving up is easy. Once you learn to quit it becomes a habit.
There’s a lot of conventional wisdom out there about quitting — namely, that you shouldn’t do it. As someone who has quit a lot of things over the course of my life, from ballet to a bad job, I’ve always wondered why it is viewed so badly.
That’s why I was surprised when, in the middle of an MJ Bear Fellows session on entrepreneurship, Rebekah Monson, co-founder and COO of WhereBy.Us, made a comment about not being afraid of quitting projects that aren’t working.
I recently chatted with Rebekah to find out more about what she meant and to answer the question “When do you know it is time to quit a project?”
Here’s our conversation, condensed for clarity.
Could you elaborate on what you meant about not being afraid to quit?
Evaluating when to quit is essential if you want to get things done. Starting a startup led me to step away from a whole lot of other community commitments that I used to derive a lot of joy from. I don’t run the Code for America Brigade or Hacks/Hackers, because I don’t have bandwidth to do it anymore.
I struggle with evaluating whether what I’m doing at a given moment is benefitting what I want to accomplish. When you’re managing a team, this becomes really hard to account for, particularly if you have a high-functioning team. They’re naturally going to do more. There are 15 million ways we could hit our company goals, that we could grow our newsletter subscriber base, that we could make more money. What we have to do is pick one or two things and run at just those. That means always leaving ideas on the table, which can be difficult to learn how to manage.
When you start projects, do you set yourself up for a better way to quit them? How?
One strategy is setting an expectation from the outset about how long you’ll run a project. “We’ll try this for two weeks, and then we’ll evaluate, and this is what we’ll look at to see if it worked.”
You should also consider sustainability. Are you building something now that’s going to leave someone with an impossible job when you walk away from it?
Within a year of launching Code for Miami, my co-founder Ernie Hsiung and I started thinking about who the next layer of leadership might be. We weren’t planning to leave then, but we wanted it to last beyond us. Now, I haven’t been to a Code for Miami meeting in about a year, but they’re still running and there’s a leadership team in place. That’s a management lesson.
For journalism projects, what you want to build is knowledge and a repeatable framework to carry something on or to kill it if it is not working. Sometimes we have things that are semi-successful — they didn’t hit all the goals, but we saw some progress. Then the questions become “Should we scale this project back? How do we gracefully do that?”
News organizations have a difficult time with this piece. You set up user expectation every time you launch something. Part of knowing when to quit is embracing the beta, being upfront with your users about the fact you’re trying it for a little while and you hope it works. And it isn’t just system and process. When something ends, have empathy for the people who are missing it. Make sure their needs are met somewhere else or that you have an alternative. Let them know: “Hey, we thought this was cool, too, but it didn’t work out and we can’t support it. But we’re grateful for the time you spent with it.”
What factors do you consider as you weigh whether to quit a project?
For starters: Is this a unique value that we offer or that I offer? Are we the only ones doing it? Are we doing it best? The projects where you can answer “yes” to these questions are the core of what you’re doing, and you don’t want to let that go.
In news, a lot of our habits are built on the idea that in order to best, we have to be first. If everyone is watching the same press conference, does it matter if your story goes up later than another news outlet? Where’s your unique value? How might you double down on that? Where can you cut to be able to do this thing that is unique?
What about the mental load of quitting a project?
It is really popular startup rhetoric to say “fail fast.” That’s nice jargon-y stuff. But it’s more useful for a team to ask, “What did we learn from this?”
Even if a project didn’t fully work, you almost always can find something critical to the organization that you learned from the effort. Building on what you learned is a challenge, but that’s the special sauce. That’s the way you keep people trying things that are painful to try.
Are there any circumstances that you can think of where it is worthwhile to quit a project when you think it is successful?
There are a lot of things in your career that you’ll have to step away from because, even though they are successful, they aren’t successful enough, or it’s not successful in the right places. You may have an initiative that is super successful in engagement, but you can’t tie it to a revenue hypothesis.
We’re making value judgments all the time about what we want to be good at and whether a project would get us there. If you’re not taking the time at the outset to determine what your hypothesis is, it is hard to make that judgment later.
What are examples of personal projects or times from your professional life you’ve had to quit?
When we started The New Tropic in 2015, we were trying a lot of things, doing a lot of “spaghetti throwing.” One of our initial hypotheses was that we needed to have physical space to build community engagement. We held a boatload of events for six months and in the process learned that events are great for building community, but they are also super expensive to produce. Also, hosting them in our office wasn’t ideal. It was destructive to the workday. We stepped away from that. We started out trying to be the convener, and we realized we’re a better partner most of the time.
What are the best practices for communicating that you’re quitting a project?
Campsite rule: You want to leave the place better than you found it.
You want to acknowledge people’s concerns, but not wallow in self-pity.
I’m not a big fan of ghosting on your users. There’s always a good case for being upfront.
You might say, “Hey, we tried this, it didn’t really work out, but we’re going to work on things that will work better in the future.” Or, “Here’s an alternative elsewhere that is better.” As we think about building better ecosystems for local news, we have to be less afraid to point people in the direction of the thing they want.
What are some reasons for absolutely not quitting a project?
The projects that reflect your unique value, your highest and best use, those are the things you’re not going to be asking whether or not to drop.
If you’re evaluating whether or not to quit a project, that project is already not on your priority list. My guess is if you’re thinking about quitting it, it is not something purposefully aligned with the goals you’re looking to accomplish. It doesn’t mean you kill it outright necessarily, it just means it is time to evaluate. But if you’re keeping a lot of things half-working alive, you’re not giving yourself the opportunity to provide your highest and best use to the goal you’re trying to get.
Any final thoughts?
The big thing is to remember that when you’re quitting something, you’re quitting to add value elsewhere. Prioritize how you document your learning and share what you learn with others. The idea of failing fast is nice, but if you’re not learning from the failures, it is just an exercise in pain.