Maintainathons and hackathons

by Adam Marcus

The thrill of creating something new is both personally fulfilling and valuable to companies. It's why you see so many organizations embrace hackathons: given some unrestricted time and the mandate to create something from scratch, people tend to generate some really inspiring stuff. About once a quarter, B12 runs a 2-day hackathon with only rough instructions to do something great for our customers or experts, and the reminder that no one can tell you what to do. We've run hackathons since we started B12, and they have resulted in everything from our signup flow to our website editor to early prototypes of AI Assist. But for all of our love of hackathons, they left us with a question: all this focus on innovation is great, but how might we apply that same focus to improving what we've already created? Our answer is maintainathons, and after a year of running them, we're excited to share how they work.

The basic structure of our hackathons and maintainathons is the same: for two days, no one can tell you what to do, and your focus should be on improving the experience of our customers, experts, or fellow B12ers. Some details include:

• The Monday before the event, we have a 30-minute session where participants can share ideas they are considering and where they might need help. We welcome ideas from anyone, so a salesperson or customer success team member can provide an idea even if they aren't hacking.
• The two days of hacking happen on the Thursday and Friday of that same week, when we cancel all meetings. These aren't all-nighters: people work regular days and hang out with family and friends afterward as they would on any other day. (We schedule the Monday brainstorm a few days before the Thursday start of the event because we are geographically distributed and team members need time to coordinate across time zones.)
• We schedule optional collaborative unblocking sessions each day where anyone can join to either get help or help someone else out.
• We schedule at least one social/game hangout during the event for the team to blow off steam and share their ideas and progress.
• At the end of the hackathon/maintainathon, each project team gets a few minutes to demo their work, with a bias that awards collaboration: 1-person projects get 4 minutes to demo, 2-person projects get 5, 3-person projects get 6, etc.
• There are no prizes or voting or anything like that: we just enjoy the freedom, the flow state, and each others' great work.

For all their similarities, the only material difference between hackathons and maintainathons is the input to the Monday idea-sharing session:

• For hackathons, we have a brainstorming spreadsheet that starts with a blank slate. Participants can list an idea and what sorts of collaborators they might benefit from (e.g., "This project could benefit from teaming up with a designer"). There's a column to add your name in case you're interested. In the meeting, we go around sharing ideas we're most likely to work on and ask for collaborators.
• For maintainathons, we replace the empty hackathon spreadsheet with several pre-filled lists of ideas collected from user feedback, our error monitoring tool, technical debt, packages that need updating, infrastructure quirks, and documentation that's lacking. The brainstorming meeting consists of people sharing support for already listed ideas (as well as new and unlisted ones) based on the pain they felt themselves or observed a user experience.

While we've run hackathons since we started B12, we only introduced maintainathons a year ago. In that time, we've observed several key differences between the two:

• Team sizes. Hackathon projects tend to focus on an ambitious too-hard-to-solve-alone problem, and it's easy to rally a team of 2-3 collaborators who want to solve that problem. With maintainathons, a list of achievable-but-not-yet-addressed issues results in lots of advocates working solo or with one other person to solve those issues.
• Cross-company participation. While participation is optional and every team is invited, our entire product team tends to participate in hackathons, with scant appearances from other teams in the company. Maintainathons tend to see participation beyond the product team, with marketers and customer success team members rallying to update messaging sequences, improve documentation, or iterate on an outreach strategy.
• Project outcomes. A hackathon presentation usually features an impressive demo followed by a checklist of tasks it would take to ship to production, usually requiring 1-2 weeks of additional work we might prioritize in a future quarter. Teams sometimes even address a single project across multiple hackathons. In contrast, it's not unheard of for a maintainathon participant to ship 3-4 improvements to production on their own during the course of the event.

We've enjoyed alternating between hackathons and maintainathons for the past year, and intend to keep running both. Both types of event ultimately benefit from and tap into the intangible delight our team experiences from self-motivated and self-directed work. Introducing both has allowed our team to use that energy to tackle everything from the simplest bug to the most ambitious project. We're excited to hear from other organizations that try out the maintainathon concept, so let us know if you experiment with maintainathons or something similar!

Thank you to Aditya Bharadwaj, Meredith Blumenstock, and Daniel Haas for helping introduce maintainathons, and to Katelyn Gray, Daniel, and Meredith for reading and editing an early draft of this post.