Keith McFarlane, Chief Architect
We recently held our eleventh LiveOps Hack Day event, and it was something special; a number of really interesting ideas came to life in a mere 24 hours thanks to the efforts of some very passionate and dedicated teams and individuals. A few of the hacks shown at demo time were:
- Pivot to Video – the team involved with this one found a way to move a live agent chat conversation into the world of video using Tokbox.
- Multichannel Visualization – our reporting team presented a new way to look at the overlapping streams of work an agent handles while dealing with multiple work items simultaneously.
- Agent Telephony in-Browser – the engineer showed off integration of our agent phone panel application with Twilio‘s JavaScript-based Client, enabling voice calls using a PC alone.
- Scriptable Callflow – some of our platform engineers found a slick way to control granular telephony functions via REST API.
We have worked to improve Hack Day over the years since we held the first event, and while we have made many incremental changes, we have also identified a set of core principles that can make or break the event depending on how closely they are followed.
1) Great hacks come from the heart, not from the backlog
All too often, I’ve seen engineers or product managers try to use Hack Day as an excuse to accelerate their favorite backlog items. While this certainly accomplishes something useful, it defeats the true purpose of the event: innovation. Developers should use this time to pursue their wildest software dreams and try out new technologies. The same is true for product managers; they should team up with developers to integrate with other web services in unexpected ways, or to make an attempt at defining and implementing an idea that would seem risky under normal circumstances. It should be an opportunity for exploration, not business as usual in a slightly different order.
For developers, picking a backlog item as your hack day project is essentially thumbing your nose at the product management team’s priorities. Think of all of the thought and discussion that has gone into getting the story order right for your scrum, and then imagine ignoring all of that work and selecting stories at random. Clearly the former is preferable to the latter.
Hack Day is about allowing great ideas to emerge from unexpected places. Without emphasis on pursuing new ideas rather than existing ones, it loses most of its value.
2) Focus, focus, focus; scope creep kills hacks dead
While any new idea should be fair game for hack day, I’ve noticed that the greatest successes come from small, focused efforts that aim to complete a minor but valuable feature, or to demonstrate a large concept through a well-defined example that is limited in scope. Often, projects like this can achieve success early, and then add features as time permits. Also, because the victory conditions are well-defined, the team can abandon the hack if it proves too complex, and move their focus to some other idea.
All developers have “big concepts” floating around in their heads; unfortunately, these can be the most difficult to build, even in limited form, as part of Hack Day. If you want to successfully pursue one of these grand schemes in hack form, draw more people into the discussion and find a small piece of the puzzle that stands well on its own, but still gets your point across.
3) Sometimes it takes a village to create a hack
Certain hacks are so clearly defined and limited in scope that a single developer can make them happen on time; however, as complex as most web services are, it is far more common that any truly interesting hack will require the efforts of several subject matter experts across a number of different platforms.
At their heart, hackathons are social events, and they are just as much about teaming and morale as they are about innovation. If you are organizing a Hack Day event, provide a forum for team formation prior to the event itself; we have held a pre-Hack-Day “recruiting” meeting for several years at LiveOps, yielding teaming combinations that might not occur within the normal flow of project work, and fostering greater interactions between teams over the long haul.
4) Deployment is the best reward
Yes, it is important to offer some sort of tangible “best hack” prize, although everyone who wants an iPad probably has one already. However, not every developer has a product idea of their own running as a feature in production; many engineers can work at enabling the visions of product managers for years without their own innovative notions seeing the light of day. If hacks show promise as products, or if they are immediately usable, they should be fast-tracked into production for both the good of the company and as a reward for the engineers involved.
Every software company (not just web startups) should hold regular hackathons to engender innovation, increase motivation, and improve the lines of communication between teams. As with any company activity, however, there are more effective and less effective ways to go about it. Keep track of what works and doesn’t work, make improvements over time, and listen to participant feedback. Although the principles above have worked very well for us at LiveOps, you will more than likely evolve a set of guidelines that work better for your organization over time.
