Reflections on a Bad Presentation

Last week I did a presentation at the Executive Briefing Center. This is not unusual, I’ve done lots of CxO briefings in the past with typically high to very high scores (7-9 out of 9). However, this time, while I had some decent scores, I also had some awful ones (more than half under 5 including a 1 and a 2. Ouch!) and was the worst scored presenter of the session. While it would be easy to chalk it up to “you win some, you lose some” or to blame the customer (i.e. “they weren’t technical enough”) that’s not going to help me do better next time. I’ve given it a bunch of thought, and there are two key things I’ve learned from this experience.

The first thing is that I wasn’t utterly prepared. This is Scott Hanselman’s 2nd tip and I blew it. I used to deliver the “.NET Vision” presentation three or four times a week. Doing that for a year is the definition of utterly prepared. However, in the past year, I’ve changed roles. I’m an architect evangelist now, and we have a dedicated role on the team – called the .NET Advisor – who is focused on delivering the high level vision of .NET and web services. I have an old friend who used to say “use it or lose it”. He was talking about programming skills, but the same goes for presentation skills. My ability to deliver the high-level .NET & web services vision has waned from lack of use. This wouldn’t be a huge problem, except that I didn’t realize it. I chose to white board the session, in order to be more flexible. But since I was out of practice on the material, I ended up being inflexible and doing a poor job delivering the message.

(BTW, speaking of .NET advisors, we have an opening on our team for one in Charlotte, NC. Submit your resume if you fit the bill.)

While I understand what to do about preparation (i.e. do more), I’m sort of stumped on my other key learning. We had the customer present first, to tell us about their organization. Among other things, they told us their list of IT priorities. It looked something like this:

  • Webify legacy applications
  • …a bunch of other stuff…
  • Build web services

I imagine this priority list is pretty typical. However, it’s upside down. Building web services in front of legacy applications needs to be more important that webifying them. The IT world is getting faster and more complex by orders of magnitude. This requires a new way of thinking about how you put systems together – i.e. Service Oriented Architecture (SOA). Webifying old applications is lipstick on a pig.

But how do you tell the customer they are wrong without being arrogant? I mean, webifying legacy apps was their #1 priority and I told them it should be struck from the list! Conventional wisdom for sales people is that the “customer is always right”, but I’m an engineer at heart where right and wrong usually can be technically quantified. Adopting SOA is, IMHO, a critical factor in the continued long-term success of any organization today. In many ways, it is even more important than choice of platform (though I remain confident that a customer who adopts in SOA is more likely to choose the Windows / .NET platform).

I meant to challenge the customer’s assumptions. Instead I proceeded to alienate at least half of them. While it is tempting to blame them for being closed minded, the truth is I could have challenged them in a way that didn’t alienate them. The problem is, I don’t know what that way is.