Paradoxical Incomprehensibility

Several times in past years, TheHackerCIO has been amazed to see the paradoxical advantage gained by a knowledgeable person shielded by an impenetrable accent. One person in particular had an exceptionally good technology background, but a very thick european accent. Let's call her Karl, in keeping with the PC policy of being as confusing as possible with pronouns.

Whenever Karl put forth her technology proposals, they were sound. But the advantage she garnered came from avoiding any questioning or probing, which uniformly foundered on the shoals of her thick accent. I knew from my own intimate acquaintance with the implementation, oftentimes being coded and tested by yours truly, that these questions were receiving what the lawyers call "non-responsive" answers: that is, the answer was not a response to the question asked.

Was this a deliberate "mis-understanding" of the question posed? At times, I'm sure it was. Perhaps, other times it was genuine. But the misdirection, coupled with the difficulty of comprehension, seemed to provide a cover for Karl, so that no opposition could effectively field a contrary viewpoint.

Notice that this didn't help in the big-picture-sense of the word. It didn't help the policy to be correct, or better, or even succeed. It did help Karl's career and/or her specific goal of implementing whatever technology was desired.

There were two reasons for this:

• the generosity of the listeners, who naturally, and generously assumed that the question had simply been misunderstood by a non-native language speaker. Also, to actually dig in and demonstrate that the answer was not connected to the question properly would seem very combative and perhaps even mean-spirited. 
• bits and pieces of the answer were correct, technically, and based upon a deep and proper understanding of the underlying technology, which reassured the listeners that a proper approach was being taken, even if it was surrounded by the fog-of-incomprehensibility of Karl's accent.

To return to the big-picture, note that comprehensibility and communications are the number one issue and problem in technology development and application. A miscommunication of requirements is clearly far more devastating to total cost than any other single item conceivable. From my own experiences with Karl, I know that the objections of the "loyal opposition" within the company could only have led to an improvement in the overall approach taken, because I know from my own firsthand experience that many improvements were missed out by my inability to penetrate the verbal fog quickly enough to be able to tweak or adjust it to suit the particulars of the situation. 

Incidentally, this comprehensibility-overhead has to be factored into any attempt at outsourcing. If you're going to uphold the primacy of communications principle (and I think one must!), then it only follows that you have got to dig in, bite-the-bullet, and resolve each and every communications issue that arises in the course of the project.  Rigorously. At all costs. If that means that you lose any, or all, or even more than all of the cost-advantage that came from outsourcing to a foreign organization, then that's just the way it is. You simply have to find ways to emphasize that you're "sorry to be difficult", and so-forth, to counteract these communications-barriers. And that is true regardless of whether you're outsourcing. 

Because communication is the primary issue. 

I Remain,

TheHackerCIO

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

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