Some co-workers and I were out to lunch with my manager a few months ago, and the concept of 20% time came up. In case you aren’t familiar, the idea is that 20% of employees’ time is allocated for them to work on whatever projects they’d like. The thought behind this is that it will energize the team, promote personal growth, and unleash innovation. In fact, “free time” like this has been responsible for several staples of modern life like Facebook chat and the Post-It Note.
Doing 20, 15, 10, or even 5 percent time would be difficult to implement, but there are alternative methods to accomplish the same thing. And while this was a radical idea for our organization, we decided to move forward and host a team event loosely modeled after Facebook’s hackathons. We called it the code-a-thon.
The Rules
In an effort to make the event sellable to the rest of the organization, we needed to put some structure around the event. This would allow us to give freedom to developers to work on projects that they chose and that they were passionate about and, at the same time, demonstrate the direct business value to the company. Here are the rules that we came up with:
- Projects must be submitted for manager approval prior to the event. I’ll be honest—I wasn’t a fan of this, but I realize its necessity. In order to really capitalize on this and communicate the value of innovation to the rest of the organization, the projects needed to be something related to the business. I hope to eventually remove this restriction in future events.
- Employees can work alone or in teams. We had several meetings leading up to the event to help organize employees into teams. We ended up with 6 teams, each with 2 to 5 team members.
- Teams will be given 48 hours to implement their projects and create presentations.
- Teams will present their projects to a panel of judges.
- Presentations will be strictly limited to 15 minutes.
The Event
We began the event by having all teams meet for a short kickoff with breakfast provided. This gave us a chance to review the rules and parameters of the event and allowed an opportunity for any last-minute questions. After the meeting, the teams separated and were left to their own devices. From that point on, I can only speak about my team’s experience.
My team began by coming up with prioritized milestones for our project. We were using a new 3rd party tool that none of us were very familiar with, so reaching our first milestone was achieved through group R&D and prototyping. By midday, we had something that was functional and ready to be re-implemented into our project. And, by the end of the day, we had reached our second milestone, which was essentially getting our prototyped enhancement functional within the application we were enhancing and having it operational with actual data. All the teams came back together for an end-of-day dinner of Chinese food and pizza—yum!
Day 2 began with our team getting back together and reviewing some additional work that was done after separating for the night. We then got to work on our next milestone, and, once that was reached, we shifted focus to our presentation. As part of the presentation, we made a (crappy) video to help illustrate the motivation behind our project and add some comic relief. The second day ended with us having reached all of our pre-project milestones and having implemented some “2.0” ideas that we didn’t think we’d have time to get to. There was another all-teams dinner, and I was excited to see how many teams showed up late because they were feverishly working their projects to completion. I was also happy to see a number of very-late-night source control promotes.
The third day had just 2 hours reserved for demos. Each team presented for 15 minutes to our panel of judges. I think it’s safe to say that all expectations for the event were exceeded, across the board. The judges were managers from other parts of the organizations, and all of the demos were followed with questions like, “When can we get this?” and “How soon before we can get this to customers?”
The event was a tremendous success, and there’s been a lot of buzz as word has begun to travel to other parts of the company. We’re already planning on having our next code-a-thon in Q1 2013.
What I’d Do Differently
While the event was definitely a huge success, there are some things I wished I’d done differently—mostly from an implementation perspective.
First, I wish I’d done more research upfront. My thought going in was that I shouldn’t do work, because the spirit of the event is to see what I can accomplish from scratch in the allocated time. However, this lead to feeling unprepared, and I didn’t feel like the team had a clear direction or vision for what we were trying to accomplish.
The other thing I’d change is to limit the time to just 24 hours. At the end of day 1, it seemed like most people just sort of called it a day. It was anti-climactic, and I wasn’t feeling the passion. Day 2 was an entirely different story because of the deadline. People were scrambling, working late, and trying to get it all together. That part was great—I loved it. I think having a second day just causes the first day to be a bit lackadaisical.
That’s really all I can come up with for changes I’d make to what went down. It was a productive two days that did a good job of demonstrating that our people are passionate about what they do and have good ideas. Given time and freedom, we can do great things. I’m definitely excited about this new step that we’ve taken, and I’m looking forward to the next one!
adamprescott.net 
Why the 48-hour limit? Deadlines encourage a sense of urgency, but why put people in a situation where they’re expected to work late nights to complete the project on time when there is no customer deadline associated with the project?
And what happens to the prototypes after the demos?
I like the idea of a time limit because of the reasons you pointed out. I want you to work feverishly away at something because you care about it and want to make it as good as you can in the time that you’ve been given. And, like I said in the post, we were modeling this effort after Facebook’s hackathons–where only 24 hours are given–and not necessarily trying to implement 20% time in some sort of quarterly interval.
Aside from that, we wanted to create a fun, competitive event. I don’t think you could have a competition without imposing a time limit.
Regarding the post-event prototypes, we’re still figuring that out. In most (all?) cases, we’re evaluating what effort would remain to cleanup and complete the projects and incorporate them into upcoming release plans.
I think this is a great idea and I think you did a great job executing it. I can see how this would definitely fire up engineers and managers alike.
Thanks, me too! It’s definitely created a buzz around the office.