What I learned Hacking in Seattle

What I learned Hacking in Seattle

I’m currently on a plane back to NYC after a whirlwind trip to Seattle for the Comcast/NBCu Hackathon. Yesterday, to a room full of hackers and NBC execs, I debuted a working iOS app that can unify measurement across all screens by listening to a video ad play on any device.  Spoiler: we lost the competition.

discover a new relationship with advertising

In another message, I’ll follow up all about what we built and how we built it.  In this post I wanted to write down my lessons learned from this Hackathon while the paint is still wet.

Know your Hackathon goals

A hackathon is a game with a goal.  However, like all games with crummy prizes, getting first place is only one way to “win”.  From the start, my team defined success as building something ambitious with the potential to improve video advertising (and learn along the way).

We didn’t win, but we still celebrated Saturday night as champions because we achieved what we set out to do.

Advengers, Assemble!

I achieved my personal hackathon goals as well:

1. Build something that could change the TV advertising industry (check)
2. Eat fish (check!!) 
3. Make friends and have fun (check and check!)

Argue vehemently. Commit completely.

Building something in 24 hours requires total alignment.  Anyone working on functionality that does not support the goal is wasted work, and we have very little leeway for waste.  Alignment is impossible without agreement on the goal.  

The wireframe that sparked our controversy!

At the starting bell, we began by setting aside 30 minutes to argue about what we were building.  This was heated, critical, and probably the most productive 30 minutes of the competition.  In half an hour we agreed to a common vision and each felt heard and valued. 

Simple! 

After agreeing on what to build, thinking about how to build it came much easier. We were done with tech design in no time because we all saw the same target.

Scheduling: Divide Tasks, then Sync Constantly

Before I begin talking about scheduling…

For those of you who haven’t coded before, building an app is pretty easy:

1. Build the parts of the app
2. Combine those parts

…not unlike building an Ikea bookshelf! (For those of you who haven’t built an Ikea bookshelf, you’re missing out!)

A hackathon is all about constraints: time, people, and skills.  There isn't a lot of slack for anyone to be idle or to work on something that ultimately gets thrown away.  

Before we began coding anything, we started with a goal and a tech design.  Blindly dividing and conquering would lead to trouble because tasks have dependencies on each other’s, and a person's unique skill can quickly become a bottleneck if they're working on the wrong thing. 

• To start, we took inventory of our known bottlenecks and made a rough list of all the tasks we needed to do.  If two people were working on things that talked to each other, that integration was flagged as a separate task from the beginning.  
• Then, we doled out the most critical functionality that didn't have dependencies and could be completed by the fewest people.  
• Once we had assigned a first set of tasks, we continually checked in every 30-60 minutes as a team to run mini-scrums.  During these check-ins we would review progress, update our list, attack any new issues as a team, and hold ourselves accountable for delivering against our own timelines.  This let us ensure dependencies finished before subsequent tasks began and sometimes abandon functionality before we had over-invested.

The presentation IS the deliverable

It’s embarrassing how long this took me to grasp: the goal of a hackathon is to present something, not build something.  Frankly, I don’t think it clicked for me until after they named the winner.  Even during other teams’ demos, our team was still whispering about how an effective presenter with a great idea had a week technical undercarriage.

At the end of the day, I liked our presentation, and I’m incredibly proud of our sweet tech.  But if we could do it over, I would have thrown another coat of paint on the demo.  Lesson learned.