Last year, my company ran a hackfest. This year, we are doing it again. The company I work for, 8z Real Estate, is about 20% real software developers, though everyone at the company is familiar with software and technology.
How do we run a successful hackfest when only a few employees can build software?
- Include everyone. It will be a richer, more fun experience with more people. Get executive buy in–I found the original ‘fed ex day’ post helpful in explaining the idea.
- Set goals and expectations. At a typical hackfest (or hackathon), running code is the goal. For us, autonomy and exploration is more important. In the announcement email we state: “the idea is to give everyone a chance to do something work related that they want to do, or try, or explore, but don’t have time to because of the hustle and bustle of work life.”
- Reset deliverable expectations. Rather than running code, the deliverable at a typical hackfest, at an event with many non technical attendees other deliverables should be embraced. Spreadsheets, powerpoints, text documents, mockups, link gallerys, images–these are all artifacts that capture an exploration. They can also be referred to in the future. (I don’t think a presentation without an artifact is a good idea, because of the lack of permanence, although I guess you could videotape it.)
- Encourage developers to work on different teams. Spreading the developer viewpoint and code writing ability across as many groups as possible is a good thing, as it will allow the groups to push their ideas further. That said, if a developer really wants to work on his or her own idea, don’t force them to join a team.
- Make sure contractors feel welcome. Because this isn’t a typical workday, it can be difficult to justify paying contractors to attend. But a hackfest reinforces company culture and can make contractors feel part of the team. We compromise by inviting contractors and paying them a mutually agreed upon reduced hourly rate. If they are technical, this also adds to the pool of developers as well.
- Have the hackfest onsite, preferably in one conference room. Especially for the first one, the hum of people working will be motivating and exciting.
- Have the hackfest happen on one day. Pick one that is slow–for real estate, that means closer to the year end holidays.
- Plan for some ‘normal’ work to be done on the day of the hackfest. We need to provide daily customer support, so on hackfest day we try to compress a full day’s work into a few hours, then shut off the phones.
Then, some general hackfest principles that I believe are true no matter what the attendee’s skillset.
- Start with a timeboxed ideation whiteboard session. This lets everyone see all the great ideas, and find what interests them.
- Use the ideation session to head off any ‘typical work’ tasks that people suggest (‘I just have to verify 4 more bugs on the foobar widget’).
- Let teams self organize, but encourage cross pollination between departments and teams. A hackfest is a great way to build trust between people who don’t normally work together. On the other hand, if someone is very passionate about an idea that no one else cares enough about team up on, let that person pursue their passion.
- Handling managers at a hackfest is a sticky subject. On the one hand, there is benefit to treating them as another employee–they get the benefits of working with different people and ideas. On the other hand, because of their job, they may (unintentionally!) warp the autonomy of the team. Last year, the CEO worked alone, but all the other managers were treated as employees. Discuss this issue, especially with higher level executives, before the day of the hackfest.
- Order in lunch, which keeps the momentum going.
Any tips for a good hackfest, especially one attended by fewer developers than non technical people?