Monthly Archives: May 2013

Five tips for Writing a Presentation

I’ve had hundreds of chances to experiment with presentations, through teaching, invited talks, and day-to-day presentations at work. If there’s a mistake you can make in delivering a presentation, I’ve made it. Today, I’ll share with you the top five things I’ve learnt along the way — hopefully, they’ll help you write a great talk!

One major point

You’ve been asked to give a presentation that’s less than an hour in length. My advice: deliver one major theme or point to the audience – you want them to leave unambiguously ready to understand, believe, act, or follow the point you’ve made.

Don’t share two or more major points. The audience will leave with different key takeaways. Or, worse still, you’ll confuse the audience or seem rushed in your delivery. And you usually won’t land that key message that you want the audience to act on or evangelize for you.

What is a major point or theme? It depends on the length of the talk. If I was speaking for an hour, I’d design a talk that lands a broader theme than if I was speaking for fifteen minutes. For example, in an hour I might land “how to deliver a great presentation”. If I was speaking for fifteen minutes, I might land “tips for verbal presentations”.

What if you have to speak on two topics in one session? For example, your boss wants you to present to her boss on two topics next week. Write two talks: start and finish the first, change decks, and start and finish the second. Consider having question time between the two. Pretend you’re two different speakers coming up to the podium.

One slide every two minutes

Rule of thumb: one slide for every two minutes of presentation. A one hour talk, thirty slides maximum. A fifteen minute presentation, seven slides. Really.

If you fly through slides, you’ll seem rushed. If you stay on one slide, you’ll kill the audience with boredom.

If I’m speaking for an hour, I restrict myself to thirty slides maximum — I’m always tempted to have more, and every time I do I regret it. If anything, err on the side of caution: I’ve given a few one hour talks with twenty or fewer slides, and it’s worked out fine.

Keep the slides simple

A slide with the right amount of content

A slide with close to the maximum amount of content. I’ve delivered this one a few times, and it’s hard to get through it in two minutes.

I like to have four to six lines of text on a PowerPoint slide. I try to avoid sub-bullets. I definitely wouldn’t have more than eight lines of text; I know when I reach eight that I’ve got two slides of content.

I dislike quadrant slides, they’re too complex for a presentation. I dislike two-content slides too — the ones that have text on the left and an image on the right (or vice-versa). If I want to include an image, I typically make it the feature of the slide and accompany it with at most two lines of text above or below the image.

Signpost the structure

I include the following signposts in most talks I deliver:

  • A title slide, with talk title, my name, company, and contact information

    An example title slide with talk title, my name, company  and contact information

    An example title slide with talk title, my name, company and contact information

  • An overview slide that explains the structure of the talk to the audience; that way, they know what to expect, it helps them to know when to ask questions and what’s going to be explained

    An overview slide. Usually the second slide in my presentations, and there to outline the structure of the talk

    An overview slide. Usually the second slide in my presentations, and there to outline the structure of the talk

  • An occasional subsection slide that shows we’ve arrived at a major section in the talk

    A subsection slide that explains where we are in the talk structure. I'll typically include two or three of these in a longer talk, and they'll reference back to the overview slide

    A subsection slide that explains where we are in the talk structure. I’ll typically include two or three of these in a longer talk, and they’ll reference back to the overview slide

  • (Sometimes) A concluding slide that contains the key points from the presentation
  • A subsection slide that includes the phrase “Questions?” or “Q&A?”

    A final slide asking for questions (and doing a little advertising)

    A final slide asking for questions (and doing a little advertising)

I count these slides in my “two minutes per slide” rule; these don’t come as free extras.

Be careful with the colors, design, transitions, and builds

When you’ve got Microsoft’s Powerpoint as your tool (or something fancy such as prezi), it’s tempting to include lots of slide builds, transitions, zooming, and animation. Resist. These are very often a distraction — and can lead to your audience thinking you’re more about style than substance.

I particularly dislike builds. Why? Because it looks like you’re hiding something, and it doesn’t give the audience the chance to read, understand, and put what you’re saying in context.


I was fortunate to work with Justin Zobel for many years, and developed my early presentation style with his coaching. His book is worth the money — highly recommended for anyone who needs to write and present in the field of IT or computer science.

See you next week.

Changing platforms at Scale: Lessons from eBay

At eBay, we’ve been on a journey to modernize our platforms, and rebuild old, crufty systems as modern, flexible ones.

In 2011, Sri Shivananda, Mark Carges, and I decided to modernize our front-end development stack. We were building our web applications in v4, an entirely home-grown framework. It wasn’t intuitive to new engineers who joined eBay, they were familiar with industry standards we didn’t use, and we’d also built very tightly coupled balls of spaghetti code over many years. (That’s not a criticism of our engineers – every system gets crufty and unwieldy eventually; software has an effective timespan and then it needs to be replaced.)

Sri Shivananda, eBay Marketplaces' VP of Platform and Intrastructure

Sri Shivananda, eBay Marketplaces’ VP of Platform and Intrastructure

We set design goals for our new Raptor framework, including that we wanted to do a better job separating presentation from business logic. We also wanted better tools for engineers, faster code build times, better monitoring and alerting when problems occur, the ability to test changes without restarting our web servers, and a framework that was intuitive to engineers who joined from other companies. It was an ambitious project, and one that Sri’s lead as a successful revolution in the Marketplaces business. We now build software much faster than ever before, and we’ve rewritten major parts of the front-end systems. (And we’ve open sourced part of the framework.)

That’s the context, but what this post is really about is how you execute a change in platforms in a large company with complex software systems.

The “Steel Thread” Model

Mark Carges, eBay's Chief Technical Officer

Mark Carges, eBay’s Chief Technical Officer

Our CTO, Mark Carges, advocates building a “steel thread” use case when we rethink platforms. What he means is that when you build a new platform, build it at the same time as a single use case on top of the platform. That is, build a system with the platform, like a steel thread running end-to-end through everything we do.

A good platform team thinks broadly about all systems that’ll be built on the platform, and designs for the present and the future. The risk is they’ll build the whole thing – including features that no one ultimately needs for use cases that are three years away. Things change fast in this world. Large platform projects can go down very deep holes, and sometimes never come out.

The wisdom of the “steel thread” model is that the platform team still does the thinking, but it’s pushed by an application team to only fully design and build that parts that are immediately needed. The tension forces prioritization, tradeoffs, and a pragmatism in the platform team. Once you’re done with the first use case, you can move onto subsequent ones and build more of the platform.

Rebuilding the Search Results Page

Our first steel thread use case on Raptor was the eBay Marketplaces Search Results Page (the SRP). We picked this use case because it was hard: it’s our second-most trafficked page, and one of our most complex; building the SRP on Raptor would exercise the new platform extensively.

We co-located our new Raptor platform team – which was a small team by design – together with one of our most mission critical teams, the search frontend team. We declared that their success was mutually dependent: we’re not celebrating until the SRP is built on Raptor.

We asked the team to rebuild the SRP together. We asked for an aggressive timeline. We set bold goals. But there was one twist: build the same functionality and look-and-feel as the existing SRP. That is, we asked the team to only change one variable: change the platform. We asked them not to change an important second variable: the functionality of the site.

This turned out to be important. The end result – after much hard work – was a shiny new SRP code base:  modular, cleaner, simpler, and built on a modern platform.  But it looked and behaved the same as the old one. This allowed us to test one thing: is it equivalent for our customers to the old one?

Testing the new Search Results Page

We ran a few weeks of A/B tests, where we showed different customer populations the old and new search results page. Remember, they’re pretty much the same SRPs from the customers’ perspective. What we were looking for were subtle problems: was the new experience slower for some scenarios than the old one? Did it break in certain browsers on some platforms? Was it as reliable? Could we operate it as effectively? We could compare the populations and spot the differences reasonably easily.

This was a substantial change in our platforms and systems, and the answer wasn’t always perfect. We took the new SRP out of service a few times, fixed bugs, and put it back in. Ultimately, we deemed it a fine replacement in North America, and turned it on for all our customers in North America. The next few months saw us repeat the process across our other major markets (where there are subtle differences between our SRPs).

What’s important is that we didn’t change the look and feel or functionality at first: if we’d done that, we may not have seen several of the small problems we did see as fast as we saw them.

Keeping the old application

Another wise choice was we didn’t follow that old adage of “out with the old, and in with the new”. We kept the old SRP around running in our data centers for a few months, even though it wasn’t in service.

This gave us a fallback plan: when you make major changes, it’s never going to be entirely plain sailing. We knew that the new SRP would have problems, and that we’d want to take it out of service. When we did, we could put the old one back in service while we fixed the problem.

Eventually, we reached the confidence with our new SRP that we didn’t need the old one. And so it was retired, and the hardware put to other uses. That was over a year ago – it has been smooth sailing since.

The curse of dual-development

You might ask why we set bold goals and pushed the teams hard to build the new Raptor platform and the SRP. We like to do that at eBay, but there’s also a pragmatic reason: while there’s two SRP code bases, there’s twice the engineering going on.

Imagine that we’ve got a new idea for an improvement to the SRP. While we’re building the new SRP, the team has to add that idea to the new code base.  The team also has to get the idea into the old code base too – both so we can get it out to our customers, and so that we can carry out that careful testing I described earlier.

To prevent dual development slowing down our project, we declared a moratorium on features in the SRP for a couple of months. This was tough on the broader team – lots of folks want features from the search team, and we delayed all requests. The benefit was we could move much faster in building the new SRP, and getting it out to customers. Of course, a moratorium can’t go on for too long.

And then we changed the page

After we were done with the rollout, the SRP application team could move with speed on modernizing the functionality and look-and-feel of the search results page.

Ultimately, this became an important part of eBay 2.0, a  refresh of the site that we launched in 2012. And they’re now set up to move faster whenever they need to: we are testing more new ideas that improve the customer experience than we’ve been able to before, and that’s key to the continued technology-driven revolution at eBay.

See you next week.

Beta testing the Tesla Model S

My Tesla Model S

My Tesla Model S

I bought a Tesla Model S earlier this year. It’s a dream car: comfortable, responsive, spacious, and great looking. It’s a total geek dream gadget, and I feel good about owning an environmentally sensible electric car. It’s 95% of the way to perfect – and it’s fun being part of the ongoing experiment to find the last 5%.

Scheduled Software Updates

Tesla updates the car occasionally – the car has a 3G cell connection. A dialog box on the massive 17” screen says an update is available, you schedule it, and wake up to an improved car. It’s like updating iOS on your iPhone. Indeed, it’s very similar – your car could be quite different after the update, and it’s clear the car is designed to be a flexible software-driven platform. This is mostly where the beta testing feeling comes in.

Scheduled Charging

Scheduled charging. My car is configured to being charging at 1am when it's plugged in at home.

Scheduled charging. My car is configured to begin charging at 1am when it’s plugged in at home.

The most recent update added scheduled charging. You plug the car into its charge point, and it’ll start charging when you tell it – this allows you to take advantage of lower electricity rates in the early hours of the morning. What’s cool is that it is location-aware: you can set different charge behaviors for different locations, and the car remembers those. So, for example, you could have it charge as soon as it’s plugged in at work, and beginning at 1am at home – and once it’s set, it just works. Pretty neat. (I’m glad this feature arrived – I was beginning to figure out how to install a timer on my 50 Amp 220 volt plug at home.)

Plugged in for charging with the mobile charging cable.

Plugged in for charging with the mobile charging cable.

I actually got this new feature about a week ahead of everyone else. How? Well, I scheduled an update and it failed. I woke up to a dialog box that told me to call Tesla Service. The climate control didn’t work, the odometer read 0 miles, and a few other things were a little off – but the car was completely drivable. I called Tesla service, dreading the need to take it to their service center – but it was way simpler than that. The guy on the phone asked me when I’d next have the car parked for a couple of hours. They later logged into my car, remarking that “the packages were all there but didn’t unpack properly” (suggesting a Linux flavor to the car), and “cleaned things up”. When I got back to the car, all was great – everything back to normal, and I’m the first guy on the block with the latest software that includes scheduled charging.

Climate Control Problems

Climate control must be a harder problem than you’d think. It’s entirely automatic by default: you set the temperature, and the Model S looks after maintaining it. However, I get blasted with cold air most of the time – if you jump in the car when it’s warm outside, and ask for 70 degrees inside, it’ll get you there as fast as it can. And once it’s there, it’ll lower the fan speed until (I guess) it gets a couple of degrees warmer, and then it’ll Arctic blast again. It always feels like it’s not quite doing what I want – sometimes 70 degrees feels rather too warm, and other times I’m freezing. There must be subtlety in making this an awesome feature (maybe other car companies took a long time to get this right?): you want the occupants to be comfortable as soon as possible, but you also want them to have a pleasant time getting there. I bet there’s a software update coming.

Spinal Tap humor: the volume control and even the climate control fan settings go all the way to 11

Spinal Tap humor: the volume control and even the climate control fan settings go all the way to 11

The web browser and nav apps fall short

The giant 17” screen includes a web browser and a navigation application. The browser is about as basic as you’ll get: it doesn’t have autocomplete (with much-needed spelling correction), it doesn’t save form data, and it randomly seems to lose its history and cookies. It’s also got problems with its touch interface: you need to press a little above any link you want to click, and often a few times. The navigation application is ok, but has a few quirks: it’s always oriented so that north is facing up, which isn’t how I like to use navigation, and traffic data seems to update on its own frequency (even if you turn traffic on and off) – which can lead you into a jam. I am not quite sure whether the traffic data is used to determine routes – I suspect not yet ; it’s certainly not configurable to tell the navigation app whether you’d prefer a faster, shorter, non-highway, or highway route as in many other nav tools.

If the 17” screen has issues, you can reboot it by holding the two scroll wheels on the steering wheel. You can do this while you’re driving. You can reboot the screen behind the steering wheel separately by holding the two buttons above the scroll wheels. Again, no problem while you’re driving. This suggests there’s several physical or virtual machines in the Model S – at least one for each of the screens, and more behind running what’s needed to drive the car.

Am I unhappy? No. The future has arrived early – a car that’s as much software as hardware, and that can be iterated on and improved without you going near a service center. Is it entirely baked? Not yet. Do I love my Tesla Model S? Best car I’ve owned easily.

See you next week.

By the way, while I own a Tesla, I don’t own any shares in the company nor do I plan to buy any. I wish I did, after their spectacular rise in the past couple of weeks.

eBay Open House in Seattle on Tuesday May 14

eBay's Ken Moss, VP and General Manager of eBay's Seattle office

eBay’s Ken Moss, VP and General Manager of eBay’s Seattle office

Would you like to learn about some of the projects underway in the eBay Seattle office and have the chance to mingle with our leadership team and engineers?

eBay Seattle invites you to a keynote on Tuesday May 14 2013 by one of our Vice Presidents, Ken Moss.  The team will also present an overview of eBay’s architecture and a tour of our endeavors in the big data realm. The event is at the Meydenbauer Center in Bellevue, WA.

Please RSVP at