How do you measure the success of your developer-facing activities?

The Developer Program Leaders survey focuses on understanding “what makes a developer program successful” as viewed from the perspective of professionals in the field.

This survey brings you and the members of the DevRelX Community insights on how DevRel and Developer Marketing professionals:

  • Run their developer programs
  • Prioritise their work 
  • Segment their audience 
  • Measure success
  • Justify the value of their developer program to senior management and more!

If you are a DevRel, Developer Marketing, or Product Manager, your input is precious.

You may also think of it as an open-source initiative to better understand how the world understands the value of developer marketing and relations. 

In the survey, you will find questions such as:

What metrics do you use to measure the success and ROI of your developer program? Do you segment your audience?

These questions (and a few more) need your input. The latest wave of the Developer Program Leaders survey is now live. 

What you gain by responding:

  • Full access to the findings in an interactive session supported by SlashData’s research analysts, hosted within the DevRelX community
  • A chance to win exclusive DevRelX swag
  • You take part in a community effort to understand and improve how your peers work and set their strategy

How long is the survey? It is short. You’ll need ±8 minutes

Shape how the world understands the value of developer marketing and relations!  

Take this short survey.

The survey closes on November 14.

Under the Hood of Developer Marketing | Transcript | Developers are your competitive advantage with Adam FitzGerald

This is a transcript of the audio episode from our podcast. You can listen to the episode here.


[Jo] Welcome to “Under the Hood of Developer Marketing“, a podcast from SlashData. I’m Jo Stichbury, one of the senior analysts in the team and today I’m joined by Adam Fitzgerald. Adam, we’ve not met before. So I’ll give you a short description of my background and then I’ll ask you to tell me and the listeners about yourself. I have a fair amount of experience as a developer. I’m a mobile developer and since back in the early days, dealing with software for Symbian and I’ve also worked for Nokia plus a number of publishing companies. These days, I’m into technical writing, which I started when I realised just how difficult it was to find good explanations of difficult subjects. I’ve worked with a number of teams to grow developer portals and developer content to attract and retain developers. We worked together recently on the book “Developer Marketing: The Essential Guide” but we’ve not really met before.

[Jo] So perhaps could you tell us a bit about your bio and your background?

[Adam] I work for Amazon Web Services and have done so for the last five and a half years. I’m responsible for a few things at Amazon, including developer marketing, technical evangelism; I also am responsible for startup marketing and some aspects of enterprise strategy as well. So, a handful of things to do. I’ve been in the developer marketing and relations space for most of the last 15 years at various companies. And, I think developers are an incredibly important part of not just the technical ecosystem, but overall, for the general business. I think developers are the future for all businesses and that the companies that embrace and understand developers are the ones that are most likely to be successful. It’s a great place to spend your energy trying to help developers become successful. That’s been my big motivator for the majority of my career.

[Jo] So, before you were in your current role, what did you do? Where were you?

[Adam] Well, yeah, I’ll give you the express version. I started off as a mathematician at the University of North Carolina. But eventually, I grew a little bit tired of the academic work and I was already writing software for fun and as part of my research. A friend of mine had a startup that was teaching software development, as well as building an object-relational mapping tool. He asked me to join and I went to work for him. Shortly after I joined the company, we were acquired by BEA Systems and I worked for them for seven years. Starting off, I initially started teaching Java development for a few years. And then a bit server administration, business process management, web services and service-oriented architectures, all that kind of stuff. Eventually, I wound up becoming an evangelist for BEA. In fact, I wound up being the Demo Guy for web logic server for about a year, working directly for the CTO and doing demos at large events like JavaOne and BEA events. That led me to take over the developer marketing responsibility for BEA or the program we called Dev to dev, the DAB. At the time, there weren’t that many other companies that had developer marketing programs, pretty much Microsoft, Apple and us. So, it was a very small universe of companies that were really dedicated to thinking about developers. I left BEA in 2007 to join Spring Source, which was an open-source Java company created by Rod Johnson. There was created the Spring framework. It was a fantastic time. Super exciting for me. Spring was totally disrupting and changing the Java market. It was a great opportunity to go to a place where developers were the forefront of what mattered to the business. So, I worked with Rod and the spring source team for several years. We were acquired by VMWare in 2009 and I took on the responsibility to run the developer relations efforts with VMWare across their business. That later became product may now know is Cloud Foundry. I was part of the spin-out from VMWare to pivotal and I left not long after that, in 2013 to join AWS, largely because, you know, AWS was a company that spent a lot of time thinking about developers and, developers where clearly a critical part of their business. I knew a few people that were already working with Amazon and I had a chat with them about it and it was a great opportunity to come over and join a company that sought developers on their critical paths of success. And it’s been a really fantastic and engaging last five and a half years working for AWS.

[Jo] Yeah. Sounds amazing. And you really have worked your way up from development all the way through. So I think it makes a difference. Some people say you don’t really need to be a developer, but I do think if you’ve been there yourself you have a different perspective and maybe a different way of talking, which can help with communication. When you were a mathematician, did you think you’d end up in this kind of area and how do you think your self would see you now?

[Adam] No, there was no way, as a mathematician, I would have thought that this was ever going to work out. My concept of myself didn’t look anything like this. I was very much on the academic path; looking at faculty positions, teaching undergraduate mathematics, that kind of thing. The earlier version of myself wouldn’t recognise where I am now. But there is something that does -sort of- bridge across the two. And that was again, mathematics. There’s an awful lot of value in understanding the abstractions of different types of mathematics. Lots of people get caught up in the details of mathematics and way down in the weeds and implementing individual tasks or looking at particular numerical analysis or understanding particular partial differential equations. But my strength was always in mathematics, looking at the more abstract elements and sort of taking commonalities across a whole class of different things and looking at them in a different way. And that’s very, very true in the technology space. If you look at the big movements, over the last five or six years, whether it’s in machine learning or containerisation or serverless computing, they’re all really abstractions away from the individual implementation details to get to higher level constructs that allow you to operate more effectively. So, if you’re not afraid of diving into the details, but willing to see through the trees to see the actual forest, then that becomes really useful. And I’m far from a hands-on keyboard coder these days. I’m not going to be implementing very much. But my background, both mathematical and technical, I think it gives me the ability to sort of get in touch and organize the new technology logically in my mind, in a way to make sense for me. I think that’s where the mathematics has been a strength for me.

[Jo] I think I took a similar path to you. I was in academic chemistry. And I was spending hours a day standing in the lab cooking up various things. And it just happened that I was reading the Guardian one Saturday and there was a job advert I saw in software and I thought “I should give this a try”. They offered me a job and I switched and in many ways it was a fantastic opportunity, but because I didn’t have a degree in computer science, I didn’t have any real qualification with C. So I sat in the library at Imperial College where I was first cooking in chemistry, now learning C, and I always felt like… It’s got the label “imposter syndrome” these days. At that time, I didn’t really know what it was, but I never really felt like I knew what I was doing and everybody else did; because everybody else, must’ve learnt it at university. Looking at, it now, the thing that I really want to tell my younger self is that – actually- nobody else really knew either because the subject itself was evolving. C hadn’t been standardised at that point. So nobody knew what it was. What do you think you would tell your younger self? The mathematician who’s just starting to teach people Java in your friend’s company?

[Adam] I would say…I think there are fundamental parts of this, which is probably -maybe I’m generalizing too much here- but are kind of true for all of the developers that I know. And that is, curiosity. Curiosity is the most important part of being a developer. Technology moves so quickly that you can’t just sit there and be like “I’m only going to do exactly what’s being done for the last 10 years”. You’ve always got to learn something new. Maybe it’s a new language, maybe it’s a new framework. Maybe it’s a new area in which the technology is operating, maybe it’s a new platform, whether it’s cloud or mobile or whatever it is. But it doesn’t matter. There’s no sitting still. No technology is sitting still. If you’re a curious person, if you’re interested in looking and learning about something new, then this is great. This is a great thing to be doing. And that was, that was me in a nutshell. I was very restless in academia. I was always looking for something interesting and I basically got that first job because I self-taught me on how to build a website and pull and put myself though all the database stuff and I actually ran a fantasy football website off the math department computers for like three years without anybody knowing. That’s what got me the interview with my friend’s company. He saw all the things that I built and that I was self-taught and that gave him the confidence that I could not just be an academic but somebody that works in technology. So I really think that thinking about what is the next thing you want to learn, what are you curious about, what are the opportunities to develop and extend yourself, is really the driving force for a lot of developers. And I’ve been very fortunate at Amazon. It’s a great place to do exactly that. Not only because the platform – AWS is very, very broad and covers a whole spectrum of services and areas. We’ve got over 140 services that cover IoT, robotics, machine learning, data analytics, mobile, about anything you can think of. But it’s also the culture here. Amazon really invests and thinks about people that have this curiosity element to them. And there’s a collection of leadership principles Amazon espouses. One of them is the “learn and be curious” leadership principle where we expect the people that work at Amazon to take the time to go dive deeply into new areas and work out what’s happening now, understand it and how it applies to what they’re working on. It’s a driving force for the people that work at the company. I would say curiosity is the one thing I would keep reinforcing to my younger self.

[Jo] That’s a good one. And I should have told myself that too actually. I shouldn’t feel guilty about sitting in the library learning C – that it was definitely the right thing to be doing. So, I think I mentioned imposter syndrome, which I see as a big challenge that I’ve had to overcome. What would you say is a challenge that you’ve had? I mean, the book, when we wrote it, it was all about challenge. It was all about the journey in developer marketing. We ask every author in the book to describe not just the things that went right, but the things that went wrong, what they learned from them and pass on, basically, everything that is their primary experience. What would you say has been your biggest challenge? What have you learned from that?

[Adam] So I’d say, overall, the biggest challenge I’ve faced over the multiple places I’ve worked is getting businesspeople to understand the value of talking to developers. For those of us that have done software development or understand or believe that software is central to the innovation and the capability of today’s modern businesses, it would seem self-evident that developers are on this critical path of business success. For us it’s the obvious thing to do. But quite often, you wind up in situations where people are not aware -it’s not that they don’t understand; situations where business leaders are like “I’ve got to make the number”, “I’ve got to hit this target as a sales thing”, “there’s a Wall Str expectation”, “there’s something we need to deliver”. When you say “well, I want to go talk to developers” they respond with “well, what does that developer worth to me? What does that mean to me? That doesn’t help me. Why aren’t you helping me achieve some other kind of goals? They’re not buying anything”. I’ve been fortunate in some places such as Amazon Web Services and Spring Source where they totally understood that developers are a critical factor. Or other places I’ve worked where like “yeah, yeah, do your developer marketing thing, just help me get to my sales number and I won’t bother you”. The biggest challenge has always been saying “No. You really need to understand that talking to developers is a critical part of what means business success. A developer actually means something to you and might even mean that the solution you just sold your customer is actually going to get implemented in the right way and become successful for the customer or it’s actually going to result in more usage of your underlying product because developers actually operate at scale”. Developers don’t just say “Hey I’m using this one thing.” they say “All right, I’ve made this thing work. Now let’s use it a thousand times.”. Potentially, by engaging with developers, you actually open up your ecosystem to expose yourself to new customers and new opportunities that you wouldn’t have before by adding a new API or adding a new interface to whatever it was you’ve created. Helping the business understand the value of developers has been the biggest thing that I have faced again and again in lots of places. Even in places as forward-thinking as AWS or Spring Source, it’s still a very reasonable question to ask “what does the next developer mean on this platform? What is their value? What do they actually mean to us?” So understanding developer value has been sort of the crux of my introspection or the biggest lesson learned I’ve had in the years I’ve been doing developer marketing. I’m in a really concrete understanding of what that value means to the business and is the key way to talk to οther members of the business team and the key way to talk to leadership about how to fund programs that really engage with developers.

“Helping the business understand the value of developers has been the biggest thing that I have faced again and again in lots of places.”


[Jo] I see. Yeah. I was writing a blog post last week about developer relations and developer marketing and one of the things I was trying to write about was how you measure success. Certainly, with developer relations, that’s a very difficult one because you’re talking about building connections. It’s not a particularly measurable activity. Do you have metrics? What is your view or on KPIs and metrics so that you can talk to the business about the value of individuals or groups of developers?

[Adam] I think it’s really important for people in developer relations and developer marketing, not to the religious or overzealous about “this is the right thing to do because it’s the right thing to do and therefore you should listen” to come with a business sensibility. For most organizations, you’re a cost centre. You’re costing the company money either by your salary or by the program you’re executing or something, you are costing the company money. So, you should understand that the things you do have to deliver a commensurate value back. The KPI and the value depends upon how your company is structured. What does your company sell? What does your company do? What is it that matters? For example, if you’re selling packaged software, then what does one developer mean? Are they a buyer of that software? Are they an implementer of that software? Are they somebody that can access and make the software successful so you can get more revenue for the customer or sell more licenses? Here’s a great example of this. Like I said, developer relations has been around for a while. It wasn’t done by very many companies, but when I was at BEA, I remember chatting with some people at Microsoft and they were very clear that developers are important because they produced more people consuming Windows licenses and they actually had a model at the time that said one developer produced the sale of seven new Windows licenses because the people consuming the software created and that put a characteristic value around that developer, that they can then go take to the business. In the form of “we know how much seven new licenses of Windows software is to us. Therefore, going and grabbing a developer or engaging with the developer, we know what the value is for that developer.”. Similarly, when I worked at Spring Source, you know, Spring Source is an open source tool, right? It was used freely by millions of Java developers around the world. So each individual developer wasn’t actually that valuable to the business because the business wasn’t selling Spring. The business was actually selling an industrial-strength version of Tomcat for enterprises to use. It was much cheaper than Web Logic Server or Websphere. So, the value of the developer was very small. But the value of the developer audience aggregate was the path through which we could go sell Tomcat because by using Spring, it made Tomcat equivalent to these bold-fledge JTV containers. All we needed was Tomcat. You didn’t need all the heavyweight application server. So understanding what the developer meant to that business was very different than the Microsoft case. And then if you look at things like AWS, each individual developer winds up creating an account on AWS. There’s a generous free tier, but it expires after a year. So at a certain point, your credit card is going to get charged for the things you’re using with AWS. So AWS understands what your charging characteristics are, we understand what the average spend is on the account, we understand what services you’re using. So it’s very much an as-a-service model where we can define our customer lifetime value for that developer. The question about what a developer is worth can be answered much more empirically than we could have done in either the Spring Source example and the Microsoft example, right? You know, it depends on what business you’re working for. Do you understand what is the key performance indicator? What is the critical measure that you’re interested in? For me, you’ve got to be able to answer for the business “What is the next incremental developer worth to the business?” If you can answer that question with some kind of accuracy or some kind of real knowledge, then you can use that as your argument to the board or the CEO or your leadership and say “Hey, this is what the developers are worth. This is what they do. This is what they deliver to the business. Therefore, in order to gain more of these developers, you should fund me at this rate. You should give me these resources to accomplish that task.” You can use the same argument about writing documentation or running events or doing webinars. They all have something, some incremental value that changes the way the developers engage. If you know what the value of the developer is to your business, then you can use that to work out what you’re going to be doing to change those different channels or invest in those different channels. For me, that’s not much of a KPI because I’ve given you a “depends” answer, but it really depends on who your employer is. It depends on what your businesses is. You’ve got to be able to work a lot of those things out. There’s not one answer in all of developer relations.

“If you know what the value of the developer is to your business, then you can use that to work out what you’re going to be doing to change those different channels or invest in those different channels.”


[Jo] That’s right. And it seems it’s very much about the business recognizing that and recognizing the value of developers.

[Adam] Yeah, which is why I feel like I’ve had the same argument at every company I’ve been at, which is: developers are important and this is why. And this is why. That’s the conversation you have to have. If you’re in a situation where, the leadership doesn’t believe that, then you’re going to have a hard road. You’ve got to do a really good job of convincing them why developers really matter, and it depends upon what the product is. You know, each developer is very, very different. Each individual developer is very different. I see a lot of businesses these days are in this as-a-service model, right? So whether it’s a software-as-a-service or platform-as-a-service or infrastructure-as-a-service, and you actually think the, as-a-service model is a lot easier to compute developer value because you do have this customer lifetime value computation you can do, on trailing spend over multiple months. So those things are very, very easy to start thinking in that direction. But there’s still plenty of companies that sell packaged solutions or solutions to mobile, libraries that are delivered on mobile devices that just don’t look like that. Or it could be companies that have a partner ecosystem and so, they’re looking at developer relations to build integration points, then allow other partners to integrate with them. And the model there is completely different than thinking about it as an as-a-service model. There’s a lot of different challenges in developer marketing and I wouldn’t pretend to understand, you know, each market’s individual challenges. I would say “what is your business?” then let’s sit down and talk about your business and work out what does a developer mean to your business and then we can start talking about what your KPIs are, what things really matter to your business and how you demonstrate the value you’re providing.

[Jo] That’s really interesting. Yes, thank you. I think you’re going to have a queue of people wanting to talk to you about that.

[Adam] Well, you got to understand your business. Sometimes, that’s kind of our issue too.

[Jo] Yeah, absolutely. Let’s move on to talk briefly about the book “Developer Marketing: The Essential Guide”, it’s been a number of months since that was published at the Future Developer Summit 2018. It’s a book that pulls together a huge range of experience from a number of people that work at different companies, representing either the company or just talking more about their personal experience. We’ve had a range of contributors come on the podcast, like you. You worked on the foreword for the book.

[Adam] Yeah, yeah, that’s right. So actually I was at the Future Developer Summit in 2017. When Andreas, Nicholas and I were talking after the event, having a glass of wine. This is the first time I’d see all these real leaders across all these different companies that are brought together to talk about developer marketing. The idea of the book kind of got hatched out of that and Nicholas was super engaged and super excited about doing it and really drove the creation of that. And so I was like happy to help out in any kind of way I could. Unfortunately, I didn’t have the bandwidth to contribute to a chapter, but I was happy to write the foreword because I felt like the foreword sort of answered what I’ve been already talking about: the biggest challenge, which is how one goes to convince people that developers are the most important critical audience for the 21st century business. That’s something I believe. I believe technology is the driver of business innovation, first of all. So that can evolve. The masters of that technology are the developers not somebody inside the business. Third of all, the way that technology consumption has changed in the last 10 years, means the power of technology decision-making has shifted out of the IT department into active development. It’s because people, companies expect more out of their technology. They expect the technology to be more responsive to the business. And that same response is from customers saying “hey, why can’t I do this with my mobile phone? Why can’t this happen more quickly? Why can’t I just do this while I’m sitting on the train instead of by having to log on somewhere else?”. Consumers are expecting more agility out of their companies, out of the companies they do business with, out of the governments. They do, have responsibility for fast digital experience. The companies that don’t understand that, are not going to survive, they’re not going to become successful. The companies that do understand that, are going to realize very quickly that developers are the critical part here, and that’s why moving quickly and helping developers understand what your product or your technology is, and using developers as your competitive difference-maker, is so incredibly important. That’s one of the things I wanted to reinforce in the foreword: developers are at this point, because of the way the business has changed in the last 15 or 20 years and the power is in the hands of the developers. Understanding how to communicate with them and having a strategy for being able to communicate with them, better become an integral part of every business strategy. Because if they don’t, they’re going to lose out to the ones that do understand that element. For me, that was why I was super interested in writing the foreword; because it feels like it’s commensurate with the argument I’ve been making for the last 15 years about convincing business leaders about why developers matter. Basically, if you don’t believe that premise, then the rest of the book doesn’t mean much to you. You’ve got to believe that developers matter, in order for you to think there’s value in developer marketing.

“Developers are the critical part here, and that’s why moving quickly and helping developers understand what your product or your technology is and using developers as your competitive difference-maker, is so incredibly important.”


[Jo] Yes, and see the value of the book. As I edited the book, I saw this common theme come through every chapter and it seems like the commoditization of development, it’s become something that everybody expects. As you say, consumers have these expectations and developers have to follow through on that. The book has done remarkably well. We’ve gotten to 10 five star reviews on Amazon you’ll be pleased to hear. I think a lot of people are picking up on that, we’ve had a lot of feedback. And that’s why we’re having another edition with more chapters which echo a very similar theme. I want us to move on because we’ve been talking a lot about the business side of it and developers and developer communities is something that we’ve been talking a lot about on the podcast. I want to talk a little bit about diversity. How we can encourage people of different identities, how we can encourage diversity in a developer community. I wondered if you had any thoughts or if you’ve worked in any particular area to cover this?

[Adam] I think there are two parts to this that are really incredibly important. One is that diversity actually really increases the success of your business, whether it’s diverse viewpoints or diverse perspectives or diverse backgrounds or representation of the diversity of your customer base. It’s incredibly important in making sure that you’re building things for all people and anytime you have homogeneity you can totally miss on those opportunities. Actually having diverse representation inside your business, is good for your business, first of all. Secondly, technology has really suffered from the lack of diversity and I think it’s super important that we acknowledge that and try to address it. There are lots of things that Amazon does, where we’re trying to move in this direction.

“Diversity actually really increases the success of your business, whether it’s diverse viewpoints or diverse perspectives or diverse backgrounds or representation of the diversity of your customer base.”

At AWS in particular, we try to engage with diverse groups. We’ve sponsored multiple diverse nonprofit organizations over the last several years. We run diverse workshops inside the business. We engage very closely with various different programs. Externally, we run a diverse speakers bureau where we can identify excellent speakers from diverse backgrounds around the world. There’s a lot of parts where we think about that, but the most important part for me and somebody who runs an evangelism team is to try to think about how do we get those diverse voices public and visible to the people that are aspiring or interested or looking to join in technology. We want to make sure that it’s okay and very, very clear that’s fantastic to be from a diverse background. And there are two parts of that. One, we’ve got to find the people that are willing to be those champions and support them. If you are public and talking about these issues, the environment can get very, very taunting very, very quickly and we should have very strong stones, everybody in technology, so we’ve very low tolerance for that kind of behaviour. The brogrammer, the bro Programmer mentality, it’s just not okay. You know, I see this with people that I work with that are from diverse backgrounds that are in public-facing roles and I see sort of the backchannel and the DM messages that they receive from certain people with this stuff. This behaviour is just not okay and it’s from a lot of people who are across a broad technology spectrum. And the more we can acknowledge that that is not tolerated, the better off we’ll be. So, I want to encourage people to be very vocal and visible from diverse backgrounds and talk about their successes, but they should also talk about what their challenges are and we should surface those and have no tolerance for any other sorts of bad behaviour that I see too commonly in a technical environment.

[Jo] I totally agree, I think that’s a very important stunt. Another interesting thing I was reading a couple of days ago, it was about how you can encourage the employees to participate. So a very good example is that working women have got their time set aside to work, but the rest of their time is potentially taken up with family, childcare, whatever. They may have less time and opportunity to participate, say in open source or hackathons than other people who don’t have the additional second or third shift that often falls to women. So it looks like it needs to be part of the time that they devote to their work, that they can offer a slice of their time to an open source community for example, while they’re actually on the job. Is that, is that something that Amazon does? Because obviously, Google has their 20%. Does Amazon have any kind of policies for encouraging open source participation just to get your diverse workforce out there?

[Adam] We’re all active participants in open source and lots of different areas. I don’t think it’s necessarily rooted in diversity. We actually think open source as an incredibly important part of the technical ecosystem. It’s something that our customers really care about and we think is an important place where innovation occurs and you know, new ideas happen and it’s a way to build really collaborative environments where we work with other people. You can go to AWS at and actually, there’s a whole list of the ways that we contribute and participate in the open source community, whether it’s foundation membership, actual code contributions, open source projects that we lead. There are lots of different areas where open source matters and we’re active and actively engaged with them. This may be an assistance for diversity, but that’s not its primary purpose. I think the more important thing for diversity is that you want to make sure the internal culture of the company has the tools and mechanisms that make it very, very clear within the workforce that diverse interests, viewpoints and backgrounds are all completely the norm and anticipated at the company. I will say that AWS, it’s become a really great place for me as a parent and a family member. It’s a very understanding place when it comes to work-life balance. It’s a very understanding place when there’s a lot of work to be done, things need to be done. It’s very understanding when it comes to making sure that there’s enough appropriate representation across staff in various different roles, whether it’s gender or racial diversity. There are lots of different programs involved in Amazon that make it a great place to work whatever your background is and it’s something that we continue to focus on.

[Jo] Yes, that sounds great. I’ll definitely be looking for a few hackathons to come.

[Adam] Well there are lots of other challenges about hackathons. But there’s a collection of programs that we run. In AWS in particular, if you look at our events we’ve got a Code of Conduct Policy that’s very, very clear for all of our in-person events. We’ve got programs or large scale events, white summits and reinvent which is a cost event, but we have mechanisms for encouraging different diverse groups for attendance to those. We have programs at reinvent as well to help nursing mothers for example. So there are pieces of all sorts of programmatic support that goes into our marketing for technical communities. We’re trying to make an effort. I’m sure we can do better and I’d love to hear ways we can do better. We’re trying to make the effort to make it clear that any diverse background is accepted, welcome and encouraged to attend AWS events.

[Jo] Fantastic. Well, thank you very much, Adam. It’s been really interesting to talk to you. You’re clearly really passionate about developers and developer marketing and we really appreciated your contribution to the book, as well as kicking it off in 2017. Thank you and thank you to the listeners for listening to Under the Hood of Developer Marketing, the podcast devoted to developer marketing and relations. If you want to listen to more episodes. You could subscribe at or follow us on Twitter at @SlashdataHQ for regular updates.


What happens at a Future Developer Summit

(edited by Stathis Georgakopoulos)

A look back on the 2019 event.

On September 24 & 25 we opened the doors to the fourth edition of the Future Developer Summit. With Diversity (openness & inclusion) as the overlying theme, we welcomed 60 participants from 30 companies across industries and had prepared for the 1,5 days full of keynotes, two fireside chats, 12 lightning talks and two workshops, including some fun, interactive games.

Experience sharing is a must in the Future Developer Summit and we strongly believe in learning from each other’s mistakes and real career experiences. Let’s see how that went.


 Day 1

Open source as a drive for decision-making

Willie Tejada (VP and GM of Developer Relations and a Chief Developer Advocate, IBM) kicked off the Summit with his keynote and what better way to do it than talk about open enterprises and how companies benefit from using open-source software. He also mentioned IBM’s “Call for code” initiative that addresses climate change and natural disasters.

 Inclusion in your DevRel team

Remaining close to openness, Maru Ahues Bouza (Director of Developer Relations and Advocate for Diversity and Inclusion, Google) followed the keynote with a fireside chat. Maru had her story to share:

      When Maru started working in DevRel, she was the only woman and the only Latina (she is from Venezuela) in a team of 40 ;

      Today, in a team of 100, more than 25% are women and people of colour ;

      Specific diversity and inclusion goals have been set in hiring ;

      When it comes to strategic hires for building her DevRel team, she first hired developer advocates (called them “engineers with social skills”), then a program manager who created a programs team, followed by the operations team, and the strategy team.

What does “diversity” mean to Maru? She wants everyone in her team to feel included and to feel that their contributions matter: “I don’t think you can do diversity well if you don’t focus on inclusion. Hiring is important but making sure everyone in your teams feel included is critical. It is super important to set your people up for success.”

 How do you build a developer community from scratch?

That’s the question Diego Moreira (Director, Products & Partnerships, Facebook) took on answering with tips to build a 200k+ developer community from scratch. He pointed at educating, helping the innovation process, and bringing people across the globe together as the three main components of Facebook’s strategy. He also shared Facebook’s initiative in Sudan. 

How can diversity help your team?

“Diverse developer relations teams serve the needs of diverse developer communities around the world” said Lori Fraleigh (Senior Director of Developer Relations, Samsung). Here are some more hot takes from her speech:

      Developers in certain regions (Japan, China) prefer materials to be translated into local languages whereas in other regions (Germany) developers are fine with English ;

      DevRel teams need to be sensitive to local and cultural norms, even when planning the start and end times of meetings ;

      Failing is learning. Lori also shared her personal failure story about how she made it to TechCrunch, with a funny twist. While at Motorola, her name was attached to an article referring at the upcoming Motorola device and mentioning it would not be reflashable. Developers were not kind in their feedback, but as she said “failures make for good stories down the road” ;

      Ensuring diversity within an organization takes constant work. Different people and cultures have different expectations, and you should never underestimate a minority faction.

Building an inclusive developer community

Leandro Margulis (VP & GM of Developer Relations, TomTom) was all about offering real tips we can start using as soon as possible:

      In the sign-up form, instead of asking for first and last name, just ask for full name and do some smart processing in the background to figure it out ;

      Localization is key ;

      When possible, use inclusive maps with place names in local languages ;

      “Your developer program should cater to real persons and people – not to the typical, and wrong, stereotype of a developer one gets from the movies” Leandro said.

 DevRel team, assemble!

What have your failures and successes taught you about building four developer relations teams? That was one for Tim Falls (Director of Community, DigitalOcean). He stated that “systemic organizational issues are fixable – if they are acknowledged as broken” and shared a story about revising a team compensation structure that was unfair and misguided. Inclusion is always key, so he offered tips and lessons learned from working with a team member with mental illness: acknowledge and honor the need for accommodations related to their mental health, make sure HR is in the loop and seek help and feedback from mental health experts when you need, be open and understanding and always try to learn as much as you can so you can meet the needs of your team members. “Some teams are too good to stay together. You need to foster an environment that nurtures individual expansion and attracts talented people to achieve healthy retention” he said about having such an environment that helps people excel and grow, even if they leave to join another company or start their own.

 The first day was wrapped up in a relaxed atmosphere with dinner, wine, and a Silicon Valley sunset.


Future Developer Summit 2019

Day 2

How and why to engage Millennial developers

Diane Prescott (General Manager of Business Planning, Microsoft) kicked off day 2 of the Future Developer Summit with a sociocultural approach towards millennial developers.

      Millennials (currently 23-38 year-olds) form 33%+ of the US workforce and 50% of the global workforce ;

      They are more likely to work in organizations that have been operating for less than 10 years;

      They are more likely to be primary decision-makers for cloud-only apps ;

      They leverage the community and their personal networks, significantly more than earlier generations ;

      “It is best to meet customers and developers where they are, with all their unique preferences and attitudes and developer programs need to take this into account.” Diane said and emphasized that it is equally important to look not only at your customers but also learn from your non-customers.

 What does “relations” in developer relations mean?

The second fireside chat of the event was led by Quinton Wall (Senior Director of Developer Marketing, Twilio) who took over in placing “relations” in “developer relations”.

      “Developers don’t necessarily associate themselves with a company, but rather with a technology and a community – even if developers change their employer, they remain loyal to the technologies they are familiar with” ;

      When it comes to diversity and inclusion, he made a point of looking beyond university graduates and has made hires directly from hackathons – people who learned to code without a university degree ; 

      While it is important to grow your developer community, it is equally important to look at empowerment and activation: how to make your developers successful. It is paramount to understand what your developers are doing and how they are using your platform. They might even use it for completely different purposes than what you built it for. The community manager and others should constantly monitor developer feedback and pass it on to product teams ;

      People talk to people, not companies. First focus on hiring strong developer advocates – people advocating FOR the developer inside the company – and then community managers developers can talk to ;

 Developer trends

That was one for us. As the analyst of the developer economy, we /Data, through our data scientist Michael Carraz, presented the latest on developer trends:

      Who developers are ;

      What they buy ;

      Where they are going ;

      What are the top development areas ;

      What lead to the success of Kubernetes ;

      Which are the developer persona characteristics ;

      What are the upcoming trends in development ;

      What are the features each successful developer program should offer. 

 Workshop time: How to build a developer program from scratch with $2 million.

After being updated in all industry trends, it was time for our first interactive workshop. Time to put words into action – or even more precisely, put our money where our mouth is. We asked the participants to spend a virtual budget of $2M towards building from scratch a developer program within 12 months. They needed to prioritize and decide where they would invest in people and activities. Teams came up with various scenarios based on their assumptions and constraints. 

 Time to talk (developer) personas

We’ve talked about developer personas in the past. We even run webinars on it. Luke Kilpatrick (Senior Manager, Developer Marketing, Nutanix) discussed the four types of developers they take into consideration when it comes to segmentation:

      Marketplace developers (they build apps and sell them) ;

      API consumers (the integrators) ;

      Tools (developers with purchase power) ; and 

      Developer Required (you need developers to sell your product).

He also discussed developer program success KPIs and gave us all the early hires that are needed in Developer Marketing: content writer, evangelist, researcher, community manager, support engineer. Luke also offered a few quick tips on how to build a developer program from scratch, from the chapter he wrote for our new book “Developer Marketing + Relations: The Essential Guide .

 Overcoming corporate hurdles

Developer program leaders often ask how we can help them get the corporate buy-in. Francisco Romero (Head of Open Innovation Programs, Amadeus) addressed this and gave us a peek on how to overcome corporate hurdles to build a developer program. Changing the mindset of top management is a series of smaller achievements including: setting goals that are aligned with the company’s goals and bottom line, creating internal alliances and partnerships on a 1-2-1 level, building the support at different organisational levels, communicating the risks of no action, managing risks and expectations by preparing beforehand to have the means to deliver what is promised. 

Lightning talks, lightning tips

These are the hottest tips from the lightning talks of day 2:

      To create successful developer events, you need to address all areas: audience, branding, content, location, logistics, staff, and marketing. | Sidney Maestre (Head of Developer Evangelism, Xero) ;

      Diversity doesn’t come easy, you need to implement various diversity initiatives to really add gender diversity to the engineering teams. | Sara Chipps (Director of Public Q&A, StackOverflow) ;

      Within your developer marketing team, you really need to manage expectations, build real relationships, and win as a team | Nick Schwartz (Sr. Director, Financial Technology Developer Engagement, Banco Santander) ;

      At Cisco, the ideal is to create a diverse DevNet community where software meets hardware and software developers meet network engineers. At the same time, if you want to build great API experiences, you need to listen to developer feedback and create a customized API style guide along with an internal API community and tools. Amanda Whaley (Sr Director of Developer Experience, Cisco) ;

      Being customer-obsessed boosted our NPS by +20% in just one year. You need customized API strategy for each developer type, you need to earn the right to invest in future value, and ecosystem obsession is a team sport. Acknowledgement, action, and transparency are in the secret sauce for customer satisfaction. | Cassie Divine (Senior Vice President, QuickBooks Online Platform, Intuit) & Jarred Keneally (Director of Developer Relations, Intuit) ;

      The evolution of a developer platform has these stages: early days, crossing the chasm, growth and maturity. When moving from the early days to crossing the chasm, users expect easy-to-use apps from your program and developers expect easy-to-use tools and infrastructure. When moving from crossing the chasm to growth and maturity, users expect rich quality experiences and developers expect to be able to run a successful business. The developer relations role sits in the intersection of technology and people. | Ellie Powers (Director of Product, Platform | Slack).

 The first 5 people in your DevRel team.

Back to work. For our second workshop, participants had to staff their DevRel team with its first 5 people. Loads of combinations were presented, but most included: community manager, partner engineer, developer marketing manager, tech writer, developer advocate, support engineer, and partnerships manager.  

To conclude

Brad Meiseles (Senior Director of Engineering at VMware) delivered the closing keynote. The focus was on the Kubernetes community best practices and how it has changed and is still changing the way we work. Kubernetes is now one of the top open-source projects ever and it took 5 years to reach to the top. The reason behind its success is very simple: its community of kindness, open to all, created by developers for developers.

Nothing makes diversity sound better than a live Latin jazz band to accompany the closing dinner.

In retrospect, the Future Developer Summit 2019 had a lot to offer to the Developer Marketing and Relations world, more to those who attended it. We hope to see all of you at our next Future Developer Summit where the theme will be no other than Open Source. Stay tuned for the event date!

Future Developer Summit 2019

Developer Relations vs Developer Marketing Which Side are You On?

Have you ever wondered what the difference is between developer marketing and developer relations? And what is the difference between  an advocate and evangelist? Just who is behind those developer portals you use for the developer documentation and who answers your queries on official forums? Read on to find out!

In this blog post, I’ll set out to disambiguate the roles within a company’s developer outreach team and explain what each person does and where they focus their attention.

If you are a developer, you have likely visited a number of portals and joined communities over the years, some successful and some less so. You’ll find it interesting to know the inside story on how they are put together and what happens behind the scenes.

If you work with developers, or are planning to, you’ll also find this post useful, particularly if you are considering building a developer community, or funding one. It’s also likely to be something that you need to consider if you already have a nascent community running already but want to push into the next level of the developer community maturity model.

Here at /Data, our Developer Program Benchmarking reports track how developers perceive individual developer programs. Twice per year, we measure developer adoption, engagement, and satisfaction across the industry, reaching over 40,000 developers in more than 165 countries. Our data shows that developers visit the top developer portals at least once per week and, on average, developers report to be involved with 3.1 different developer communities. These days, development uptake revolves around community, and your outreach team is likely to have a huge bearing on your success. So, without further digression, let’s dive in to the structure of a typical developer outreach team.

Developer product engineering

What is a company’s developer product? Well, it could be a Github repo that you clone, or an installable tool. it could be a zip file that you download, maybe it’s an API, maybe it’s a library or a package. It’s something you use if you are a developer — and somebody made it. That person, or group of people, sit in the developer product team.

The developer product team can range from a handful of developers to hundreds of people in big organisations. This team is responsible for setting out their product strategy & roadmap, for developing the product and its supporting documentation & sample code, plus tooling, and libraries and IDE integration where relevant. They will be the know how behind the technical support provided when you need it.

Their goal is to develop the best product for you, the audience, in terms of its usability and relevance. They will want to know how to improve their offering to you, and also want to be able to demonstrate to their company that they are worthy of what has been invested in them.

Many product teams would agree that the marketing metrics of “who read our blog?” or “ how many twitter followers do we have?” don’t really apply to them. In our recent book, Developer Marketing: The Essential Guide,  Pablo & Rex of Arm’s developer ecosystem team, made the point that their goal is to help developers’ code run better on Arm products, and their efforts in this direction is what they need to measure. Their approach is to educate themselves on their developer audience so well that they find a unique way to serve them and make their lives better, thus raising their awareness of the company. In the book, they describe how they spent time meeting developers and listening to woes about a particular development workflow. They set out to build a tool to smooth out the experience for developers, and set themselves a target for the installation process to get a developer up and running in under 5 minutes.

Developer relations

Now we’ve seen into the team building the developer product, let’s turn to the main interface between that team and developers using their output: those working in developer relations. Their goal is to build credibility, trust and influence with developers for the company they represent.

Many people struggle with working out exactly how to pin down the role of developer relations, and those working in it may alternatively be labelled community manager, developer evangelists or advocate. The role incorporates some marketing, but it also fits alongside the product group and within engineering. We’ve described previously that developers don’t trust always marketing, so developer relations is often seen as the bridge or connector between the two. Developer relations is about field work: working with developers to help them understand how to use the developer product. Some of the activities you may find developer relations working on include:


– public speaking

– attending hackathons and contests

– writing sample code and running demos

– social media (including technical blogging)

– attending events and meetups

– hosting office hours

A role in two parts

The developer relations team has two distinct ways of working. Part of their responsibility is evangelism: to communicate the company’s message to external developers. They may find themselves explaining which features are available and which are not, yet.

Conversely, the other part of their job is advocacy: to convey the developers’ views back to the product team. Developer relations practitioners are familiar with saying “I’m getting very strong feedback from people who use X that we should actually include feature Y and not Z”, and defend specific feature requests to the product team.

It’s a very important role, advocating on behalf of the developers to the company and evangelising the company to the developers. It’s also something of a balancing act at times. In our recent podcast with Mary Thengvall, author of a recent book about developer relations and well-established community builder, she said:

… you’re constantly going back to the company with feedback from the community or turning around and explaining to the community why a product roadmap looks the way that it does and why those are the decisions you’ve made. You find that you’re explaining why we’ve made decisions or what best practices we have decided to follow. There’s a lot of storytelling in there, fitting your knowledge to the perspective of the person that you are talking to. Taking the feedback from the developer audience and the technical audience and communicating that in a way that the product team and the stakeholders and the company are going to understand and vice versa, taking the business speak from your stakeholders and communicating that back out into the community in a way that they understand…”.

Developer relations people are responsible for building connections, then stepping back and letting other people do their jobs. For example, they make an introduction between a community member and a recruiter, or they connect an active community member to someone at the marketing team, to write a blog post. The developer relations team are not responsible for hiring the person or publishing the blog, and it may or may not happen. But the connection was made and it can bring value to the company, ultimately, so that’s the job. It isn’t measurable in terms of sales numbers or marketing numbers or traditional business metrics.

Developer marketing

Working in developer marketing, the focus is to encourage developers to learn about, try out, adopt, use and contribute to a software product. This is the team that defines the target audience by building a model of developer segmentation and personas. They also create the developer marketing strategy and product go-to-market plans, and work on outreach channels of social media, content marketing, email campaigns and blogs. Some developer marketeers will be in teams that establish developer rewards programs and early access programs for software or hardware; other, smaller teams, will be focussed on growing an audience via sponsored events and meetups.

There’s a great chapter in Developer Marketing: The Essential Guide, by Ana and Christine of Qualcomm, who talk about building a developer community around hardware. They describe the process of narrowing down the target audience for the community around their Snapdragon 410E processor. It was

‘…to let a thousand flowers bloom: to make it as easy as possible to use, to build up a broad community and channel, then see where biggest leads came from and tune the business approach along the way. That’s a difficult place for developer marketing to work.

“Who is our target audience?” we asked.

“Lots of people,” the product team told us.

“What will they make with the board?”

“Lots of things. You know, for the Internet of Things.”

“Can you identify a few key vertical segments to focus on for our initial campaigns?”

“Why would we do that? We need to position the product as broadly as possible.”…’

As they say in the book, it wasn’t exactly a well-defined target audience and clear direction, but that is as succinct a description of the place that a developer marketing team finds itself as I’ve ever seen!  

And finally…

The following table illustrates the subdivision between roles as I’ve described them above. Please let me know in the comments if you think I missed anything about the roles, or if you have good (or bad!) examples of how they work together to allow the developer outreach team to engage with its community.

dev rel vs dev marketing

Under the Hood of Developer Marketing: Microsoft’s Jeff Sandquist

Developer Marketing – what is it, why is it important, how to develop it successfully? We’ve interviewed Jeff Sandquist, General Manager on the Cloud and Enterprise Team at Microsoft, to share with us his experiences. This interview is part of our Under the Hood of Developer Marketing series where we ask leading practitioners what Developer Marketing and Developer relations mean to them, what they do to make it happen, and how they measure success.

Continue reading Under the Hood of Developer Marketing: Microsoft’s Jeff Sandquist

Under the Hood of Developer Marketing: Grace Francisco from Roblox

In our latest installment of interview series with the leaders in developer marketing and developer relations, we talked to Grace Francisco, VP of Developer Relations at Roblox.  Grace shared with us her experiences building developer relations programs, the challenges her team encounters and how they measure success.

Grace is VP of Developer Relations at Roblox. She is responsible for leading developer and educational programs and engaging with a growing community of 3+ million developers to empower them across multiple platforms. A seasoned developer relations leader with over 12 years of experience, she has co-authored three patents and led worldwide developer initiatives at Microsoft, Intuit, and Atlassian. Prior to joining Roblox, she established Atlassian’s Global Developer Relations organization to nurture and expand their rapidly growing developer community. She is also a celebrated diversity advocate, establishing and driving diversity programs, including mentoring rings, at Microsoft and Atlassian. Grace graduated cum laude and holds a BBA in Business Management from Golden Gate University.

developer marketing, developer relations, grace francisco, roblox


How long have you been in the role?

I have been in this current role for a year and it has been a fantastic adventure so far. This is my first foray into a consumer-facing service as all my other roles have been enterprise focused, so this has been a refreshing change. The other aspect of my job that makes this experience special is the developers we get to work with that are a vital part of the Roblox community. Specifically, I am referring to what we call emerging developers – first-time developers – creating their first ever experiences on the Roblox platform.
What was your journey to Developer Relations?

I left home at 17 and worked my way through college for nearly 10 years. I was fortunate to find my way into tech during this time. I did development work without a degree for some time and earned a couple of patents along the way while I was an engineer at Lotus/IBM.

I eventually wanted a change and went into technical marketing and then pre-sales engineering at Borland. After that, I went to Microsoft to be a developer evangelist on their first enterprise developer suite which was called Visual Studio Team System (VSTS) at the time. I thought I had reached the pinnacle of my career while at Microsoft, but actually, it was just the start! I was at Microsoft for eight years in a variety of developer relations roles from VSTS to leading the planning of (a developer focused transparency channel) to driving web and open source initiatives.

I have since led and built teams at Intuit, Yodlee, Atlassian, and now Roblox.

So in your evangelism role were you on the road, developing content, etc?

At Microsoft, I enabled the worldwide field evangelists who were the employees on the road in their local markets. I built out a lot of content – samples, demos, decks, and train the trainer materials. I also met with strategic customers and partners. Some of the partners I worked with in my VSTS days were “frenemies” – they were competitors in the space we had just entered but our joint customers wanted a seamless experience from their tools to ours. I really enjoyed looking for win/win situations that served the best interests of both companies.
Back to your current Roblox role, how are you organized?

The developer relations organization is its own organization, reporting to the Chief Business Officer. Marketing, engineering, and product are all peer teams to our organization. I have four core groups reporting to me in our developer relations organization – Top Dev Programs, Developer Community, Information Experience and Education, and DevRel Operations.

What are your team’s responsibilities?

We focus primarily on providing resources that are designed to accelerate the success of developers on the Roblox platform. We have a rapidly growing audience of over three million developers who have largely grown out of our player community. We are focused on creating great self-serve content and education, as well as building a self-nurturing community whose goals is to provide our creator community the resources they need to build imaginative, immersive experiences on our platform. We also provide our education partners with core content which they extend and deliver in summer camps and after-school programs or build into their existing class curriculums.

We accelerate the success of our top developers via two highly competitive, onsite internship programs called Accelerator and Incubator. These two programs are either three months or five months long and take place twice a year (Spring and Summer). The programs are designed to bring young developers into Roblox to learn best practices in game design, marketing, and monetisation and have direct lines of communication with our engineering teams as they work to either create a new experience on Roblox or update a current one. The interns provide valuable, ongoing feedback about the tools and resources available on the Roblox platform that helps us continue to evolve and improve Roblox both for the developer community as well as the community at-large.

Do you recruit from these programs?

We don’t actively recruit permanent employees from our Accelerator and Incubator programs. The intent of both programs is to help developers either build new, successful games or improve existing ones. Our top developers are also now forming their own design and development studios where they collaborate with others in the community to build and monetise their experiences on Roblox. Others decide that they really like the idea of working in a bigger company that includes benefits and other employee perks, have had a good intern experience, and therefore pursue opportunities at Roblox. Given the success of top developers on the Roblox platform (over $30M paid out in 2017 with top devs earning over $250,000 per month with their games), it’s easy to see why.

You have a very different audience to the typical developer program!

Our core player audience is 9 to 13 years old. Our top developers are in their late teens to early twenties and many started on Roblox as 8, 9 or 10 year old members of the community. This emerging developer audience has the ability to build content that resonates in a special way with our core audience. They build unique experiences like “Work at a Pizza Place” – one of our top games – where players simulate working life in a pizza parlor. These are highly imaginative experiences that are less likely to come from an adult developer. We find that many young people have this “a-ha” moment between the ages of 10 and 12 when they self-determine that they want to build something themselves on Roblox. Our developer tools and hosting platform are free which lowers the barrier to entry, and many developers are making really good money from their games. As their games grow and become more popular Roblox provides the backend support to ensure a quality of play that our community expects.

How do you approach the ethical side of marketing to children?

We’re COPPA compliant and follow industry guidelines and policies related to marketing to children. We are also implementing GDPR by the May 2018 compliance deadline.
Do you describe your work as DevRel or Developer Marketing, or something else?

I think of these areas as distinctly separate. Credible developer relations is about the technical conversation, enablement, and relationships whereas marketing tends to be about higher level messaging and broadcast to create leads and new customers.

You have to be able to initiate and carry on a very authentic conversion with engineers, so I know many organisations are careful about separating Developer Marketing & Developer Relations.

Do you share/discuss best practice with other practitioners?

Yes, I attend and speak at different developer relations conferences and meetups. We have similar challenges – How do you do things at scale? What are the right platforms and technologies to create great content and API docs? How do you identify best practices to nurture those developers? At Roblox, we just use the extra lens that our audience is particularly young.

Is your program International?

Our platform is being used globally, so for us, it’s about how we support language-specific ecosystems. We recently released a localisation tool and we are building out data centers in key markets around the world to ensure the best experience for our player and developer communities. Now we are looking at how we incentivise developers to be first movers within non-English-speaking markets, to build native experiences that will appeal to local markets and help Roblox gain market share. We have to keep in mind that developers in these new markets are typically very young so the opportunity may not be apparent for them.

How do you measure the success of your program?

We keep track of the number of developers on the platform, metrics around game quality, play time, engagement and retention metrics. We also invest in helping our developers understand why these are important.

What has been your biggest challenge?

Over the past year, a big focus has been hiring and building up the organization and putting processes in place to help us scale the business as we grow. The developer relations team has grown from two to 20 people really quickly, so we are expecting to get a lot done over the next year. We take cultural fit really seriously. What stands out here is the level of collaboration between teams and a genuine sense of wanting to help each other out to get work done. We have a collegial atmosphere and this is the most polite engineering organization I have worked with to date!

What are you most proud of?

A lot of people burn out in this line of work. I have been doing it since 2004 and I’m really proud that I have been able to navigate the waters in various roles at multiple companies and continue growing in this boutique field. I’m one of a few long-standing developer relations experts in the field and have often been consulted for my expertise. I’m proud of the teams I’ve built over the years and our achievements. I have always sought more knowledge and information and I am convinced that if you want to continue to push the boundaries and continue learning new technologies, best practices, and new information, these are the best roles you could wish for.

What’s next?

I believe we are creating a new category of entertainment, but it didn’t start out that way. The original vision was an educational tool to help teach physics but quickly morphed into content and games as students began working with the physics engine to create their own experiences. Only now are we beginning to fulfill the original vision around education and as we have grown, we are seeing the type of engagement on the Roblox platform that is reserved for some of the largest entertainment platforms (ie. YouTube, Facebook, Netflix, etc.). Given this popularity and our focus on education, we are now getting into educational curriculums and building relationships with large educational institutions who will be integrating Roblox into their various programs, which our founder is really happy about.

We aspire to have school programs in the future which is no easy feat given the understandably high bar set by formal educational institutions. However, we’ve made great progress so far with nationwide organisations to run summer camps and after-school programs and there is clear interest from the education community in the Roblox platform.

We’re continuing to scale up what we’re doing with our top developers to ensure the same level of support and services are available to the masses of developers we have on the platform. We’re building the next waves of top developers in much larger cohorts and doing so for a global market.


Liked this article? Read also our interviews with Intel’s Scott Apeland and Amazon’s Adam Fitzgerald to learn more about Developer Marketing best practices.

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

Under the Hood of Developer Marketing: Intel’s Scott Apeland

Developer Marketing – what is it, why is it important, how to develop it successfully? We’ve interviewed Scott Apeland who leads the Developer Program at Intel to share with us what it takes to succeed in this rapidly expanding field. This interview is part of our Under the Hood of Developer Marketing series where we ask leading practitioners what Developer Marketing and Developer relations mean to them, what they do to make it happen, and how they measure success.

Continue reading Under the Hood of Developer Marketing: Intel’s Scott Apeland

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