What Did I Do Wrong in My Hackathon Presentation?

Post-mortem analysis is the very flower of Pathology. And of medicine.

It's the mechanism by which one can scientifically determine pathology, learn from it, and eliminate it from live patients.

Very few presenters at the last Hackathon were "live" in the judges estimation, after they gave their 90 second lightening talk.

Toward the end of the 5 1/2 hour ordeal, the judges were saying, "so, is that another WTF? Did anyone understand what it did?"

And so, another 48 hours of labor times team-members bit the dust.

Don't you think thats a waste?

I suspect that huge numbers of original, innovative, and well executed projects were there at the Hackathon, but it was impossible to know for certain because the presentations were, generally speaking, so poor. Incredibly poor. As if they never read my blog poor.

TheHackerCIO isn't going to repeat the details of the 4 Tips for Hackathon Presenters. Follow the link, if you haven't read the basics, which I posted prior to the judging. Here, I'm just going to list them, with no details, and then add in an autopsy on the additional errors and failures I saw. I'm not prioritizing them or otherwise ordering the list. It's in the order that they come to my mind.

But anyway, we all know how many people love these numbered lists!!!

1. You over "Uh-ed".  Don't "Uh".  It's OK to think without making noise.  
2. You didn't Speak Up. Speak up. You have a microphone.  

3. You presented with a thick accent. If your presenter has a thick accent, consider employing a better communicator. 

4. You had no attention step. Pick the most interesting attention step you can.

5. You didn't focus. You can't solve every problem in Public Safety. You can't use every API on the contest list. Why do you make it seem in your presentation that it is "all things to all men." All that means, is that it is nothing. It has no identity. No integrity. Diffuse presentations were a major problem at the Hackathon and the judges hated it. 

6. You didn't rehearse. So you got cut off at the end of 90 seconds. That means you didn't get your conclusion in. You missed out on delivering the Fing most important lines of your presentation. All because you didn't rehearse and get your timing down. Shame on you. Shame. 

7. You presented How before What. I knew that you used a proximity sensor and a Gimbal and this AT&T API and that Plantronics head sensor and all kinds of wonderful stuff. WTF it actually did -- I have no clue. You presented how you did whatever you did but forgot to mention what it was you actually did. The what must precede the how. Duh. My 15-year old daughter complained most particularly to me about this, without my ever telling her. So how come you didn't figure that out? Because you didn't rehearse with anyone. And I was available. A Hackathon weekends labor is a terrible thing to waste. Especially just because you blew it something as simple as good communications. 

8. You failed to convince the judges panel that you actually produced a demo version of your product. That blew you straight out of the competition. In one particularly tragic case, TheHackerCIO had to fight with the other judges. "So, did they actually deliver anything?" Came the question from several of them. "Yes, they did,  I replied. I saw it working last night at 4am. And they had time to add in more after that!" But if I hadn't been there and hadn't seen that demo and been blown away by it, We would have immediately eliminated that team from the running and moved on.  Remember, we had about 10 seconds to evaluation your 90 seconds of presentation. 

9. You focused too much on the business or revenue model, when you were presenting to judges who were technical. In other Hackathons, CEOs were brought in to judge the winners. Those are the people to pitch on business viability. Now, a quick mention of this wouldn't have hurt, even with us. But some people spent way too much of their precious 90 seconds on this, when it WASN'T a JUDGING CRITERION. 

10. You wasted precious time from your 90 seconds by introducing yourselves and where your team was from. Your name is irrelevant. We had no criterion for "good introductions" that gave contestants points. All this did was rob you of time to convince us of your originality and execution. It's also the lamest possible attention step. "Hi, I'm Bill Hatley, from Iowa and Shirley here is from San Diego..." Yeah, that really riveted my attention; I quit looking at that cocktail waitress walking by because I wanted to see what Bill from Iowa looked like. 

***

Ok, so I'm way too tired tonight to continue. And I'll be moving on to other topics, starting tomorrow. But that doesn't mean that I won't be writing up all my notes from this event. I'll be dribbling them out over the next few months, so if you want to learn the most you can about the event for the next time, you'll need to stay tuned ...

And tomorrow morning, TheHackerCIO takes a plane out to Miami. Time to visit clients and get back to work. And get back to some other interesting technology problems. It wouldn't do to dwell overly on just Hackathons. 

Maybe it's time to talk about Strategy. 

Or about Java 8. 

Or ...

I Remain,

TheHackerCIO

Judge & Jury, Too

TheHackerCIO worked the Hackathon the moment he arrived on Saturday morning.  Not caring too much about it, he barged his way in the door, looking like he knew where he was going, and kind of half hiding from the door-guards, by "drafting" behind a few other, properly registered Hackathon contestants, in much the same way he would have drafted behind a large City Bus with his 10-speed bike, when he was a teenager.

But he didn't want to wonder if he'd ever get back in the door a second time, should he go to the hotel room.

So, after many hours, down to registration he moseyed. "I'm judging this Hackathon," said he to the registration attendants, "And I kind of think I ought to have a badge!"

"Of course," said the very helpful ladies, "So..... let's see .... You're a judge ...."

"And Jury, too," said that funny fellow, TheHackerCIO!

Laughter was apparent at the Registration table.

But isn't there a truth to it?

Why do they always call it a "judge" for some kind of event like this? What is typically done is far closer to the function of a Jury. We had a panel of about 5 judges. We all sat around a table (not quite sequestered, but close), and we recorded our decisions individually, but discussed our scoring internally and argued and convinced each other to reach a set of final verdicts.

As far as the function of a judge, I definitely performed this function to some extent as well. I reminded my honorable fellow jurors of the need to be objective about their "evals." For example, several times business considerations entered into the discussions. And while I'm very sympathetic to using that as a criterion, that wasn't an option. It was not in the "Constitution" of the competition! Only Presentation, Originality, and Execution were our evaluation criteria (Use of AT&T APIs, also was in the list, but was assigned to a separate jury). I had to give the jury instructions on this matter several times. "Business viability is irrelevant," I told them. "It's not one of our evaluation criteria."

It's just an interesting reflection, but that's an important thing to do.

And besides that, I always wanted to be able to say, "I'm judge and jury too." So this posting has been my big chance!

[And for the curious, inquiring minds, that photo is of TheHackerCIO with an M249Saw in hand and a belt of .223 over the shoulder. With that, he could mow down any opposition. It's also, about a $150,000 piece of hardware. This picture was taken at about 11am Sunday, at a well needed break from working the event to go on a shooting party with my family and a Las Vegas colleague (and friend). After the shooting party, came the work of judging the lightening talks. ]

I Reflectively Remain,

TheHackerCIO

4 Presentation Tips for Hackathoners

Today marks the completion day for the Hackathon. Presenters will have 90 seconds to win the prize. Or not. TheHackerCIO likes to see crisp, excellent presentations. So, despite the fact that he's a judge, he sees no conflict of interest in helping as many people as he can to do their best on their presentations.

I've told everyone the following:

1. First and foremost. Don't "Uh".  It's OK to think without making noise.  Every "Uh" you add cloys the auditory palate of your audience and detracts from your presentation. Practice your 90 seconds of fame with a colleague or friend. Have him bitch-slap you every time you say "Uh," or "Um." Or whatever other verbal detritus you have picked up. Eliminate it. Do it now.

2. Speak up. You have a microphone.  Find the sweet spot between these two extremes:

• nasty screeeeeeeeeeeeching feedback
• mumble, mumble, blah, and mumble

You want to fill the room with your voice, so that no one must struggle to hear your presentation. They might do it for a moment, but they will soon tune out. And that's not good.

3. If your presenter has a thick accent, consider employing a better communicator. Why let the non-important issue of accent screw with your winning a prize? At the last Hackathon where I was a GrandMaster (I wasn't just a Sensei .... I'm beyond that level!), one of the teams brought an actress to present the concept. The idea-generator (who had a thick accent) coached the actress to make the best possible presentation. I thought this a very smart move.

4. Pick the most interesting attention step you can. Grab your audience by the mental throat; arrest their attention and then transition immediately to the main point of what problem you solve or value you offer. You don't want your audience to keep looking at that cute waitress bringing out drinks ....

This will get you started toward making the best possible presentation you can.

Now let's break this down and see how it applies to winning a Hackathon. I've seen two first place prizes go to an actress who never coded a line of code (until this last year), but who nevertheless brought home the bacon repeatedly. Two years in a row. First place both times. Why?

Because the Hackathon is judged on 4 categories:

1. 25% weight - Ability to clearly articulate what your app does
2. 25% weight - Originality of idea
3. 25% weight - Difficulty of technical implementation
4. 25% weight - Use of AT&T APIs

Actress scored 100% of 25% on point 1. Perfect articulation of what the app does. She was absolutely the best at the Hackathon. This was true at her pitch, so she attracted the best developer. That was an advantage for point #3, which we'll see later.

Actress scored some percentage of point 2. Not super innovative. But interesting. 

Actress scored 100% of 3. Not so much difficulty, but the amount of functionality produced was clearly the best at the Hackathon. And that was because Actress got the best developer and the best designers and other helpers to work on her project.  And that was all because of her good presentation of a clearly articulated idea.

Actess scored a good showing, at least a 90% of point 4. Again, because she attracted the best developers, they in turn did an excellent job of using the APIs.

I think this example underscores the importance of good presentation skills. 

I hope this blog posting helps you to produce the best presentation you can, and win the Hackathon for your awesome innovation.

P.S. See also: here. 

I Remain, Helpfully,

TheHackerCIO