The Hackathon That Never Happened

This is a story about having very good intentions, and watching them grow into something too big to happen.

The idea

On my industrial placement at Elanco (Building a Web Platform for 80 Sites) I wanted to build more of a developer community and a culture of sharing knowledge. I was given room to make that happen, and our CTO was happy for me to take the reins.

The first thing I wanted to run was a hackathon in the spirit of Hacktoberfest, the month-long open-source event every October that I’d taken part in for years before. The plan was deliberately small: a handful of developers, in October, building and contributing together. I was ready to plan it out.

How it grew

It was suggested I get some help from a couple of more senior technical colleagues, which I welcomed. They were genuinely excited, and their enthusiasm took the idea somewhere bigger: make it inclusive to every business area and function, a whole-office, organisation-wide event.

Every part of that suggestion was well meant. But it completely changed what we were doing. A small developer event needed almost nothing from anyone. An org-wide event needed:

• a value proposition, and a story for how it aligned with company goals
• sign-off from parts of the business that had never been involved
• people taken away from their day-to-day work, which understandably wasn’t popular with everyone

There were rounds of back and forth, sign-offs took time, and the pull on people’s time caused real friction. Eventually the project fizzled out. By then, it wasn’t October any more.

What I learned

Protect the smallest version that delivers value. I’d have been happy with a few people in a room. That version needed no business case because it cost almost nothing, and it would have created the momentum for a bigger one next year. Growing the scope before the first run meant asking for a business case before there was any evidence.

Explore before you extract. It’s the same failure I now recognise in platforms: asking for proof of value and company alignment while you’re still in the “find out what works” phase (Explore, Expand, Extract). Trying to include everyone from day one is how you end up pleasing no one (Growing a Platform: Breadth, Depth and Gear Shifting).

Enthusiasm is a resource; scope is a decision. The people helping me weren’t wrong to dream bigger. What I didn’t do was say, kindly and clearly, “Yes, and that’s version two.” A lighthouse event with a few willing developers is the community equivalent of a lighthouse team for a platform (Designing a Platform for AI Assistants).

Time-boxed ideas need a deadline-shaped plan. A Hacktoberfest hackathon has a hard date. Every extra approval step was a step towards missing it.

Training parallel: it’s adding far too much weight to the bar before you’ve grooved the movement. The lift stalls, and you go home without the rep (Progressive Overload and Incremental Migration).

The version that worked

A few years later at Accedo, where I was acting as a developer advocate alongside my engineering work, I helped organise a hackathon that went really well and got great feedback. Looking back, the difference was the shape: it grew out of a community that already existed, built through regular tech talks and knowledge sessions. The ambition was the same; the order was different.

Related: The Business Value of Developer Relations · The Five Dysfunctions of a Team · Chairing a Cross-Team UI Guild