Internal Hackathons the Lean Way

Nov 04, 2017

One of the many awesome reasons why I love working as a software engineer at The Container Store is that once every other month we take time out of our busy days to compete in a 24-hour hackathon. We self-organize into teams around some project we think is loosely related to our business and a day later we demonstrate whatever we were able to cobble together.

I’ve been fortunate to have something of a winning streak over the last few hackathons, but I don’t consider our teams to have been a collection of engineering superstars - instead I believe that we’ve stumbled upon a winning recipe: treat hackathons just like a lean startup.

The Lean Startup

For those not familiar with the Lean Startup methodology, you’ve probably heard of it’s core philosophies by some other name. The aim is to iteratively build your business by starting with a tiny first product and incorporating continuous customer feedback as you gradually refine and build new features. An effective lean startup wastes very little engineering time developing features that customers don’t want, or that don’t positively impact the business’ bottom line (those two things are typically synonymous).

This is in stark contrast with another (bad) startup methodology that starts with some grandiose plan and eventually produces a polished product after many months of engineering. The result of this second flow is usually something that doesn’t connect with customers and may actually destroy the startup company itself.

Anyone who has played the startup game knows that the lean startup route is not a guarantee of success, but not following it is almost certainly a guarantee of failure. In my experience, your hackathon team is simply emulating a startup on very compressed timescale, so if you want to have a “successful” hackathon project, you really should be doing it the lean way.

Note: I’m defining “success” as “winning the hackathon competition”, and the rest of this article uses that definition. It’s worth noting that some hackathon teams exist purely to explore some new idea for the sake of knowledge/self-learning, and those teams should define success in a very different way.

Hackathons the Lean Way

1. Identify Your Customer

As with any successful startup, one of your first tasks as a team should be to identify your customer. I’ve participated in many hackathons across several companies, non-profits, and education and I can say with absolute certainty that the number one mistake unsuccessful hackathon teams make is to mis-identify their customers.

In fact, most engineers identity themselves as the customer! What I mean is that engineers think of some cool idea that would make their lives easier, or be impressive to their peers. However, if the judges panel at the competition is staffed with VP’s of Marketing, or a CEO - they likely don’t care much about the interests of engineers. Teams that make “cool stuff for engineers” probably won’t win many such hackathons.

If you know that the VP of Marketing is going to be a judge, then you should figure out what the VP of Marketing is interested in. If you’ve overheard them saying something like “It would be cool if we could do X”, well, you should definitely build X! On presentation day if you present an idea that the judges have already identified as a business need, you don’t need to waste any time convincing them of the value of your project and you’re way away of any team that does.

2. Keep it Simple

Once you’ve identified what thing your team is going to build, you should figure out how to build the simplest possible version of that thing. As is also read in the obituaries of many a failed startup, hackathon teams often stumble over useless features at the last minute and fail to present a working demo with the most basic functionality. It would be better to present something with one feature that works than something with 2 features that does not.

So, identify the core feature and build that. Everything else is window dressing. Add the dressing as time permits, but never at the cost of the core feature.

You should also be familiar with the technologies inside you company that are easy to use, and the ones that are notoriously painful. Use the easy ones, and avoid the painful ones. I know this sounds obvious, but it’s somehow frequently overlooked. If you need customer data to show off your project and you can choose between setting up a connection to your production Oracle database, or simply use a public API for the same data, you sure better be using the API instead of trying to configure Oracle!

3. Make Your Presentation Compelling

As it turns out, people care about how things look. Given two projects with comparable functionality, the one that looks better will win almost every time. You should not sacrifice your core feature to make things look good, but you should leave time to make things look good before adding superfluous features.

Another way to look at it is like this: always keep the demo in front of the judges in mind. Add features that will be compelling during a presentation and avoid features that won’t add anything to the demonstration.

4. Recruit Well

Of course, as with any startup (or any business for that matter), the people on your team will be your number one resource. You should attempt to recruit a team (or recruit yourself onto a team) who understands the points above. If you know that the VP of Marketing will be a judge, then it really makes a lot of sense to have someone from marketing on your hackathon team (this is especially influential when all other teams have only engineers as members).

Also, keep your team size manageable - just like your scrum team, you should aim to have 5-8 people.

Have fun

There you have it - the recipe above is not some magical, secret formula - in fact you’ve probably read an article about how to build a successful business with almost the same advice above.

As a final note it’s important to say this: have fun. Hackathons should be a time to experiment with new technologies, work with teammates you’ve never interacted with, and build things you just don’t have time to build during your regular workday - but if you can’t have fun with them, then they’ll just be another draining exercise.

Come Join Me!

I’m very thankful to The Container Store for treating the engineering team to these games every now and then. Hackathons are just one more little reason why I love coming to work every day. If you’d like to learn more about our internal hackathons or some of the other very cool stuff we do here, please don’t hesitate to contact me, we’re hiring developers right now!