[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 aws.amazon.com/opensource 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 developermarketingpodcast.com or follow us on Twitter at @SlashdataHQ for regular updates.