Report on Self-Serve Trip Scheduling Experiment

At Amazon.com, innovation is one of our core values. Read on to learn how I was able to do something innovative with regard to the seemingly mundane task of trip planning.

A few months ago, in a post titled Toward a Future Without Email, I talked about my desire to reduce the amount of back and forth email required to set up a worthwhile itinerary for one of my evangelism trips. Within the scope of my job as web services evangelist, I travel all over the world, speaking at conferences, user groups, and private corporate events.

As part of each trip I also like to have 1-on-1 meetings with software developers in each destination city. These meetings allow me to learn a lot more about trends, concerns, and activity within our community. As I often tell my audiences, “I came out here to talk to you, but I really want you to talk to me.” There’s a very subtle and very important difference there. Having these conversations, creating these relationships, and becoming familiar with what’s going on has paid numerous dividends over the years.

Unfortunately, finding the “right” developers in each city wasn’t easy for me. Until I created my new self-serve scheduling system, there was no good way for me to locate the developers in each city that I should be talking to, much less spend the time needed to negotiate locations and schedule slots for each one. My team and I were able to find developers to meet with by posting to the Amazon Web Services blog, but scheduling individual meetings was very, very tedious. Getting all of the time slots lined up for something as complex as my recent trip to Utah required dozens of emails and hours of time.

As an experiment, I decided to try out a self-serve scheduling model. I invited interested developers use an online tool to put themselves onto my calendar. Interestingly enough, they all chose to use the Wiki, the least structured of all of the tools.

I am happy to report that this experiment has been very successful!

For example, I spent last week in Munich and London and had a number of wonderful meetings. I made a single blog post, Keep Me Busy in London, and the rest just happened without a lot of work on my part. I pre-filled the Wiki page with the anchor meetings for the trip and then simply opened up my schedule to the world at large. Practically speaking, there’s no way that I would have known enough to initiate any of the meetings that ended up on my calendar. I met a lot of interesting people and learned about a lot of interesting and creative uses of Amazon EC2, Amazon S3, and Amazon ECS.

I have found that people are very respectful of my time and always make sure that the meeting is worthwhile. They also know the local travel times and constraints and are going to be better than I am at figuring out just how much time I need between meetings. Also, having an open and visible schedule has led to several interesting and serendipitous situations where a meeting with one developer leads to suggestions of further meetings, joint efforts, and partnerships.

I also learned that it is important to do an email confirmation before each meeting. One promising meeting didn’t happen because I neglected to do this. I also found that the S3 Ajax Wiki had a bug which resulted in ever-increasing page load times as the page was edited and re-edited. One quick email to L.M. Orchard was all it took to get this fixed (Thanks, Les).

I am heading to Washington DC in early June and that trip is already looking good. I’ll be refining the details later this week. If you want to meet with me while I am there, feel free to get onto my schedule.

This self-serve model is now a standard aspect of my team’s planning process going forward. We will create a Wiki page with our anchor events, announce the trip on the AWS blog, and let the community do the rest. As a further step in this new direction (which will be announced on the other blog) we will soon allow developers to express desire for meetings in cities that are not yet in our travel plans.

Score one for innovation!