April 30, 2015

On Evangelism

Warning: this will be a long blog post.

Very frequently I am asked, by different organizations and individuals, what would be the best strategy to reach out to developers, build a community, and create a positive “buzz” related to a specific technology. Or, how to do Evangelism. I have decided to spend a long and lazy evening to share my thoughts on the subject, and the result is this blog post. I hope that many people will find this helpful, and of course comments and suggestions are more than welcome. To be clear, this is more about how a Company can do Evangelism, rather than how an individual can be an Evangelist. Good? Let’s start.

First, let me introduce myself.

avatar_vmworld [Simone Brunozzi keynoting at VMWorld 2014 in San Francisco]

I have been an “Evangelist” more or less since 2004, when for a few years I voluntarily spent time and effort to drive adoption of Linux Ubuntu, alongside my other jobs (entrepreneur, Professor, CTO). Thank to that experience and a lot of sane stubbornness and hard work, I landed a job as a Technology Evangelist at Amazon Web Services (or AWS) in early 2008, and left Italy to travel the world. Back then, most people dismissed AWS as Jeff Bezos’ risky bet, and the business was way, way smaller that the current 1.5B$ revenues per QUARTER, as recently reported. When I started, Europe only had Amazon S3, and in the United States there were only two EC2 availability zones. There were no data centers other than those. My role was to “evangelize” people on AWS’ technology: it meant being a public speaker at 100+ events per year, engaging with the community, dealing with developers and customers on a daily basis, and becoming a “bridge” between product and customers. I wrote “Letter to a Technology Evangelist” and “Being a Technology Evangelist”, two years apart, where I shared some of my thoughts on how to do my job. (if you are interested in how to be an individual Evangelist, these two posts are a good start). I was Technology Evangelist for EMEA (Europe, Middle East and Africa) for about 2 years, then for APAC (Asia Pacific), then for Americas. I used to travel A TON. This map shows you the places I’ve visited during my first 5 years at AWS. It includes exotic places like Australia, New Zealand, Iceland, South Africa, Korea, Japan, Hong Kong, Bhutan, Estonia, Israel, and pretty much any other country with some sort of IT industry.


Last year, I left to become Chief Technologist at VMware, still focusing on Cloud technologies. Part of my activity is still related to Evangelism, although I usually target a much more diverse crowd, which now includes a lot of large enterprise companies.

The rest of the post will focus on Evangelism, and how a company should define it and execute it.

1) What’s your technology? What’s your mission?

A company should start by defining what’s the technology that they want to promote, and what’s the mission. I will use an hypothetical company that doesn’t exist in reality. Let’s call it Simon Cloud - a new startup that provides cloud services, very much like what AWS (at a larger scale) does today. Let’s assume that Simon Cloud wants to be the next generation Cloud Provider, embracing containerization, microservices, and agile development. It targets developers right now, and in the future will also target larger organizations. Simon Cloud was created by looking at the pain points of current Cloud Computing offering, and found the following: a) Cloud Computing is great to start with, but costs get out of control when the usage grows. b) Need to learn new skills to use Cloud c) Annoying lock-in after you start using many of the ancillary services d) Hard to manage existing IT infrastructure together with It that sits in the Cloud. Simon Cloud is a small startup, and they can’t boil the ocean. They can’t really solve issue D for now, but they think they can defuse the first three issues by offering a very simple solution where you use APIs to buy/sell hardware, and “rent” data center capacity where you can put that hardware you just bought. An additional benefit is that you can bring those machines back into your own data center, if that’s what you want (which reduces issue C, and possibly** A**). They also offer a very nice, sleak User Interface (UI), and a great UX (User Experience, which is how users interact with the service). On issue B, they have created some great documentation that explains everything in detail, and they also want to launch a huge education effort to make sure that Computer Science and Engineering students become familiar with their technology and will later adopt it. The mission, of course, is to become the new, big and bold Cloud Computing provider of choice. Our goal is to help them “spread the message”. That’s when Technology Evangelism comes into play. Ok, let’s look inside.

2) Evangelism strategies

There are many ways in which you ┬ácan do evangelism. Let’s cover a strategy that would help Simon Cloud, assuming that the strategy would be executed over the course of 4-5 years, during which Simon Cloud grows from being a small startup to a huge company, ready to IPO (or, in other words, ready to “go public”).

At first, your technology should brilliantly solve a problem, even if that problem is specific to a fraction of your market. That’s how you find your first enthusiasts. In Simon Cloud’s case, we are solving the problem that many startups have with Cloud providers: they just need “easy” hardware, or easy capacity, and they don’t want to deal with telephone calls or long setup processes, nor they need additional services pre-baked by the Cloud Provider. Existing players, such as AWS, Azure, Google Compute, Digital Ocean, Rackspace, or VMware’s vCloud Air, they all have a relatively simple way to get started, but none of them offers a pure, simple, “co-location” option that is offered on-demand, via a simple web interface or an API.

In this case, the strategy is to find early adopters, meet them and get to know them, and understand why they are adopting Simon Cloud instead of the other incumbents. Then, you capture these stories and use them as material to start “evangelizing” and create your own story. “Find your story” is your first step. Second, you should “create a movement”, or in other words, find ways to multiply your impact by enabling other people to tell your story, or their story, and thus contributing to the company’s momentum. Third, when a movement grows, it tends to “split” into sub-movements, because of different ways of thinking or different preferences. To avoid **“losing customers” to other technologies or competitors, you should create a connection between the technology that you provide and the customers that use it. It simply means to tell their story to your company, and make sure that the whole group feels ownership for the technology, and feels in control of where the it is going. An example that I really like is [Microsoft’s publicly available roadmap**](http://www.microsoft.com/en-us/server-cloud/roadmap/recently-available.aspx). Find your story, create a movement, connect customers and company. Fourth point is to “create a legacy”, or to find ways in which your technology will have a lasting impact in the world. How? For example, by finding partners that can build on top or around your technology, and dramatically increase your outreach. This last point cannot be solely done with evangelism, but evangelism is a critical aspect of succeeding at doing this.

Now that we’re done with strategies, let’s see how execution would work.

3) Execution

During my last two years at Amazon Web Services, between 2012 and 2014, I increasingly got involved in creating an identity for the Technology Evangelism group. A culmination of that effort resulted in the TES internal events (Technology Evangelism Summit), where every product team had a chance to discuss the product in front of the entire Evangelism team, making sure they would know how to evangelize it, and where Evangelists themselves had the opportunity to share ideas, discuss, and take action.

The trick about executing an Evangelism strategy is a lot about teamwork, and how this team interacts with the rest of the company. The following can probably be applied to many other situations as well.

First, the team you build should have a clear vision of where you want to go. They need to know that the current team of, say, 4 people, will grow to be a 30 person team in four years time, and that the tactical execution will evolve based on team size, and maturity of the technology offered by Simon Cloud. Each individual should know what this means for his/her career, potentially allowing them to carve out a specific role that they love, and that fits in that strategy. Evangelism is a very tricky career path; it’s kind of an hybrid, between a purely technical role, a semi-technical role like Solutions Architect / Sales Engineer, and a Marketing/Sales/Business Development role. Some people want to be evangelists for their entire life. Some others like to be evangelists as a way to share with the world their passion with coding and technology. Some others see it as an intermediate step. You should know these things, and how they will affect your team. Especially at the beginning, spend time with them and make sure they understand all the implications of their career choice, and where they want their career to evolve next.

Second, you should build a process machine, where with little overhead you can track, measure, and correct what each individual does. I have personally NEVER seen an Evangelism team adopt these tactics, possibly because evangelists are seen as special, weird individuals that travel an insane amount of time and have enough intelligence and smartness to be able to contribute to the success of the company. Well, this is wrong. On one side, you should allow creativity and initiative to flourish, but at the same time you want to map these activities into something meaningful and, where possible, measurable. Actually, to be more precise, EVERY time I have seen teams adopt some of these tactics, results have been amazing, but so far I have NEVER seem a team programmatically and systematically adopt a process framework for Evangelism. Let me give you a personal example on how this would work. Every quarter, or sometimes every two quarters, I would meet with EVERY product manager at AWS, including the ones whose product wasn’t launched yet. I would first try to understand the product, or the new iteration of the product; then understand what problem they were going to solve; and then discuss which strategy would be best in evangelizing that specific product to the masses, including deciding which conferences made sense, which audiences we wanted to attract, etc. Then I would do tens of events, some of which would give me the opportunity to talk about that particular product. I would create a report on these events, which customers I spoke to, and metrics related to how many people went to my presentation on Slideshare, or how many retweeted my presentation, and where possible how many asked for AWS credits. Then I would sit down with the same product manager, and try to get metrics on adoption and signups, trying to understand correlation between these and the conferences that I did. In that way, I had a process to provide Evangelism to a specific product, and somehow measure its effects. This example shows how an individual (in that case, me), following a process, could provide an output that would fit in a general framework.

Third (and this is something that I was unable to fully achieve at AWS, for internal reasons), you should get support from the rest of the company on things you need to operate more effectively and efficiently. Example? You might need budget, and some headcounts, to create a “champions program”, where you have a selected group of individuals that you treat in a special way, but at the same time you need tools to capture and measure that interaction. As an example, if you give these individuals a certain number of credit coupons, to try out the service, you NEED the tool to investigate which of these coupons have been redeemed, and how these customers are growing in size over time. That details tells you how effective that individual is, and will become your best friend to ask for an increase in budget for the following year. At the end of the day, someone in the company always wants to know that if they put 100,000$ in that bucket, the bucket will return an X amount within a certain period of time. Another example? You might need tools to monitor social media activity related to your “fleet” of evangelists that are presenting at events all over the world (and perhaps use it also to monitor how your “champions” are performing). The tricky part here is to understand how to convince the company to give you these resources. You need to know how politics work at your company, and you need to know what you can leverage to move money to your projects. In Simon Cloud’s hypotetical case, they want to use education as a way to minimize issue B (need to learn new skills to use Cloud), and maybe your team wants to take charge of it. That would partially fit into evangelism, and partially be an initiative that could stand alone. In that case, it’s up to the individual running Evangelism to decide if he can take responsibility for a separate project, knowing that only part of that project will be strictly related to evangelism. In any case, I am a firm believer in the importance of education as a way to gain marketshare and become a thought leader, true for any technology company. Evangelism has limitations, and that’s where education comes into play.

4) Conclusions

I told you it was going to be a long post. There would be so much more to discuss, but my time is up for now. I hope that you found this piece useful, and that your company will benefit from it in their evangelism efforts. Feel free to comment here, and if you really liked it, please share it online, or discuss it on Hacker News.