Under the Hood of DevRel: Amazon’s Adam FitzGerald
Repost of an article I wrote for Slash Data. Since first publication, Adam has moved onto HashiCorp where he is VP, Developer Relations.
I’m excited to bring you an interview with Amazon’s Adam FitzGerald. 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 4 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 organised 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: 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. 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.
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.
