What exactly does it mean to be a Developer Advocate and what roles do they play in the development community?
In this episode, we talk to Geertjan Wielenga, author of “Developer, Advocate!” who answers what a Developer Advocate actually does and who qualifies as one. He also discusses the ethics of Developer Advocacy, the challenges in connecting and interacting with the developer community, and how he was able to gather information and learning experiences from 32 fellow developer advocates.
- Geertjan Wielenga tells us what exactly a developer advocate is.
- Wielenga talks about his book Developer Advocate, where he talked to 32 of the industry's most prominent developer advocates and why he decided to put developer advocates on the spotlight.
- What’s the most common career path towards getting a developer advocate job?
- What are the most common skills that developer advocates need to have?
- What was the process behind choosing the 32 developer advocates for his book?
- How do developer advocates identify the difference between a “developer advocate” and a “developer evangelist”?
- What strategies do advocates take when they advocate their technology to non-technical or non-IT people?
- Where does a developer advocate’s allegiance lie?
Our guest for today is an open source enthusiast, with a long developer advocacy history in and around Java, having worked at Sun Microsystems and Oracle, and now at Azul. He interviewed developer relations folks around the world for ‘Developer, Advocate!’ the book which we’ll talk about today, and he currently works on Foojay.io, a place for friends of OpenJDK.
Joining us today for a round of cocktails is Geertjan Wielenga. Hi GJ, great to have you on the show! And I'm sorry if I butchered your name.
It was perfect. Thank you for having me! It's great to be here.
Alright, great! So now, before we get started, we'd like to remind our viewers and our listeners that you can get into a deep dive of today's episode by visiting our page, torocloud.com/podcast, where we'll have a full transcript of this podcast episode, show notes, as well as links to resources to be mentioned in the show.
You can also download our iPaaS, Martini for free! Martini is Toro Cloud’s integration platform without limits. Take charge of your business using a single solution to manage all of your data across applications, databases and business processes. Try it out and discover why it's the highest-rated iPaaS on G2! Visit torocloud.com/martini to learn more.
Alright, GJ. So, I'm just gonna refer to you as GJ from now on. We're going to talk about your book, Developer, Advocate!, where you had conversations with 32 of the industry's most prominent developer advocates from various companies. So, before we dive into the book, can you tell me exactly what a developer advocate is?
Yes. This is a very interesting question and it's really what the focus of the book is all about. But maybe one way to look at this question is to think about engineers or developers, programmers, however you want to term that group of people, who do all the coding. Now, those people increasingly are the ones who have a big influence on the technologies that a particular company chooses. And that's more and more the case with open source technologies. So, engineers adopt particular technologies, then start using them at home in their hobby projects and so on, and then they bring them to work.
And then in the work context, the company buys that particular product or the enterprise version of it and so on. So, now the question is how best to approach that target group? If you are an organisation of some kind, trying to sell some technology to other companies and you're aware that engineers, developers, programmers, coders play a big role in the choice of a particular technology, then how do you reach those people? Do you reach them by means of a marketing talk with PowerPoint slides and people in a suit? No you don't. That doesn't come across as very authentic. And also, engineers spend their time coding and they're not at presentations and so on.
So, then it becomes more challenging, the question of how do you reach this group of people that have an increasing influence over which technologies are required in organisations. And developer advocacy is the response to that. The developer advocates value a number of different ways to manage, to interact with engineers and developers and coders and programmers and so on, and bring across the message of a particular technology from a particular company or the open source projects that they work on and they work alongside developers and programmers and coders and so on. And through a process of empathy and an authentic interaction, enthusiasm, they bring these technologies into the place where the coders can try them out, to pick them up, start playing with them and introduce them into their organisations.
Yeah, that's interesting. And what made you decide to do this book and put developer advocates into the spotlight? Because I would imagine that these are engineers and we often have this bad um stereotype of IT engineers who just want to code and they're just in the background.
So, I guess this is a way for you to put this up front that there are people in our community, in our industry who have this capability to be like voice boxes, be like amplifiers, of our technologies, of our processes. So what made you decide to do this?
Well, I mean I had been a developer advocate for many years and had been traveling to many different conferences around the world and I came across all these other people who were also developer advocates. And the interesting thing is that there isn't really a degree or a course that you can take to become a developer advocate. So, the stories of the people who are doing this in different organisations, it's always very unique and very interesting.
So personally, in the 90s, I was a technical writer writing very sick books that nobody read. And I remember the first time I wrote a blog post and I got a response from somebody from the other side of the world, leaving a comment at the end of that blog, was a major breakthrough for me. And I'm thinking, “Well, you know, with the internet, with the web, etcetera, with all the technologies that are increasing, the connections between people are much shorter.”
And different people have been discovering the same thing, coming from technical writing, coming from training, coming from all kinds of other disciplines, they found that this authentic interaction and approaching people, working with them, finding the right influences within organisations. And so I wanted to find out more about these people and put their stories together and um and also make the case for this being a real discipline with real practices at an early stage clearly. But over time, I'm sure there's going to be a development towards there being courses and training the developer advocate and and so on.
Yeah, because there's currently no clear career path towards getting a developer advocate job right? But since you've talked to 32 of these prominent developer advocates, did you see a commonality or a common denominator? Where did they come from? And what was their common pathway towards becoming developer advocates?
Whether they're called “technical writers” or “trainers” or whatever they're called... those people are the advocates towards the developer.
I think that there's a couple of common aspects. One is about the personality of these people. So, empathetic kind of people, but not necessarily all people who want to stand on stages and travel the world and so on. You know, a lot of people enjoy writing blogs and articles and things like that. And some people enjoy editing. There's a whole range of different places for people of all personality types, whether you're introverted or extroverted or whatever.
But if you want to engage people directly in one way or another, whether that's in person or not,if you want to cut through all the marketing stories and all the product pitches and get down to what really the technology is about and what is really interesting about it and bring that message across to the people who are really going to use it rather than the CFOs and the COOs and the marketing people and the etcetera, if you want to work directly with the people who are using the technology and bring across your enthusiasm, those people in an organisation tend to become developer advocates, whether they're called developer advocates or not.
Whether they're called “technical writers” or “trainers” or whatever they're called – all kinds of things typically – those people are the advocates towards the developer and for the company bringing the technology across in an authentic way.
It's interesting that you brought that up since you would think that a developer advocate would be great at sales but also a good engineer and something like that. So, there's that common misconception that I'm glad that we're addressing that right now.
Speaking of that, you've already touched on this a bit when you answered the question. But how about the common skills? What would be the common skills that you find developer advocates need to have if, say for example, someone from the other end of this podcast who would be listening in, they want that developer advocate career path? Well, you just said they don't need to speak well. Do they need to write well? Do they need to know a bit of marketing, sales, public relations, perhaps?
I think it's mostly about personality. Are you independent-minded? Are you self motivated? Are you curious? Are you enthusiastic?
I think it's mostly about personality. Are you independent-minded? Are you self motivated? Are you curious? Are you enthusiastic? Just those particular things as a starting point. If you're that kind of person who doesn't necessarily fit perfectly well into a particular group within an organisation, you're not the kind of marketing that you want to talk directly to developers.
You’re kind of sales, but you kind of think, “Well there's also the process before sales.” You want to speak to people before they get to the point of buying or selling. The kind of pre-pipeline discussion and you're kind of in the product organisation, but you're somewhere in the middle and you’re kind of the linking person between these different organisations. If you find yourself not fitting anywhere perfectly, then this may be what you've actually been doing all along. Maybe you've been a developer advocate without even realising.
Yeah. So the label, it doesn't really matter when it comes to what you're doing. I think I see a lot of parallels with developer advocate and community manager as well so I think that it's basically the same thing.
I mean I see community managers as maybe being slightly less technical than what developer advocates typically are and a lot involved with setting up events and bringing people together. But whether you call yourself developer advocate or community manager or developer relations or technology evangelists, you're all basically doing the same thing and there isn't one title that covers everything. But you know, you're doing community work, whether it's for an organisation or for an open source project or for something that you're working on yourself. You're enthusiastic. You're authentic about something. You want to get the message out there.
You want to be honest as well. So, it's also about saying, “Look, this product isn't perfect, it's in progress.” It's not about spinning a product, it's about being real about it and saying, “Hey, come along. Join me on my journey as I learn this product.” It's about sharing. It's not about really preaching, but it’s kind of a question around technology evangelism versus developer advocacy. Developer advocacy is about coming alongside somebody and learning from each other. Whereas technology evangelism, it's a very similar thing. It comes down to the same thing.
Right, so let's dive into your book. You were able to interview 32. Wow, how long did that take you?
It was a process. A lot of the people that I initially started with were people that I found personally interesting, just in my circle of friends, and developer advocates. So, people I personally had run into and kept running into. So, Josh Long from Pivotal and Matt Raible from Okta were two examples of these. These are really enthusiastic, really great speakers, always with great presentations, always with great practical content. It's never a marketing pitch, it's always about, “Hey, look what I discovered last week! Even though I've been working on this particular technology for 10 years, here's something I learned last week.” That kind of enthusiasm is really, really great and inspiring and it's what brings people to conferences.
So, I wanted to find out what their stories were and how they ended up there and so on. And so I had a list of people who I wanted to interview anyway. And the book was a happy coincidence where I met Dominic Shakeshaft from Packt who was looking for different topics to do interviews around. And he said, “Would you like to do a book of interviews around something?” And I said, “Yes, I've been collecting along the names of people who I have wanted to talk to about how they ended up being what they are and what their daily life looks like and what the pitfalls are of developer advocacy, what they've enjoyed.” What are the ethical dilemmas? There's a lot of interesting ethical aspects.
And so, I had a list and then the publisher. Dominic came up with a list because he had other names because we want to have a bit of a mixture of people that I knew and people that I didn't know and people from different technology backgrounds. And so we ended up with quite a wide range of different people and that's how the selection of the book came about.
And how long was the process of getting them to sit down with you or talk to you, getting on a call, writing down all of these notes and then publishing it on the book and collating it. How long did that take you?
It took about, I don't know, about a year or two I think. It was a process of having an initial conversation with a list of prepared questions. There were definitely points that I wanted to touch on each interview but I also wanted to leave space for spontaneous directions to be started. And then we had a lot of recordings and the publisher. Then there was just a fantastic person over there, Joanne who took all those recordings and worked them out into a nice flowing interview.
What ended up in print was very different to the conversations that we had tried to piece together into a coherent conversation and then went back and checked with the interviewed person and went back and forth quite a bit until we ended up with the finished product.
Yeah, and you told us a while ago that developer advocates, they would focus a lot with talking to their co-architects, their co-engineers, their co-developers. But a lot of the movement now in IT Is going into this low code space where we have terms such as “citizen developers.”
So what strategies would advocates take when they advocate their technologies to non-technical or non-IT people? I would imagine that a lot of them right now, a lot of the people that you've talked to, they would also have conversations with people in the business side of things and not necessarily developers. They may be in sales or in marketing. So how do they talk to these people?
It’s always complicated even for non-technical people in an organisation to understand what developer advocacy is.
It's a very difficult challenge, definitely. It’s always complicated even for non-technical people in an organisation to understand what developer advocacy is because there is a long road from developer advocacy to a funnel or a pipeline or a revenue stream. And this is the problem of developer advocacy in an organisation, especially as it typically happens that you find yourself in the marketing organisation. So you are a developer advocate with your team or on your own and you're reporting to the marketing person, the CMO oftentimes.
What also happens is that your reports to the engineering manager, which can have advantages and disadvantages to the engineering manager, understands what you're doing but doesn't have a budget for conferences and so on. Well, the marketing manager has a budget but doesn't really understand what you do. So it's always a bit of a complicated situation.
And so, one way to explain to non-technical people who have a budget and who wants everything to be connected to a pipeline into a funnel is to talk about pre-pipeline. I think this is the magic word, to say, “Yes, we have a pipeline, but there's also the pre-pipeline.” How do we get people into the pipeline? What's the process before the pipeline and of the engineers who are making decisions in companies about which technologies are used? That’s the focus of the pipe pipeline. You want to get people very early. You want those people in an organisation to be championing your technology, to the people with the budget in that organisation, to their marketing personnel, to their CFO and so on.
So, how do you reach those people and the marketing person in your organisation that has a budget that doesn't really understand developer advocacy, understand that there is that particular need to speak to that pre-pipeline concept and that can work? But it becomes difficult because in a lot of organisations, the revenue is created directly from reaching out to the people with the money in those organisations. So, it's like that goes straight to the CFO. That goes straight to the CTO.
But then the argument is, “Look, the CFO and the CEO in that organisation, they speak to their engineers and don't you want those engineers to be carrying across a positive message about our technology.” So isn't it in our interest to speak to those engineers? So it's a long path, but there is an argument to be made to non-technical people for the value of what we do as developer advocates.
Yeah, that's a lot of work there. And speaking of work, you've touched on this, one of the hardest aspects of the job that you said and that you mentioned is ethics. So, a rather common dilemma is about defining where the developer's allegiance lies. Right? So is it with the company that they work for or the community that they're working with? How do you find developer advocates successfully straddle this line?
It depends, and this is only one of the ethical aspects. And in the book, in each interview, I talk about these and ask questions about this because I've had so many of these myself. Really, the whole book is about me having a conversation with myself, asking the questions that I would like answered, but this is one of those aspects.
Another aspect is, what if you know that there are all kinds of bugs in your product or the technology that you're advocating and you're up on the stage. And you're giving this wonderful speech, presentation slides, demos, whatever and, you know, there are all kinds of problems. Do you secure those problems or do you open about them? On the other hand, you don't want to have a long list of bugs in your presentation either.
So that's one of these ethical aspects. But this point that you make is another one on whose side are you on. Do you represent the company? Do you represent the community? Do you represent yourself if you don't work? I mean, many developer advocates don't work for a particular company. They just work for themselves independently and they pick up particular technologies and they like them, or they don't like them. And there are particular ones that they start educating for, and probably those are the ones that you can trust most because they don't have any agenda. It's just, they're promoting this technology because they find it interesting.
If the advocate comes from a particular organisation, of course you should ask yourself, what is that organisation doing? Why is that particular developer advocate saying these particular things? It's never going to be a neutral story. If you're paid by a particular organisation, it's always gonna be a slanted story. So, yeah, it depends and you have to be careful about who the person is that you're listening to or reading from, etcetera, etcetera.
So, it becomes the task now of the engineers to really investigate. Is that the right word? On who and what to read. Speaking of who and what to read, GJ, you've got a lot of good points for this podcast. Unfortunately we just ran out of time. But I know our listeners who are mostly architects, they’d love to learn more about developer advocacy, especially who to listen to and whom to read. So, I guess your book would be a great start. So how can our listeners find out more about your book and get in touch with you?
Well, the book you can get on amazon.com or on the PacktPub. And it's available as an ebook, as a pdf or a hard copy book, really thick. It's about 600, 700 pages. Makes a wonderful doorstop but it's full of authentic conversations. Really, if you page through that book, especially if you have it in your hand and you're paging through this book and you pick it up and you read a few of the interviews and a few of the questions and answers, there's just so much enthusiasm. That's the main thing you get from this book – all these people being really enthusiastic.
So I would recommend it if you're ever in a dip in your engineering career and you're wondering what's next. Take a look at this book, take a look at all this enthusiasm around technology that all these people have from different industries, from all kinds of companies, independent from people from Amazon, from Google, you name it.
And you can reach me on Twitter. So it's here, it’s “@GeertjanW” my first name with the first letter of my last name. Or Linkedin. And also, I've been very involved in a project called Foojay, which stands for “Friends of OpenJDK.” Foojay.io. It's a community platform for anyone using the OpenJDK in any way. So if you're a Java developer or Kotlin developer, it's a site with blogs and articles and release notes and an events calendar and those kinds of things.And the slack channel of course. So you can join in there and find me there too.
Alright! We also love the enthusiasm that we got from you on this podcast, GJ. Thank you! Thank you very much for joining us.