This post originally appeared on the Society of Grownups Blog.

Grownup web developer Michael Pelletier shares how our recent company Hackathon came together-and its impressive results.

One of the best things about working at Society of Grownups, and one of the things that I think a lot of us view as making us successful, is the idea that we are all able to champion the company. Ideas for how we should best move forward don’t just come from the top down, they come from all around. From above, from below, from the sides.

For the Development Team, we had a long-standing idea to do a Hackathon: Two days, uninterrupted, to intensely write as much as we could to try and bring something to life.

As a team, we established the Hackathon parameters. We decided it should have a loose theme: Rather than just sitting down and programming anything, we wanted whatever resulted from the Hackathon to be something that we felt the company needed, or could use. It could be anything from writing an internal tool, to prototyping a proposed new feature, to introducing functionality to our existing website that we felt was missing. As long as it was something that strengthened the company. With the blessing of our CEO, we were ready to go.

Scheduling (…and Rescheduling)

We knew it was important to set a date, because with a side project like this, it’s very easy for it to just be pushed back. “We have to do x this week”, or “no, we can’t do that day because of y”. We simply said “Last week of October, the Monday-Tuesday, let’s just do it.”

When speaking to the rest of the company about it, we kept our cards pretty close to our chest. With about three weeks’ notice, we told them we’d be doing a Hackathon, and that if there weren’t any emergencies, to please not schedule any meetings with any of us for those two days. And we didn’t give them any kind of indication as to what the projects might be, as we didn’t want any influence, requests, or distractions (besides emergencies, of course). And perhaps most importantly, we wanted the results to be a surprise.

The thing is, though, once there is a date on the calendar, things change from “This will maybe happen someday” to “oh, we’re actually doing this.” Because of the nature of taking time off from what we were actually expected to be doing, it was imperative that we were up to date on all of our projects, and that no one would be relying on us for those days. And unfortunately, a few days beforehand, other business needs took priority. So, we slightly changed course and adapted: We rescheduled it for another two weeks out, informing everyone of the date change. That one we were able to keep.

  • TThe Engineering Team in front of the Society of Grownups mural.

Process

We had cleared the Hackathon with the rest of the company, set a date, accumulated more than 20 ideas to be worked on, and we were ready to go. Given that the plan was to start on Monday, and we wanted to be able to hit the ground running, we set aside some time to plan on the Friday before: We’d figure out which project ideas we actually were going to work on, and also ensure we had everything we needed, as far as setting up our environments and determining who would be working together.

With 10 people participating, we settled on getting as far as we could with seven different ideas. These ranged from creating internal tools to make it easier to generate QA accounts for our test environments, to prototyping a simple mobile app for user registration, to writing an official Style Guide for our CSS and HTML. Our Director of Engineering, Dan Luria, even offered to run a three hour “Intro to Javascript” class for anyone in the company who was interested. A couple people on our QA team and even some of the Designers signed up, and interest spread to others, too, such that classes are now going to be a recurring thing.

I had expected the Hackathon to be a success insofar as we would end up with some exciting projects, but two things really surprised me, showing benefits that I hadn’t at all anticipated.

The first is that we had people working together who typically didn’t. The bulk of the Dev Team has been here for roughly seven to nine months, and in that time we’ve had a lot of sprawling projects, which has meant that many people haven’t gotten to work with each other. With the Hackathon, that changed, and it was incredibly moving to see people collaborating on something simply because they were excited about it.

The second is that people were working on things that they typically didn’t. For some people, this was features, like our internal tools rather than the public-facing website. And for others, it was entirely different programming languages.

Measure of Success

At the end of the Hackathon, we had projects in various stages of completion, and we all felt like we had truly accomplished something. On the Thursday following, many of us sat down together and demoed our projects to each other, talking through what we had created, the decisions we had made, and results. The following week, we all got up during a larger company meeting and presented what we had done to the staff as a whole.

Remembering that no one had much of an idea of what we would be working on, there was more than a little bit of excitement and shock. If they weren’t on board for a Hackathon before the presentation, they won’t need any convincing the next time we plan one.

Obviously, taking two days off from the status quo can be hard for a business to swallow. When there are deadlines to be met and a large backlog to keep up with, losing the entire team for two days can feel like it’s impossible to manage.

And with full transparency, our first foray into this type of project was not without problems. We’re in the middle of some large rewrites and it was difficult at times to work around that. We also didn’t gauge very well the scope of some of the projects. Some were on the shorter size (a day’s work) while others we could easily have spent a week on. It was a learning experience, and I’m confident that the next Hackathon will go smoother.

We are still trying to find the sweet spot for how often to do this kind of thing. While once a month feels far too frequent, I think we will probably settle on once every quarter, or at least twice per year. While there is certainly a tradeoff, the benefits of creativity, empowerment, team-building, and learning are just far too hard to ignore.

With having more people joining the company all the time, I’m hopeful that doing this semi-frequently will be something that our new faces see and find encouraging. It’s one thing to say “yes, we believe people should pose new ideas”, and another thing to be the kind of company that actually allows people to make time to explore those ideas. I’m incredibly excited to be working for the latter, and cannot wait to be able to share some of the things we’ve already built.