© Raimond Spekking / CC BY-SA 4.0 (via Wikimedia Commons)

A Case for Hackathons at Work

This isn’t anything Gene Kim and the DORA folks haven’t already stated, but maybe re-plated for better digestion in terms of #workingnotworking.

The point of hackathons is often a tiny bit misconstrued, or at least maybe not fully realized. Giving folks time to work on something neat outside of the norm, self-organize into teams, and have some fun experimenting is obviously cool and defines most of the hackathon experience — but the point is more nuanced than that. It is part of a very important organizational dilemma when you consider the idea of hosting regular, internal hackathons at your organization.

Hackathons belong to the idea that improvement of daily work is actually more important than daily work itself.

They are part of the answer to, “How do we force relentless improvement into the system?” Hackathons, code bounties, blitzes, game days, etc, even disruptive mechanisms like ChaosMonkey/SimianArmy help us solve problems that we are continually working around right now.
When we prioritize around daily work, we perpetuate an environment where there is — even if only perceived — a constant sense of panic around having to deliver (shipping features on time, completing work for other teams, performing emergency maintenance, hotfixes, fighting fires).

The 20% Tax

The first example I’ve read of this is in the book Inspired by Marty Cagan (former vp of product management at eBay, early 2000s) where he talks about (among other things) ways to address technical debt as-you-go, positing that responsible product owners should take 20% of development and operations cycles off the table. They aren’t there for the product owner to spend. They are to be used how dev and ops see fit to fix problematic areas of code/environment, to automate, and improve. Paying this 20% tax is one of the ways to squelch that feeling of panic.

Scrum: because sprinting forever is sustainable.

Until Cagan implemented this policy, eBay hadn’t shipped a major feature for 2 years.

Google most recently championed this idea in their SRE book released last year.

LinkedIn is another famous company that had this problem. 3 days after their IPO, where despite all that was being promised to share holders, their vp of engineering announced a 60 day feature freeze because it had become too dangerous to deploy code.

Things like formal go/no-go meetings, various layers of change or code approval preceding a major release, or 24-hour day-of-release scheduling evidences that your org may actually be treading this path somewhat. Many companies still face a nontrivial amount of fear in deploying a release regardless of how much tech debt has been paid down.

Continuous Improvement

Progress isn’t only made by the typical left-to-right motion through the value stream as initiated by signal of a new feature or customer demand or an event like an outage. In addition to feedback being pushed the opposite way, we have to also inject across the entire workflow — among all the stakeholders and all the teams involved — ways to create practices so that we are continually learning and growing.

Hackathons are one of those ways.
Maybe the concept has a lot of baggage at your org. Perhaps a quarterly hackathon or a fedex day/week comes with too many connotations on some of the feature-heavy teams.

But know that at its core, a hackathon is a simple piece to the critical idea of finding innovative ways to inspire, embed, and reward continuous improvement.

The ability for your org to iterate depends on it.