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.

Pulling out the Petzold to use the P2P SDK

Lots of people (including me) have pointed out that the WinXP Advanced Networking Pack and P2P SDK have been released. But I haven’t seen any code besides the samples. And if you look through the samples, I think you’ll see why. I’ve picked thru the “GraphChat” sample, which is written in raw pre-MFC Petzold-style C. It took a while to isolate the relevant parts of the code from all the windows goo that I thought I had finally seen the end of. I have to go through the code since the docs aren’t all that fleshed out yet.

One of the trickier parts is integrating with the new Peer Name Resolution Protocol (PNRP). PNRP is a serverless DNS-esque system (though there is a “global” PNRP server hosted by Microsoft). It’s supposed to be independent of the Graphing and Grouping API’s, but the GraphChat sample gets the IPv6 address from the created graph in order to register the address with PNRP. Now that I’ve installed the Adv Net Pack, I have three virtual tunneling psudeo-interfaces. Other than hardcoding, I’m not sure how to get the address of the right tunneling psudeo-interface to register w/o creating a graph.

I’m getting the feeling that I should have started with the Grouping API, rather than the Graphing API. It runs at a higher level of abstraction, so I figured I should learn the underpinnings first. But I bet the Grouping API would have been much easier to understand.

Can You Hear Me Now?

Microsoft recently shipped beta 3 of the Speech Application SDK which allows developer to build voice response telephone apps as well as multi-modal web apps for desktop and pocket IE (with Microsoft Speech Server which just went beta 1) . But you could only get the SDK by ordering a CD. Not being the patient sort, I downloaded it internally (one of the many benefits of being b0rg). Now, all the impatient people can write speech enabled web apps, since the SDK showed up on MS Downloads today. Enjoy.