Under the Hood of Developer Marketing: Amazon’s Adam FitzGerald

We launch this series on Under the Hood of Developer Marketing with an interview with Adam Fitzgerald, who’s responsible for Developer Marketing at Amazon Web Services . In this series we interview leading practitioners in the Developer Marketing and Developer Relations field to find what this relatively new discipline means to them, how they execute, and how they measure success.

At Amazon, Adam oversees global technology evangelism, developer engagement programs, and community building. His technical interests include fault tolerant composable service architectures, infrastructure automation and data science. Prior to joining Amazon, Adam ran Developer Relations for Pivotal, VMware, SpringSource, and BEA Systems. He is a recovering mathematician (over 13 years since his last formal proof), regular swimmer, and aging gamer. Originally from England, he is now a Bay Area resident and proud geek parent


How long have you been in the role?

I have been with Amazon Web Services as the Head of Worldwide Developer Relations for four years.

Tell me about your path to Developer Relations?

I used to be a mathematician researching at the University of North Carolina. By the late 90’s I was getting less interested in academic work, and I had started writing my own software for fun, including a fantasy football app.

A friend of mine had a start up, teaching software development, he invited me to join and so I went to work with him. Between accepting the role and joining the company was acquired by BEA Systems, and I taught Java development for a few years.

I did some public talks that went really well, and I became an evangelist and “the demo guy” for Weblogic Server for a couple of years. Eventually I took over BEA’s developer program called “Dev2Dev”. This was the early 2000’s, and outside of companies like Microsoft and Apple there were not many developer programmes around.

I left in 2007 to join SpringSource an open source Java company created by Rod Johnson (the creator of the Spring framework). It was a really exciting time, and we built up a really successful business with a commercial version of Tomcat. We were acquired in 2009 by VMware and I took on developer relations for their Layer 2 business, which ultimately became Cloud Foundry.

The group was later spun out into Pivotal

I have been at AWS since 2013. I went there as I had worked with some of the people before and I admired the way AWS was disrupting the tech industry. It was a great opportunity to join a company that viewed developers as a key audience, primarily because AWS is an engineering led company. I joined to make sure AWS did developer marketing in a deliberate way. Now I run the global developer marketing team, and the start up marketing team.

How are you organized at AWS?

Over my career, I have run developer relations teams in both engineering and marketing teams – it tends to flip flop between both at different companies. At AWS developer marketing is part of the marketing organisation. We work in partnership with the engineering teams, and I firmly believe you can be successful wherever you report in, as long as you have the right charter and relationships.

We have over 90 services now at AWS from Compute, Storage, Networking, Databases, AI, ML, and IoT – that’s a lot of internal people to work with. Amazon and AWS are focused on getting product teams engaged with customers, and that feedback drives over 90% of the product features. The product leaders are in regular touch with their customers via executive briefings and customer advisory boards – it really is part of the company DNA.

Developer Marketing is a fairly new discipline, what is your perspective on the craft, and where do you think we currently are in its evolution?

It is still very much evolving, but, for me specifically, sometimes it is hard to remember what it is like to not think developers are not really important to businesses. I’m too long in the tooth to think in a non developer way. I’ve been very fortunate to work kind of inside a bubble with great people that have always understood that developers are important. When I meet other people in Developer Relations, it is a reminder that they are fighting with really basic issues like convincing their internal stakeholders why developers matter.

There is some straight forward methodology and thinking that could be built into a common framework. The last couple of years I have spoken in public about a few of those ideas like marginal value and multi-touch attribution. I think there is a movement towards a standard view of how we define what developer marketing does, or what it means to people. But developer relations is still far from seeing the clear structure and discipline you see in product management and product marketing. That said the explosion in the number of people working in developer relations has been amazing.

Do you see other developer relations practitioners sharing best practice?

Definitely! It’s hard for good developer relations work to stay a secret as it’s all taking place in the public eye. Successful developer marketing is very evident. The table stakes are well understood – great doc’s, which are well organised for inbound SEO traffic; digital and in person engagement with the community (Stackoverflow, Reddit, Hackdays, 3rd party events); you want to build community and celebrate people that are successful on your platform – developers want to hear from each other – independent voices endorsing your product.

The stuff that isn’t easy to spot is what goes on under the hood – how do you make decisions, secure funding, resource planning. I’ve shared more of that over the last couple of years.

How do you measure the success of your program?

The way I think about it is developer relations is divided into two halves from the customer perspective:

  1. What is the universe of developers that aren’t yet using your product or technology? There are some great metrics to understand here like addressable market, your SEO rank, consideration & preference, inbound web traffic, etc. But ultimately you are trying to work out how to turn non-users into users. You have to have a clear understanding of the paths they take to become a user of your product. It’s becoming more and more straightforward to map the triggers for this conversion.
  2. What is the universe of developers that are already using your product or technology? – What are they doing with your product? How often are they active? What tier of usage are they on? How deeply engaged are they (e.g. the number of products they use)? What is their financial contribution to the business?
    At AWS, we look at all this data to make determinations about the success of our developer programs.

Do you differentiate your GTM tactics for start-up developers and enterprise developers?

Developers have more in common with each other than differences, regardless of their employer. They want to learn new things, solve challenging problems, they don’t want to waste their time going down dead ends – they are very busy, and they will have to stop something they are currently doing to try something new. They also get pitched to and promised the moon and the stars all the time.

Developers also change jobs over their careers, so it is important to engage with them as a person rather than as a cog in a larger entity. For example, Capital One has made a massive transition from legacy technology to modern infrastructure on AWS and some of their development team have come from startups and non-profits.

Think of developers as connoisseurs of technology, so you need to build trust over time vs. treating them as a number on a spreadsheet to be converted. Once you help them become successful they can take those skills to any employer.

Describe the skills you look for in your team?

I’d like to think that I’m blind to people’s personal characteristics, I try to focus entirely on their technical credibility. Are they someone that understands developers? Are they someone our audience wants to listen to? Are developers going to believe what they are saying? I look for depth of knowledge about the technology – that doesn’t mean you have to be old like me, you can get that deep understanding early in your career if you have specialised.

What has been your biggest challenge?

Again, I’m lucky to work at AWS where the organization understands the value of developers. But I have seen at lots of organisations that see developers as a vehicle to achieve some other need or goal like market share, or revenue, or partner enablement. A developer that is on the end of that kind of treatment is going to see through that very quickly.

It’s important to realise developers are investing their intellectual capacity into the technology you are promoting – you are trying to convince people to do something in a different, better, way so you too have to completely believe in that technology. I think that’s probably the biggest challenge – representing that need for authenticity back to your internal stakeholders in the business.

More specifically, at AWS, our biggest challenge is our rate of growth – we launched over a 1,000 new features this year alone! That is a lot of technical ground to cover and it is only accelerating. Our team is growing quickly but it is hard to find technically credible people in all of these areas where AWS has products. We are always looking for talented technologists to join our team, and that’s going to continue.

What are you most proud of?

I would say there are two things.

I’m really proud of my time working with the Spring community and working with Rod Johnson. A lot of the things I learned came from that environment and it formed my foundational thinking around developer marketing. Spring still continues to be really relevant today.

Probably the most impactful thing I’ve done is building a proper programme of developer engagement at AWS. We have such an incredibly passionate collection of customers, it’s phenomenal. While AWS will run re:Invent this month, which will attract about 40,000 people, our AWS community is self-organizing their own developer conferences in the US, Japan, and Europe with thousands of attendees. They also run hundreds of meetups globally and the community has also created amazing open source projects, like the Open Guide to AWS hosted on Github, where users share best practices on AWS with each other.

SlashData measures developer satisfaction twice per year, across the industry’s 20+ leading developer programs. Want to find out more about our Developer Program Benchmarking research? Contact Chris at chris@slashdata.co

Unity leads the way in developer satisfaction

As software continues to eat the world (to paraphrase Marc Andreessen), software developers fulfill an ever more critical role in the progress of technology and, by extension, society. Supporting developer productivity is good for business. Those developers then become innovators – co-creators – that give a boost to your core business.

It’s also challenging. Developer programs consist of a myriad of activities, ranging from simple providing sample code and developer education, to tooling, to in-person events and online communication. It’s hard to be great at everything, and it’s hard to allocate effort and money effectively for maximum impact.

Every six months we benchmark top developer programs against each other. First, by measuring what developers value in those resources and activities, in all its diversity across several segments of the developer population. Second, by highlighting the best practice leaders: those vendors that are doing an excellent job in specific aspects of developer programs, to whom you can look for inspiration and insights on how to improve. There is no single leader across all of the 20 activities we measure – everyone can improve somewhere.

unity leads developer satisfaction

The top spot in terms of developer satisfaction is taken by Unity, with an overall developer satisfaction score of 75 out of 100. Unity shows exceptional performance on several attributes: tutorials, how-to videos & webinars, and official forums. This may be skewed by the fact that their products cater to a specific subset of developers (game developers) who might score attributes differently than others.

Google, Microsoft, and Mozilla are not only among the largest developer programs; they lead the pack in terms of developer satisfaction and engagement. Other major developer companies like Amazon, Facebook, Oracle, and Apple follow at some distance.

This doesn’t imply, however, that only the companies with the most traction and the biggest budgets can create excellent developer support programs. The living proof of that are Unity and Tencent. As we said, Unity has the highest developer satisfaction of all programs in our list. Tencent, the producer of WeChat who mostly addresses a geographical developer segment in China, has a developer satisfaction on par with Facebook and well beyond Twitter’s, and one of the highest levels of engagement in our survey. Other companies like Intel and Cisco may have moderate overall performances, but lead the way in important attributes such as training, technical support, or access to devices.

The study above shows data from the 12th edition SlashData Developer Economics survey. Over 21,200 respondents were asked which developer programs they used and how satisfied they are with them. These respondents came from 162 countries around the world and span mobile, desktop, IoT, cloud, AR/VR and machine learning developers and data scientists. The results were collected by SlashData over a period of six weeks between November and December 2016.

To access the full study drop us a note at sales@slashdata.co or download the brochure

Return on Developer Investment

My most fun job ever was as a C++ developer. Ok, I don’t have much grey hair yet, but I fondly remember the late 90s and the challenges of writing a background synchronisation application on a Compaq iPaq. And reverse engineering Mozilla’s Navigator into an XSLT parser.

My second most fun job ever has been building a company that helps the world understand developers, with research. We’ve come a long way – and a few pivots – from surveying the pulse of 400 developers in 2009 to 30,000 developers annually in 2016. That’s a lot of data – in fact more than our analyst team can chew.

It’s a privilege to be working with some of the biggest names in tech – I ‘ve learned a lot the past 2 years. Earlier this month, Amazon, Microsoft, Facebook, Adobe, Intel, Oracle and many more joined our first Future Developer Summit, and shared some of their best practices in how they work with developers. I ‘d like to share some the learnings here.

Return on Developer Investment.

You would think that with billions of dollars spent every year on building tools for developers, running hackathons, loyalty programs, tutorials and how-tos, evangelist and MVP programs – the platform leaders would have figured it all out. Yet, with so much money being spent on developer tools and marketing there is no standard for measuring the Return on Developer Investment.

Most companies represented at the Future Developer Summit shared how they measure success. At their inception, developer-facing orgs measure success by number of developers touched – but that’s a meaningless metric, a dinosaur from the age of print marketing. Some platforms are using NPS (net promoter score), polling their active developers once a year for how likely they are to recommend the platform. Many are informing product decisions based on developer comments (“will you ever fix that”?) – you’ll be surprised how many decisions are taken based on “the devs that I spoke to said..”.

Other developer relations teams are measuring success through the number of apps in the store, and the number of apps using signature APIs. In the case of open source projects, a popular metric is GitHub stars, forks and commits over time. The more sophisticated platforms track the Return on Developer Investment funnel from SDK downloads to app download and use. But there isn’t a consistent way to measure how the investments in hackathons, tutorials, how-tos, loaner devices, evangelism programs and some many more developer-facing activities are paying off for the likes of Google, Amazon and Facebook.

Quality of apps, not quantity.

Another theme of the Future Developer Summit was the need for quality, not quantity of applications at the start of an ecosystem. B2B ecosystems like Slack and Intuit prioritise quality; Poorly written messaging apps can damage not just the perception of Slack, but also the perception of chatbots in general. Similarly, a poorly written app for the QuickBooks platform can wreak havoc to sensitive financial data for thousands of small businesses. As a result both Slack and Intuit have very stringent app review processes, including weeks of testing, usability and security reviews. To improve quality for bots, Slack has pioneered a “Botness” program, bringing together bot platforms and leading bot developers; the aim is to “make bots suck less” i.e. improve the bot user experience and avert a long-term damage to the reputation of chat bots. There are already 250 members signed up and the next event is on November 4 in NYC .

The next Future Developer Summit will focus on best practices for developer relations. If you ‘d like to be part of the invite-only audience of platform leaders, register your interest at www.futuredeveloper.io


Flip of fortunes: making devices compatible with apps

There used to be a time when developers worked hard to make their apps compatible with devices. [tweetable]Nowadays, device makers are working hard to make handsets and tablets compatible with apps.[/tweetable]


  • Amazon built the Kindle Fire on the Android Open Source Platform in order to leverage Android’s developer ecosystem and adding value only in the missing parts of Android.

  • BlackBerry built a “runtime for Android” into its BB10 platform in an attempt to close the app gap with its main mobile OS competitors. Jolla used a similar tactic in its Sailfish OS.

  • And now Nokia has produced an Android phone, the Nokia X, against all expectations considering their focus on Windows Phone over the last years and the acquisition by Microsoft. The Nokia X is positioned as a low-end “stepping stone” device relative to the Windows Phone based Lumia range.

How did this flip of fortunes come about?

Why supporting Android apps is becoming a must

Apps used to be bite-sized additions to the functionality of the mobile device; individually unimportant except for a very small number of key apps. [tweetable]The bargaining power of app makers is clear from the financial results of developers – that’s to say: near zero.[/tweetable] Six years into modern smartphone platforms, a full 60% of developers are still below the “app poverty line”, i.e. earn less than $500 per app per month, according to our latest Developer Economics survey (download the full Q1 2014 edition for free).

However, apps in aggregate have now become a must-have and a big driver of competitive positions. It’s no longer enough to build your own app ecosystem, or even feasible for that matter. iOS and Android form a de-facto duopoly that is impossible to compete against. [tweetable]To survive as a mobile device maker you need to tap into Android’s app base[/tweetable] (as iOS is closed for other device makers).

To convince consumers to buy your device, you need apps. Not just any apps, mind you. The hot apps of the moment (they usually are found on iOS first, Android second), as well as a long tail of apps catering to every imaginable use case. They need to look good and be fully featured too – lowest common denominator apps won’t do if you want to put a device in the market.

To convince developers, you need to deliver many users at low development effort. The best way to do that is to produce an Android-compatible device. The second best way is to bet on HTML5 with many good cross-platform tools and advanced APIs – something that both Blackberry and Windows Phone have struggled with as well.

A good long-term strategy?

Both on the user and on the developer side of the ecosystem, device makers will fight a serious uphill battle if they don’t support Android. But is supporting Android a good strategy for Amazon, BlackBerry or Nokia in the long term?

For players like Amazon and possibly Nokia who add value on top of Android, the move is in principle sustainable. As we explained in an earlier article: you don’t need to make an OS to win in mobile. Amazon and Nokia are basically replacing Google’s cloud services with their own (and in Nokia’s case: Microsoft’s), and use the Android OS for all the rest. This enables them to add value where it really matters, i.e. where Android and Google are weak. In Amazon’s case it’s crystal clear: the e-commerce giant leverages its promotion prowess and credit cards on file to help app developers monetize better.

Device makers who try the Android compatibility approach can still lose out to fragmentation however. We argued in the Naked Android article that only a few companies in the world have the clout with developers to convince them to spend the effort on replacing cloud service APIs. GlassBoard developer Justin Williams illustrated that perfectly in his recent post, where he muses on whether or not to adapt his app to the Nokia X. (Short answer: he won’t.)

[tweetable]For Blackberry and Nokia-X-as-a-stepping-stone-to-Windows-Phone, there is little hope that supporting Android will get them out of the slump.[/tweetable] They might attract opportunistic developers looking for a few extra users, but those developers are not likely to add to the momentum of the Blackberry and Windows Phone ecosystems. “Moving up” to the native ecosystem on those devices means that developers need to rewrite their apps. This idea clashes with the opportunistic motivation that attracted them in the first place.

That’s my take. I’d love to hear your opinion. What do you think that device makers should do?

— Stijn

The Naked Android

It had become painfully clear to Android’s executives: they had officially lost control. Something had to be done. There was only one option: to strip Android naked. Senior Analyst Stijn Schuermans explains how Google made it tough for ambitious rascals to fork Android and dump Google.


It had become painfully clear to Android’s executives: they had officially lost control. The operating system had been forked by Amazon and too many Asian handset makers. Worse, it had become too easy to replace Google Play with a proprietary app store yet leverage existing Android apps; too easy to replace Google’s services (Maps) with 3rd party alternatives (Nokia’s HERE). Even the Android brand wasn’t the king of the hill anymore, being eclipsed by Samsung’s Galaxy.

Something had to be done. There was only one option: to strip Android naked. Continue reading The Naked Android

How to win in mobile without making your own OS

The battle for app ecosystems is over – iOS and Android have won. However, this is not the end of the war for mobile users. VisionMobile’s Senior Business Analyst Stijn Schuermans and Strategy Director Michael Vakulenko discuss how leading ecosystem players like Amazon and Facebook are competing for users without building operating systems.


The mobile industry is buzzing with new mobile operating system initiatives. Microsoft is betting big on Windows Phone. Intel and Samsung are cooperating on Tizen. Telefonica and Mozilla are leading the Firefox OS effort. The Jolla team (ex-Meego) is touting Sailfish OS. Ubuntu is extending its popular Linux distribution from desktop to mobile. Hundreds of crazy-smart engineers around the world are losing sleep as we speak to create the next big OS.

As it happens, operating system technology no longer matters that much in mobile.
Continue reading How to win in mobile without making your own OS

[Report] Enterprise App Developer Atlas

Presenting our latest report, the Enterpise App Developer Atlas. This is a map of the developer journey, featuring 481 developer tools across 27 tool sectors.

The enterprise app developer’s journey is a complex endeavour that must balance corporate security, legacy integration, custom cross platform coding, and emerging API Program business models. This Atlas is the ultimate guide for enterprise app developers who need to mobilise corporate assets across multiple platforms, deploy, test and market their app. The Enterprise App Developer Atlas helps developers make the right tool choices in order to reduce costs, increase revenues and capture new markets. The market is split into six distinct stages: integrate, develop, deploy, measure, market & monetise.

The image below presents a selection of the top-ranking tools for each market sector. For the full listings, [purchase_link id=”4190″ text=”download the full pdf” style=”link”].

To get a full size poster of this report mailed to you, courtesy of Intel, visit this page

VisionMobile - Enterprise App Developer Atlas

The Kindelization of Tablets, Part 2: The Silk Strategy

[Is Amazon’s Silk an elaborate attempt at avoiding privacy concerns? VisionMobile Product Manager, Stijn Schuermans, examines Amazon’s strategy and argues the reasoning behind a Kindle smartphone and the likely plans for licensing Silk]

The second in a series of articles where we expose the innovation frameworks behind Mobile Innovation Economics, this issue highlights the trend of of the Kindelization of tablets: specifically, Amazon’s Silk browser. As in our previous article, we believe that our analysis still holds true almost a year after its original release in December 2011.

The Kindle Fire and Silk are important developments that hint to the future of online retailing. The Kindle introduces new techniques to drive foot traffic into Amazon’s retail properties by subsidizing devices, rather than paying for search advertising. In turn, Silk is used to generate deep customer insight and expand shelf space. We expect Amazon to extend the Silk shelf space by licensing this browser to other tablet and smartphone makers, turning handset makers into Amazon Associates.

You can also download the full, 5-page report in pdf format here.

Continue reading The Kindelization of Tablets, Part 2: The Silk Strategy

The yellow brick road of app store monetisation

[Apple and Google dominate the app store game – but only in terms of size. Senior Analyst Andreas Pappas discusses the key success factors for app stores, why Google is lagging behind and how Amazon fits in the whole picture]

With Amazon challenging Google’s app market and Apple allegedly offering the best monetisation potential, several developers and analysts have put these claims to the test by comparing monetisation data across the three app markets. Differences in app store monetisation potential can have a significant impact on developer mindshare: developers will seek to leverage platforms that will make them more money.

Continue reading The yellow brick road of app store monetisation