Sep 7, 2011

Learning from a FAIL

Last year at TechEd Australia I delivered a session on Unit Testing that was rated top 10 overall.  This year I delivered a group session that has ended up in the bottom 20.  Ouch!

So what went wrong?  Let me run through a few things and explain.

For those who weren’t there, the session was a group session presented by myself and 3 others and what we wanted to show was how you can use the full Microsoft stack do deliver on the “three screens and a cloud” promise, how the ALM tooling that Microsoft provides (i.e. Visual Studio and TFS) helps with that, and some of the things to watch out for when doing this kind of development.  Our vehicle for this was going to be a multiplayer game that runs on both Windows Phone 7 devices and Windows desktops.  We also wanted to show how you could extend the experience beyond the game itself and use a single page web application to extend the gaming experience, so we threw that into the mix as well.  That’s a lot for an audience to process in a short space of time.  Probably too much as it turns out.

Adding to this, re-reading our session abstract I can see how it is easily misinterpreted.  It can be read as if we were going to actually build the application on stage.  We never even considered that as an option because we though for sure that the audience would be lost, but it appears a number of people thought we would try anyway.  I appreciate that you think we can condense 170 hours of development effort into a a 1 cohesive presentation, but we’re not superhuman! :-) This is a failure to manage expectations on my part.  If you turn up expecting to see pure, unadulterated, glowing awesomeness on stage and then we present something that makes them seem merely human then you’re going to be disappointed no matter what.  Not meeting expectations is a common cause of discontent and I missed the mark here.

Now when we started our session planning we had nothing; no application and only the vaguest of idea on what it might be that we’re going to build, yet we needed something to show so we could have the bones of our session.  This meant we needed to build the whole thing in our spare time and this is where the main problem arose – for various reasons the team only finished the application right before TechEd.  Further, because of the last minute finish of the application, the remoteness of each of the presenters, and the presenter’s individual TechEd sessions on top of this one, we never managed to get a proper dry run through the presentation with all of us there.  We knew the basic idea of what we needed to talk about but we never managed a full practice first.

This in particular was bad! When I’m doing a solo presentation I usually do at least 3 or 4 dry runs first just to make sure the timing is right, that the flow works and that I hit all the points as I want, etc.  Preparation is key!  I know this, yet did we do it for this particular session? Not really, no.  And the results, sadly, showed this.

Because of the lack of preparation, we also had a few “off script” moments that really, really didn’t help.  Compounding this is that as presenters we all know each other and are quite ready to joke around and have fun while still getting stuff done.  This unfortunately doesn’t translate on stage.  Humour in a session is great on the proviso it doesn’t detract from the message, that it keeps audience interest up and reinforces the learning for them.  You’ve also got to ensure it’s delivered well and in-jokes or overdoing it certainly doesn’t count in any of these cases.  Again, we let the audience down a little by doing this.

Lessons Learned

So, what do I learn? How do I improve for next time?

Content may be king but don’t overload the audience or be too shallow and too broad. We would have been better scaling back on what we did, limiting our content to only a few areas and going deeper in those areas instead of skimming.

Preparation is paramount.  Our lack of preparation hurt.  Not the preparation in the building of the game (that was fine) but lack of preparation in the delivery of the session.  No matter how good (or bad) the software was, if the delivery was good we would have been fine and people would have enjoyed it more.  The lack of preparation also contributed to overload of humour on stage.

Set realistic expectations.  There’s a trick when writing session abstracts.  If you make your session sound too boring you probably won’t get asked to speak, but if you over-hype it then people get their expectations raised too far and you set yourself up to disappoint.  More care and attention to the wording of the session abstract would have helped a great deal in this case.  It’s much better to under-commit and over-deliver than to do the opposite.

Working in a group is hard.  The larger the group, the harder it gets.  If I do another group session in the future, the way we work and the amount of time we’ll commit to up front will be clear from the outset.  Coordinating 4 speakers when they each had their own individual sessions and limited availability was asking too much from everyone, so when something had to give it was, unsurprisingly, the group session that suffered.

Evaluation Comments

To round out this lengthy post, let’s have a look at some of the comments from the evaluations, both the positive and the negative.  I’ll provide my own feedback in italics:

  • Although I gained a number of tips regarding potential issues there was little here that I can action directly when I get back to work on Monday. The speakers were all fun and had an easy rapport which made this an enjoyable session
  • Cut the attempts at comedy and get on with presenting what would have been worth seeing at a more even pace. If you hadn't have jerked around with your piss weak in jokes at the start you could have maybe finished up properly. This doesn't apply to Steve. He looked embarrassed to be with you other gooses.
    - Whoa! OK, ignoring the bile, your point is taken.
  • Funny presentation, sometimes a bit over the top, but great stuff nonetheless
    - Point taken on the over the top.  It shouldn’t have happened. Sorry.
  • good fun talk, relaxed
  • Good stuff Ricahrd!!
  • great presentation - thanks!
    - Not our best effort but also not a complete waste of time.  Good to know.
  • I think the material was good but the comedy act they tried to tack on was just distracting and made their presentation look amateurish which is not what I expect for this type of event.
    - Agreed.  Comedy should have been used sparingly.  Mea culpa.
  • I was looking forward to more on the fly coding, rather than flipping past a pre built project. It would be better for my understanding if the demo was for a simpler project, but setup and built in front of us.
    - Expectation management.  We probably should have been clearer in the session description about this.  Lesson learnt.
  • Its teched not the comedy festival ;)
    - I assume the smiley meant they enjoyed it.  Still, backs up the point that we overdid things.
  • Less talks and more information and code demo was desired
  • Loved the idea of the talk but the reality wasn't what I was expecting. I was expecting (yes my expectations were probably too high) a simple MMO built from scratch during the presentation, demonstrating the key technologies for each platform. In reality the app had already been built but even then too much time was spent monkeying around instead of showing source code or talking about lessons learnt. Once again like most presentations at teched it would have been great to have a link at the end of the talk to any downloads/links etc. Talk had potential but didn't deliver.
    - That last sentence nicely sums up my feelings as well
  • OK demo, but a bit too simple for business app.
    - I thought a title including “MMO” would indicate it wasn’t a business app.  Expectation management again.
  • Session should have had more code examples going through the actual development process.
  • The 4 speakers probably know the technology, but the whole session came across as a jumbled mess of in-jokes and non-seriousness. Not sure how anyone can manage to "learn" anything from these guys. Please plan the session better or if you really didn't have anything to say, just cancel it.
    - Preparation failure on our part.  I’m sorry.
  • The humor and relavence of this session made it very worth while.
    - Humour works sometimes, but it didn’t work for everyone.
  • The session was informative but I think that there the naming of it should have been better as the current title made the room uncomfortably crowded. The presenters were knowledgable in there fields but to me Steve Nagy was the best presenter, properly explaining the process he took in the development of that project. Though I don't mind some joking it really did distract too much from the amount of material that they needed to cover.
  • the speakers did not realise the audience invested time to see this demo. They enjoyed each other company, but wasted my time.
    - Apologies for that.  It definitely wasn’t the intention.
  • There was a little bit too much shenanigans on stage, and too many in jokes, so I think a lot in the audience lost interest. I think people were expecting to see more actual code and implementation (as the session title implied).
  • This was a very ambitious session and unfortunately, the presenters did not quite pull it off. There was a lot of really cool stuff that these guts were trying to present - but the presentation was low on details, and the attempts at comedy took away from technology being presented
  • Too busy trying to get a laugh from the crowd, that time could've been spent explaining some of the pitfalls they faced.
  • too much focus on the "gaming concepts" (XNA/Latency&Prediction), but overall very good session.
    - A dry run would have helped balance a lot of the issues raised in the 3 comments above.
  • Too much time was spent playing about on Stage and not enough on the content. A little bit is good but they went way too far. Points focused on seemed to be very specific to the problems they found with an MMO example, not necessarially translating to what someone else would experience building an app with a cloud backend for the three screen types. The third presenter was more straight up and he actually pulled the about scores up a bit. If I was rating him individually he would get far higher scores for the above, but I would have liked some deeper content, particularly from a 300 session. The one thing that would save this is if we could get a look at the code to actually see how much crossover there is between each of the clients in detail and pull it apart ourselves a bit.
    - I’m tossing up wether to put the code up on github to look at, but some of it was very rushed and not our best work.  Is that still useful?  Blog posts that go into detail may be better.
  • Very good and informative session. Also the speakers' lightheart approach makes this sessions very interesting. Bravo
  • Weirdos! Made the session fun
    - Erm, thanks for that summary… I think :-)

And there you have it.  A very public retrospective from my part on what went wrong, what could have been done better and the lessons to learn.

Publicly talk about your failings is hard, yet there’s nothing that teaches you more than a big, public failure.  This is my attempt to do some tough learning in an open way so that hopefully you learn something from it as well.

Finally, if you attended the session at and you thought it sucked, then I apologise and hope that you enjoyed the rest of the conference.

3 comments:

  1. Great post Richard, admitting fail in public is hard, but totally worth it for the readers when the lessons learned are included.

    /GertGregers

    ReplyDelete
  2. Haha, I was there and it indeed sucked. You even mentioned my evaluation above :) It's nice to see the other side of the story though and see that you guys learned from your mistake. Keep up the enthusiasm however, at least the session was lively!

    ReplyDelete
  3. Hi there! The post is very interesting indeed. I really enjoyed reading it, it will serve as a sample to avoid mistakes.

    ReplyDelete