A Few Words on Technology Evangelism

I’m currently hiring for several open Web Service Evangelist positions at Amazon. I am writing this post in an attempt to explain just exactly what it is that I do for a living. If you read this and think “I can do that,” you should send me your resume with all possible haste.

So, how did I get started? I was the first Web Services Evangelist at Amazon and I’ve been doing the job for almost 3 years. I came to Amazon in the fall of 2002 and my official position was Senior Developer on the Amazon Associates team. There was an understanding that I would spend some small fraction of my time, perhaps 5 to 10%, helping out the then-new web services effort. That small fraction grew pretty quickly as I started to help out on the discussion boards and attended a couple of conferences. Interest in our web services was growing rapidly, and I knew enough about them to be able to describe them to others. Since I had a very strong development background, I had a reasonable amount of credibility when I was in front of an audience composed of developers and system architects. At my 6 month review, my then-manager suggested that I apply for the open evangelist position, and I did so. A couple of days later, in April of 2002, I was officially designated as the first-ever Web Services Evangelist at Amazon.com.

I immediately set out to make our services as well known as possible. I wrangled invitations to a number of conferences and user groups, and simply went out and started talking to anyone who would listen. Over time our Developer Relations team grew, and I was able to focus even more definitively on evangelism, which I defined as “getting the word out.” To add some structure to this activity, I worked with my manager to come up with a quarterly evangelism plan. While I can’t share the actual numbers from my plan, I can tell you about the activities that I am signed up to do each quarter:

• Speaking Engagements – I go out to conferences and user groups and deliver a presentation can vary in length from 30 on up to 90 minutes. I like to be informal where possible, with people shouting out questions and asking me to go off in unplanned directions, which I am happy to do, being mindful that I do always need to get through my presentation. With groups of 50 people or less this can actually work pretty well. With larger groups I am typically up on stage and the audience interaction is generally deferred to the official Q&A time. I vary my presentation from week to week and engagement to engagement, tailoring it to the topics that I want to focus on. I have found that it is vital to get a “read” on the audience before digging in. It is good to know if their interests lean more toward technical or business topics, what kinds of systems and languages they like to use, and so forth. It is fun to watch the audience for clues that they “get it” as I talk. If they are making notes, blogging, or whispering to their buddies, that’s usually a good sign. It is important to know that the personality of the audience actually varies greatly from country to country. People in the US are happy to interrupt, challenge, and even attempt to steer things toward their own interests. In Europe and Japan people are generally a bit more reserved (I hate to stereotype, but others have told me similar things).

  If I have a live internet connection, I will also do live presentations. If not, I have plenty of screen shots and also some short Camtasia movies at my disposal. It is important to be so comfortable enough up in front of a crowd that you are ready for any contingency — fussy video projectors, loss of power or connectivity, malfunctioning demos, and so forth. Just once, I found that I had been running on battery power when I thought I had been plugged in (the outlet turned out to be dead). Fortunately the alert popped up near the end of my talk, so I wasn’t too worried. Its important to have a sense of humor about all of this, and it never hurts to show up a bit early so as to have time to make sure that everything works as expected. I have never been heckled from the audience (although Dave Winer did try (unsuccessfully) to back me into a corner over patents once). After my last talk I was even asked for my autograph, which was kind of neat.

  I find about 1/3 of my speaking engagements on my own, another 1/3 come through PR, and the final 1/3 are unsolicited requests. Once I know that I will be in a particular city, I do my best to find other groups and developers to talk to while I am there. I also take care of all of my own travel planning and arrangements and I try to be as self-sufficient as possible. It is actually fun to be able to land in a new city, find my way around, and have a good time while doing it.

• Blogging – I regularly write entries for the AWS Blog. Material for the entries comes from things that I find while surfing the web, or reading one of the two dozen or so email newsletters that I receive each week. I also have a Technorati watchlist, and developers email interesting things to me several times per day. I have a quota of blog entries to write per quarter. I try to keep the tone on the blog light, enthusiastic, and positive, and I never forget that I am writing something that has my employer’s name on it. I will say that there was some trepidation within the company when I started the blog way back in November of 2004. We had been discussing the concept for quite a while, and various issues were raised from time to time. Finally, Ben Trott gave me a free trial key for Typepad, I created the account, made a few posts and told everyone at the company “guess what, we have a blog!”Since that time things have relaxed a bit and I have even helped other groups inside of Amazon create blogs of their own. Before posting, each new poster must go through Amazon’s media training, basically learning what we can and cannot say, and how to say it. Most of it is common sense, and I have never had any problems staying within the rules.

• White Papers – I spent the last two days writing a 3000 word technical article on the Mechanical Turk. This article will be published in the ACM Queue sometime this year. I like to write, although it sometimes seems like I am a very slow writer. I have no idea if 1500 words per day is a good pace or not. I actually spent the day offsite, working from the Kirkland Public Library. It was a nice place to work, until the fire alarm went off and we all had to leave.

• Developer Meetings – I try to do at least one 1-on-1 meeting with a current or aspiring AWS developer each week. When I travel to another city for a speaking engagement, I try to line up some developer meetings in advance. I announce my schedule on the blog, and people are not shy about getting in touch with me. I also do LinkedIn searches and a list of people that I’d like to meet in cities that I visit on a regular basis. I am also not shy about simply emailing people with meeting requests. One important result of these developer meetings is that I learn a whole lot about what developers like and don’t like about our services. I collect up all of this information each time that I travel, and then make sure that it gets back to the appropriate teams as soon as I get back to Seattle.

• Press Interviews – Interestingly enough, I have a “number” to meet on these, but I don’t do anything to make it happen. Requests come in to Amazon PR, either directly or through our agency, and the interview is set up. The agency prepares a briefing for me so that I know who I will be talking to, and then we do the call. I try really hard to explain things in a straightforward fashion, and I never forget that the person on the other end is writing (and perhaps recording) what I say, and that if all goes well it will end up in print exactly the way that I said it. Again, the Amazon media training is very helpful here. A few simple rules keep me out of trouble. I don’t talk about the future, I don’t talk about financials, and I don’t talk about our competition. In the case of numbers and financials, I keep out of trouble by simply not memorizing any of our quarterly or annual numbers. Trust me, even if I was drugged or brainwashed I couldn’t tell you a thing about our margins. our headcount, or the number of employees that we have. Besides, it would be a lot easier to simply look them up online! I have occasionally received phone calls from people who didn’t identify themselves as journalists, started asking some innocuous questions, and quickly tried to get me to admit to something. Fortunately I was able to figure out what was going on and pointed them at a real PR contact inside of the company.

• Sample Applications – I am supposed to be building a sample application or two each quarter, but so I’ve not been able to do so. I’ll definitely get a couple of them done this year. I really want to learn how to use Eclipse, and I need to spend more time inside of Visual Studio. I don’t want to be someone who “used to be a developer.” Personally, I feel that I have the most credibility when I can speak as a developer to other developers, but I know that this is not universally true for other technology evangelists — they are able to succeed without having deep, current developer credentials.

• Screen Casts – Last quarter I did a series of 4 screen casts on the [Amazon Mechanical Turk](http://www.mturk.com]. We used Webex and it worked out really well. In practice, screen casts are much different than live presentations. First, and foremost, there’s no way to see the audience, and you have no way to tell if you are reaching them, or if they are bored stiff. I’m still getting used to this aspect of screen casting. The Webex client includes both chat and Q&A facilities, which we used at the end of each session. When the questions started flowing in I became (in effect) the host of a talk radio show. I had several members of the development team in my office to help field the questions. The questions would come in via the Webex Q&A tool. I would read it into the speakerphone and then I would either answer it or turn it over to someone else. I even made up a “commercial” or two when we had some dead air. Lots of fun!

I hope that is it clear from what I have written that technology evangelism is a whole lot of fun. There are a number of reasons for this. First, we have a great product. Each time that I tell developers about each of our 7 different web services, I can see the wheels turning in their brains as they start to think about ways to use and make money with the services. Second, the developers are building cool and amazing things every day, and I get to see them and to demo them. Finally, nothing is static. I have to learn something new every single day. New technologies, new applications, new services, and even new buzzwords.

Ok, so that’s pretty much all I’ve got to say tonight. Once again, if you can see yourself doing many or all of these activities, it would be great to hear from you.

Like this story? Digg it!.