A Hackathon Later…

This weekend I participated in the Comcast NBCUniversal Hackathon in Miami, FL. Half way through Saturday I knew my first major Hackathon was going to be nothing like I imagined it. I must say the following, I am now a Telemundo Fans member. The food was out of this world. Now, I’ve been told that pulled brisket, salmon fillets and donuts is not the hackathon norm (why do people say things that kill happiness…?). I was going to update LinkedIn: Professional Hackathoner. “Expect stale pizza and 2 liter bottles of Coke.” the Joy Assassins said when describing how hackathons ‘usually are’.

Really, all jokes aside, the people that worked over the weekend to accommodate us: Thank you. I really appreciate it because not only did you do your job, you did it well and graciously. Muchas gracias a todos!

Before the Hacking Began

So, there were two webinars that BeMyApp organized which were very useful. They were able to introduce the tech partners: Amazon Web Services, WIREWAX, Cloudinary, MongoDB, Google Cloud and others, in addition to the NBC Universal partners that would clearly lay out their program requirements. I was able to ask a couple of questions and both were answered during the webinars. Here is were the first tip of this entry begins:

Tip #1: Don’t ask “can your technology do xyz”?

The answer to that question will likely be: ‘Sure!’

Ask instead: “Can your technology do xyz AND will I have access to the API to do exactly that?” I would even venture to ask if my devs can get a key and start poking around. This way, if they say yes, you can start huddling up with your team and more seriously start considering the API, the tech that will be needed to complete your task and whether the competencies we already have are enough for the task at hand. This last point will later lead to my third tip…

But first…!

Yes, first we all met and had a review of the acceptance criteria and then conducted an ideation round. We ideated and came up with no real winner just a list of features or items we would like to see in our hackathon’s MVP. I had in my mind a clear favorite and when I pitched it, the team was also pretty psyched out about it. Voila! We had a winning idea! Here is my second tip:

Tip #2: There’s no such thing as a Plan B, if it’s thrown together after Plan A fails.

So, by now you may see where this one is going. The functionality that I was assured could be enjoyed (and I have no doubt that the tech provider could actually do it) was off limits for the purpose of the hackathon. A work around was graciously offered and we considered it for some time (actually, way too much time.) But, the time we spent trying to salvage this idea was also a function of the fact that we had no back-up plan. My fault! I put our team together and in my personal life I make backup plans for a trip to the beach. Yet, I failed to operate under this mindset for this hackathon.

Finally!

Since we (two designers and two web devs) showed up to the hackathon without a clear and fully fleshed out idea, let alone a backup, we didn’t know what web dev power we needed. “I think we may need some more man power.” one developer said. Cool, so we found some woman power! We were able to find an Ironhack grad from Paris who studied Web Dev and was able to complement the team perfectly! Everything perfect??? I don’t know if it was jitters or the fact that I don’t feel comfortable telling the web devs what they do or do not need, I allowed another web dev to join our team. We ended up with a team of six three hours into the hackathon.

“Are you sure that we need another cook in the kitchen?” I asked.

From the UX and UI design standpoint, I thought that I (UX) and Benjamin Richardson (UI) were more than enough. However, I was assured that the web dev kitchen was large enough for a fourth. So I relented. Bad idea, not only was he not needed, but he also decided that he would tend to a 10 hour Tinder call (yes, Tinder) and disappear. When he came back, I told him he could not continue in the team and, of course, he kicked, spit and dropped F-bombs. But, out he went. And what’s worse, I never even saw his credentials! I don’t even know if he has a Github account let alone a single commit… . That’s all on me and will go into the inventory of things I need to know as a professional and a leader.

Tip(s) #3: If you take Tips #1 and #2 to heart, these tips are no-brainers!

If you have two, maybe three, clear ideas set up before the hackathon you should now:

Set up a heirarchy which I suggest should follow this criteria:

1. Follow instructions!! There were many great ideas presenting on the second day. But, of these, there were also many that did not meet the requirements and lost. (I must admit that we were not guilty of this. Here, we killed it!). Relevance is KING!
2. After making sure that the ideas are in line with the requirements, allocate more priority to ideas which require less outside help. If you can build something relevant, simple and that works (not a demo), you will be ahead of the curve. Result, you hit the ground running with the exact team you need. Depending on an API should not discount an idea, just proceed with caution.

And, regarding staffing…

If, given these ‘winning’ ideas you need to bring on a developer, make sure you vet them first and make sure you take a good look at their Github profile. Don’t just take their word for things. More commits are better than less and certainly more valuable than a quick handshake. If it’s a designer you need, for God’s sake, check their portfolio… . Do all of this before you even show up to the hackathon.

Now, it’s on to my next hackathon where I am sure I will learn even more key lessons and hopefully take home a cash prize. Can’t wait!