How to Know When to Walk Away from a Project

This week, I published a post about how the Theme Team at Automattic decided to retire one of our recent experiments:

For the last year and a half, we’ve experimented with a new starter-theme generator called Components. It was a way to make a few different theme “types” comprised of different components. The starter themes born from it brought with them more code and styles, and gave theme authors a bigger head start in their work. The generator we built to piece the different components together got complex quickly, though. We created a plugin to test builds locally and struggled with a seamless way to make many starter themes from one code base.

We learned a lot, though. We worked on Components at two team meetups, made almost 900 commits to the project and launched dozens of themes with it. However, we hit a point where we realized we had over-engineered parts of the project. The original idea is still solid: make starter themes do more by crafting them out of building blocks. But we didn’t hit the mark, so we’re retiring Components, and looking to bring some of what we learned there to Underscores.

We walked away from a project we knew started as an experiment, but still grew attached to after spending hours and hours trying to make it more than just a good idea. How did we know we needed to move on? We all experienced a few key signals:

Not everyone on our team used it. Since my team builds themes, and we made this project to make creating themes easier, it was telling that not everyone used it regularly. Especially after it matured as a product.

We formed silos. Software development can get complex, and not everyone will know everything. But I saw our team gravitate toward specific areas of the project, and it was hard for everyone to fully grasp most of the decisions across the project. This led to less ideas being shared, and perhaps executed on. Meaning the project failed to move as quickly as it could have at times.

The how became more important than the why. As the project grew, more of our discussions revolved around how to solve specific challenges, but din’t come back to the why enough. We got wrapped up in the excitement of building and lost sight of whether we could solve the problems in an easier way.

Your signals may be different. I believe design demands that intentional decisions be made, whether you’re deciding on the font for something, the type of code library to use, or whether to stop working on something. Even though working on Components still feels like a failure for me personally at times, I know it’s not, because we learned so much. And more importantly, made an important design decision to leave one project and carry its knowledge forward.

Photo by Andrew Gook.