Whether it’s a developer writing code, an accountant assembling a spreadsheet, or a rock climber ascending a route, we all strive to find that moment when we are at one with our task, our “flow state.” These scenarios, experienced individually, can be powerful and rewarding. However, if you can collectively enter a communal form of flow state by working simultaneously with your colleagues, then that’s like lightning in a bottle.
As a manager of a distributed software engineering team based in Boston, I enjoy being able to work with a diverse array of colleagues located in places like Oregon, North Carolina, Puerto Rico, and Dublin. We work together and collaborate regularly through a mixture of Google Hangouts, chat, and GitHub PR’s, but there is value in sometimes getting together to work with each other in person. We’ve seen the team grow significantly over the last year, and many of these new Safarians who have worked together on the same projects have never met face to face.
Last month we decided to try something new. We invited a number of individuals from our Engineering, Infrastructure, and Business Intelligence teams to get together for a week in the new Boston office that we share with O’Reilly Media. We wanted the week to be for special projects, so we threw around some ideas:
“Hackathon!” some suggested. “24 Hour Hackathon!” the more extreme among us chipped in.
Eventually we found a compromise between the two: “How about a 24-Hour Hackathon re-defined as occurring over three 8-hour days!” (We are grownups, after all.)
Instead of using the term “hackathon,” we settled on a new phrase: Build A Thing, a product hackathon spread out over five eight-hour days. In order to make the “things” happen, we started by soliciting project proposals from the product teams. The criteria were as such: the project had enough details to support immediate work (i.e. don’t burn more than a few hours in the beginning debating on what you will build), and the project was achievable in three days. That’s it! We then gave all the participants 100 votes, and let them decide what they wanted to work on.
We specifically set up the project assignments as volunteer based so that people worked only on ideas that interested them. Individuals would see the entire list of projects, and voted for projects that they wanted to build. The “things” were varied and often surprising, ranging from “Invite a friend” to Safari to a Safari radio for us to see what our colleagues were listening to. (Neither of these projects had high votes attached to them.)
Our week was laid out as such:
Day One was set aside to discuss the project proposals and form teams. Days Two, Three, and Four were to focus on building your Thing. Day Five was to demo your Thing. We specifically cleared everyone’s calendar so that they could focus on their projects, and their only meetings on Days Two, Three, and Four, was a one-hour group status update.
Spoiler: it was awesome. In many ways, we reached the communal flow state.
Perhaps most importantly, Build a Thing reminded us how much our developers care about our users. If everyone wanted to volunteer for something that was fun but frivolous, they could have, but excitingly, many of the most sought after projects were ones that had a clear user benefit attached to them
In three short days, every team was able to build something that could be demoed, and we wound up making progress on a number of great, user requested features and ideas that we think all Safari members will appreciate. We will discuss those in more detail in subsequent blog posts, but as a preview, here are a few features that you can expect to see soon:
- User generated ratings and reviews
- Paypal payment support
- Interactive books based on EPUB3
Users of our Safari for Schools platform had the most immediate benefit as the S4S Build A Thing team had a wildly successful time shipping video player upgrades, UI updates, automated O’Reilly Media content uploads, and new searching features.
Beyond the immediate excitement of creating a bunch of exciting new features, we rediscovered a few things about ourselves and our teams in this week.
For one, remote work tends to be highly asynchronous, and it’s been easy for us to forget about the effectiveness of realtime collaboration. Three or four way conversations that span multiple time zones may drag out over days because everyone is having lunch at different times, or ending their days as others are getting started.
But, when you’re all dedicated to one effort at the same time, you can be present for each other. You can draw on whiteboards and ask questions as ideas emerge. A question that may take three days to sort out in a series of message and comment exchanges can be answered in five minutes if all of the right people are present for the conversation. Pairing occurs naturally as people share their work with each other as they’re engaged in their tasks.
I should also point out that one of our most productive teams in Build A Thing was still distributed! A few folks couldn’t make the trip for personal reasons, but they still participated remotely with each other, working intensely over chat, hangouts and screen shares. Being geographically close certainly helps with communication, but getting people working together at the same time can achieve similar results.
Further, by boiling down project goals into something achievable in a short amount of time, everybody can hold a general idea in their head of what has to be done, and who can do it. The need to interrupt work to log tickets for followup tasks goes away. Questions of scope and effort can be boiled down into: what can you finish by today? What can you demo by Day 5?
Once all of our various forms of focus came together, one could see teams entering into a communal flow state where their own collaboration with each other was feeding into their own immersion into the project. It was a fascinating experience and one that we hope to replicate again in the future.
If you’re interested in running your own version of a 3 day, 24 hour hackathon, let us know how it goes or what’s worked for you. From our side, the tl;dr for making something like this effective:
- Protect the time of the participants. Allow people to be focused.
- Keep the teams small. Most of our teams were made up of three people. A few were four.
- Put in all the work up front so that project pitches are compact, actionable, and achievable. Many teams just ran with three paragraphs in a short doc as their mission statement
- Encourage project ideas from everyone in your organization, not just from hackathon participants.
- Schedule one meeting at the end of the day to allow people to show off.
- Have fun and get out of the way for creativity to thrive.