How to avoid blowing your presentation

You've finally got the opportunity to present your idea to the right VC with connections in your industry and a track record of success.  You rush out to work on your presentation pulling in all the data, industry trends, snappy graphics, and entertaining anecdotes that support your position.  You conclude with the big ask on the last slide having lead everyone inexorably to your stunning conclusion.  You wind up with 30 slides to present in your 15 minute slot.

And predictably, what happens?  You get through through two slides, there's lots of debate around irrelevant topics and you never come close to getting your point made.  In the last 20 seconds, you race to your last slide on a Hail Mary hoping someone will see the brilliance of your plan from your asks alone.  The meeting ends with a couple nice handshakes and we'll get back to you, which of course they never do. It's a wreck.

Obviously, you blew it, but what went wrong?  The problem was you designed a presentation you wanted to present, not one your audience wanted to hear.  I see this mistake made all the time, and not just with VC presentations, with all presentations.  So now, lets stop and think about how we avoid this mistake.  Go back to the beginning before you even start your presentation.

1. What is your goal for this presentation?

If you aren't clear on that, you're dead before you start.  You want to convince someone to invest.  In other settings, you want additional funding for your project, or to reorganize a team a particular way, or to shift to a particular strategy.  There's some reason you've gathered important people and are taking their time.  You want them to do something.  Be crystal clear with yourself about that before you even get started.

2. What does your audience need to hear?

The second biggest mistake I see is that people present what they want to say.  Perhaps they're proud of a slide they put together, or of the way they implemented something.  They want to talk about how good they are at something, but if the audience doesn't need to hear that, then you've just wasted the time.

3. Be Hyper Aware of the time.

In your most important presentations, you've got an opportunity with the attention of the people that matter.  But you don't have much time, and it's probably hard to get more.  Time is your most precious resource, and you don't have much so think through how you want to spend every minute.  If you've got 15 minutes or 3 hours, plan out how you want to spend it.  In a 15 minute presentation, I'd probably think through something like this:

• Get them interested (3 minutes)
• Give your pitch (5 minutes)
• Support it (2 minutes)
• Questions (5 minutes)

4. Grab their attention.

Most presenters are boring.  Not a little boring, really boring.  Plus the environment of a darkened room with 10-15 people around a table and a 15 minute slot isn't conducive to paying attention.  Right at the start, you've got to demand that people pay attention to you. If you're funny, say something funny, but be careful because it's really got to be funny.  Lame jokes don't get people's attention, they're just lame jokes.  I often like to start way out in left field.  A few times I've opened presentations by saying I want to talk about a "Really Important Topic" and then flash to a slide with the Boston Red Sox logo.  And then I start talking about the Red Sox, and people are hooked.  How am I going to tie that back to my main point?  Do I have a point?  Plus, the story of how the Sox beat the Yankees in the 2004 ALCS can't be told often enough.

5. Get to your point

Now that  you've got a goal, and you're aware of the time pressure you're under, and you've got their attention, now you need to make sure you get to the point.  Think carefully about every slide you put in front of your ask, because that's a potential rat hole that will prevent you from getting to your goal.  It's often a good idea to lead with the ask unsupported and have all of your clever analysis and details follow that up.  At a minimum, it ensures that you'll spend the time talking about what you want to talk about.  I've seen many meetings where you open with your conclusion, and everyone starts attacking it, and their questions often lead right into your supporting slides.  "Where did you come up with that revenue forecast?" "Why, I have that on the next slide..." etc.

6. Use words sparingly.  In general use pictures.   

A presentation should be a multi-media entertainment experience.  The fact that you're talking about the important topic you care about is an engineered coincidence to the observer.  Here's my aforementioned Boston Red Sox presentation (with where I was really leading them cut off).  You probably can't follow it.  That's the point. If I'm writing a presentation for you to read, then I've got to use words, but if it's something for me to present, then I speak all the words.  And there's no excuse for not finding good pictures.  With Bing Image Search, you can find the perfect picture in three clicks.  Can you use it legally?  Probably not...but most of the time you're presenting to 10 people who don't care about that.  If you're a presenter for a living and getting paid, then you better find images you're allowed to use.

There's a whole host of other material on how to give effective presentations out there, and I really consider this the basic "101" version.  If you don't think about these points, it doesn't matter how you use your dynamic range, the graphics, fonts, colors on your slides etc.  Your job in a presentation is to communicate and lead to decision, and you have to engineer your time and your delivery to get to that decision.

Facebook's HipHop not fast enough

Facebook developers announced and released HipHop, a compiler that takes PHP code and outputs C++ code to later be compiled by g++.  I'll disclaim that I haven't seen the source code (still not on github as I'm writing this) and am basing my conclusions only on their blog post, but I think there won't be a "tremendous impact" from this project.  It's basic cost/benefit analysis.

Benefits
The benefits are nearly great enough.  Only 50% CPU reduction?  Let's walk through the math of what that might mean for Facebook in terms of cost savings.  Their post says they do 400B PHP impressions per month, which works out to about 150k/sec.  That's a phenomenal number and a challenge for any site to perform at.  Facebook describes how PHP is used almost exclusively for the front end, and that the back end services are powered by Erlang, Java, Python, etc.  So if we assume they've got the front and back fairly well separated and can scale the front end based entirely on CPU load, we can make up some numbers to guess their total cost.

In my experience, even a poorly implemented PHP site can run around 20 requests per second on a single core.  Assuming Facebook uses beefy 8 core machines, that would be 160/sec per box, and 1,000 machines to serve their 150k/sec load.  Given that their load probably peaks with US traffic, and that they probably need double capacity to handle a co-location failing, I could see that going up to 4,000 machines.

Facebook has over 30,000 machines, most of which I'm sure are used to handle photos data and their tremendous memcached layer, so 4,000 web serving machines sounds about right.  At Facebook's scale, they can probably get a beefy 8 core machine relatively cheaply, but let's use $5k as a number, that means that saving 2,000 machines saves Facebook $10MM.  That's pretty impressive, but 2,000 machines compared against their total machine load of 30k isn't that impressive.  It's 7%.

Further, if we expect this to catch on and have a "tremendous impact" on the world at large, it would have to be a big benefit for all the small PHP sites out there.  I'd wager that almost all small sites are not bottlenecked on PHP CPU performance, but database performance instead.  Even if it was PHP performance, for most small sites the savings would likely be going from 30 machines to 15, which is almost unnoticeable.  For this system to be really effective, I'd want to see a speedup of 10-100x, not merely 2x.

Costs
So I've laid out that the savings aren't that great.  But they aren't nothing, a speedup of 2x which saves Facebook $10MM is pretty impressive.  but what does it cost.  I suspect the costs are pretty high and measured almost exclusively in terms of developer productivity.  Let's set aside the man year of development their lead developer spent developing this technology.  Facebook has to integrate this system into the development process, and there are two obvious ways.

1. Developers add a "compile" step to their development cycle and test using HipHop on their development boxes.  This, to me, would represent a worst case outcome (and from their blog post is almost certainly not what they do).  One of the many development speed benefits of scripted languages like PHP and Ruby comes from the fact that developers don't have a compile cycle.  While that compile cycle seems trivial (how hard is it to interrupt your code/test cycle with a 2 minute compile?) in my experience it's a large amount of the benefit.  Sure, dynamic typing is another major benefit, but I believe that if every Facebook developer now has to add a compile cycle, their overall productivity will plummet.

2. Alternatively (and more likely), they keep developers with an interpreted language on their dev box, and they move the compile step into the release process.  They indicate this in their blog post by talking about developers using HPHPi, their experimental interpreter.  The problem here is that you've now doubled your testing.  A developer writes his code and tests it locally using HPHPi, or even the standard PHP install.  After that, they have to compile it with HipHop and test it again to make sure the compiler didn't break anything.  If the compiler were a mature technology, you could probably skip this step, but with an experimental compiler you simply can't trust that it will work on your code.  Further, when you find an issue in production that you didn't anticipate, you're now not sure if it's the compiler or the code that is broken.  Given the difficulty of debugging live site bugs that often come about due to circumstances that are hard to duplicate in the test environment, this seems like a disaster.

So we're left with a system that doesn't provide enough benefit for the costs that will be associated with it.  A neat toy, but if I were Facebook, I would value the developer productivity way over the $10MM I might be able to save in server costs.  What do you think?

On Mark Pincus's NY Times interview: Responsibility and Accountability

Mark Pincus, founder/CEO of social gaming company Zynga, is interviewed in the NY Times Sunday on the topic of leadership and he touches on a couple of my favorite topics: delegation, responsibility and accountability.

You can manage 50 people through the strength of your personality and lack of sleep. You can touch them all in a week and make sure they’re all pointed in the right direction. By 150, it’s clear that that’s not going to scale, and you’ve got to find some way to keep everybody going in productive directions when you’re not in the room.

I met Mark once, and from what I could tell he operates at a frenetic pace all of the time.  So perhaps at that frenetic pace he can touch 50 people in a week, however the number for most mortals is much lower.  I max out around 20.  So if you plan to scale, you have to delegate effectively, and that's one of the biggest challenges people face when they turn into 2nd level managers.  You need to delegate completely so that you don't have to worry about the details of a particular function, but you also are still responsible for it being done properly.  So how do you know if the person you've delegated to is up to the task?

You have to first make it clear to everyone what they are responsible for and give them all the tools they need (Gallup Q12 #1 and #2).  One of the most important tools is the ability to make their own decisions in that framework (Zod axiom #4).  Once you've made the responsibilities clear, you then have to hold people accountable.  You have to set up the right mechanism to check in on people and make sure they're getting the work done properly so you can catch mistakes before they veer too far off course.  Setting milestones and regular reviews of them are key.  You trust your people to perform well, but you check on them anyhow.

Pincus continues:

One thing I did at my second company was to put white sticky sheets on the wall, and I put everyone’s name on one of the sheets, and I said, “By the end of the week, everybody needs to write what you’re C.E.O. of, and it needs to be something really meaningful.” And that way, everyone knows who’s C.E.O. of what and they know whom to ask instead of me. And it was really effective. People liked it. And there was nowhere to hide.  

Here I like the concept, but not the implementation.  By calling people C.E.O.'s he's making it clear that all of the responsibility and accountability goes to the person.  If you're CEO of selecting a phone system, then you are tasked with gathering the input from everyone, evaluating all the vendors and making the decision.  Important here is that you own the decision, there isn't a committee of deciders among which to share the responsibility.  The credit/blame resides fully with one person, and that provides accountability.

His implementation leaves something to be desired, however.  He's asking his team to sign up for responsibility and then he'll hold them accountable for it.  That will work provided that no two people sign up for the same responsibility, and that all of the responsibility you want to delegate gets assigned.  If two people both agree to be CEO of phone vendor selection, then now you've got a committee and shared decision making, which just doesn't work.  Further, if nobody signs up to select the phone vendor, then either you're left with that responsibility, or (more likely) the work won't get done.  So as a manager, you want to solicit input from your team on what they want to own, but ultimately you own the responsibility for dividing up your responsibility in a way to ensure everything is covered and nothing is left undone.