How Great DevRel Teams Turn Trust Into Adoption

Key Takeaways

• DevRel is not marketing, it is a trust bridge between developers and product teams: Effective DevRel begins with listening. Its core role is translating developer needs into product decisions and explaining product value in a way that resonates with developers without sounding like a pitch.
• Starting DevRel early helps avoid losing deals later in the funnel: If developers are unfamiliar with your company, deals can stall or die. Starting DevRel from day one helps build awareness, trust, and credibility long before the sales team enters the conversation.
• Authenticity is more powerful than aggressive outreach: Developers ignore generic marketing. The most successful DevRel programs are rooted in genuine community participation, honest feedback, and real-world engagement with the ecosystem.
• The best technical content is contextual, problem-first, and easy to follow: Great content speaks to a specific developer problem, includes clear steps and code snippets, and avoids unnecessary fluff. If a post is not immediately helpful, it will be ignored.
• Measuring DevRel success requires a long-term view of brand impact: DevRel should be evaluated like brand awareness. Track meaningful activities such as blog contributions, conference talks, and community engagement that build influence and developer trust over time.

Episode Transcript

Geertjan Wielenga (00:00): You can't really study developer advocacy. You can't go to university and take a degree to be a developer advocate. You come from a training background, or from a development background, or from a technical writing background, or from a whole range of different activities.

And typically, if you become a developer advocate, then you kind of realize, well, if you're involved with a technology that's all about performance, then you'll become some kind of thought leader in performance in general. And then you can position your technology within that ecosystem.

It's typically not about pulling people into your organization, but it's about going out and finding people and interacting with them, and then discovering what their needs are, and not necessarily wanting to sell anything.

And that's especially true in this era of open source, because developers have been trying out so many technologies through open source in their free time or at work without paying anything. So if, especially if your technology has an open-source angle, chances are that developer relations is about communicating to developers. And you do that in multiple different ways.

It's about identifying champions for your technology. It's about making a list of, you know, here are the topics that we want to deal with in videos. Here are the conferences that are relevant per region. These are the ones that we want to attend. Here are ones that we want to encourage others.

I think good technical content has code snippets in it. And it's very step-by-step oriented and starts with a particular context, presents a problem in that context, and then provides a solution. A large part of what you're doing can be described as brand awareness. So how do you get brand awareness among developers? By writing X number of articles or blogs, producing X number of videos, going to X number of relevant conferences, having a list of that per quarter, and tracking that. And then...

(Intro music and animation plays with text: "AND WE'RE ROLLING AGAIN!", followed by "The Modern DevGTM Brew, Season #3" and logos for Anyscale, Sourcegraph, zenrows, novu, and azul.)

(02:20): Title card: "HOW GREAT DEVREL TEAMS TURN TRUST INTO ADOPTION - EPISODE #5"

(02:33): Host, Disha Agarwal: Hello everyone, welcome back to another episode of the Modern Dev GTM Brew. I'm Disha, your host. And in today's episode, we're going to discuss something that every DevTool company thinks about, but only a few are able to truly master. And that is developer advocacy.

Our guest today is Geertjan Wielenga. Geertjan has over the years worn many hats as a developer advocate, technical content writer, editor, and a long-term contributor to open-source communities. Today we'll learn how developer advocacy really works, and how content and community can help build trust, and why DevRel is such an important function when it comes to DevTools.

Geertjan, welcome to the podcast. We're really excited to have you here today.

(03:17): Geertjan Wielenga: Thank you. Thank you. It's good to be here.

(03:20): Host, Disha Agarwal: Geertjan, before we sort of dive into the questions that we have, it would be great to understand that, you know, throughout the years you've worn so many hats. You've been a dev advocate, you've been a writer. What really drew you to this ecosystem?

(03:34): Geertjan Wielenga: I think mostly the fact that one needs to be authentic and can be real and also that you work across multiple different disciplines and get to know a lot of different things and meet a whole range of people doing a whole range of different activities in the IT industry.

(03:53): Host, Disha Agarwal: Understood. And in the different hats that you've worn, what have you enjoyed the most?

(03:59): Geertjan Wielenga: It's normally what I'm doing most recently. So at the moment, I'm really active in the Java user group community in Amsterdam, where I live. I'm one of the coordinators, and I really enjoy finding new locations where we can do our meetups, identifying speakers, getting the event together. And typically, we have about two meetups a month, and sometimes at my house as well for a lunch session. So just the authentic interaction and the quick process of setting up a meetup, having it, and then doing the next one. I found that quite an energizing experience.

(04:35): Host, Disha Agarwal: Sounds very exciting to be very honest, Geertjan. And amazing work that you're doing.

(04:41): Geertjan Wielenga: Thank you.

(04:43): Host, Disha Agarwal: Great. So before we sort of get into the questions, it would be great to cover the fundamentals. So developer advocacy can mean different things to different teams, right? What do you think is actually the role of a developer advocate?

(04:58): Geertjan Wielenga: I think it's really a bridge function between an organization and its typically its technical users. So you're you're kind of a connection point between getting feedback from the external community of users of a technology and the internal team that that develops it.

(05:17): Host, Disha Agarwal: Understood. And what should a developer advocate do to actually build that trust, right, with developers?

(05:25): Geertjan Wielenga: Yeah, this is an interesting topic. It's really around, I think, reputation and having a reputation that is built on on honesty and authenticity and empathy and understanding where people are coming from and being honest about the flaws and the issues with your own technology and trying to bring people into a particular ecosystem and and sharing, being as much as possible and equal with the with the people that you're interacting with. And then also on the other side, being impactful in bringing that message across back into your organization where you come from and being that conduit, the kind of bridge between those two different entities.

(06:08): Host, Disha Agarwal: Understood. And as you mentioned, right, it's that bridge between both developers who are going to use your product and the people who are creating the product, right? A very, very important role. But then how do you maintain that balance? Because you have to make sure that both parties understand what the other is saying. So how do you maintain all of that?

(06:27): Geertjan Wielenga: It's quite tricky and it's a little bit intuitive. And typically that's also why developer advocates tend to be more senior people who have a lot of experience in the industry and who come from from different parts of the IT ecosystem. You can't really study developer advocacy. You can't go to university and take a degree to be a developer advocate. You come from a training background or from a development background or from a technical writing background or from a whole range of different activities. And typically, if you become a developer advocate, then you kind of realize, well, I enjoy doing what I'm doing, but I'd like to do more. And I'd like to have a wider range of experiences. And if you're that kind of person, then you typically evolve in that direction. And you gradually end up, there's a lot of opportunities now in terms of open source and there are community platforms like I'm very much involved in the Friends of OpenJDK, so FUJAY, but there's all kinds of places where people virtually online and in person get together. And if you go there and you're just interested, you're not there to sell anything. You're not a salesperson. You're you're far more focused on on listening and being empathetic and picking up a vibe and then bringing that back to your organization and trying to trying to bring the authentic message from from the world out there into the organization that you're from.

(07:54): Host, Disha Agarwal: Understood. So it's basically, you know, someone who's like a representative of the product, but is not pushing the product proactively, but trying to gain that ground knowledge so that your product can become better. And, you know, you can sort of speak about your product, but not really in a pushy, sazy way.

(08:12): Geertjan Wielenga: Yeah. And typically, you also find developer advocates becoming thought leaders broadly in the area from which their technology comes. So if you're if you're involved with a technology that's all about performance, then you'll become some kind of thought leader in performance in general. And then you can position your technology within that ecosystem. So you go to conferences and you talk about the importance of performance and how to achieve it. And then you say, well, one of the solutions is the one from the company that I work for. And you kind of mention it along the way, or it's one of the bullet points on a slide. And in that way, you can kind of bring that message in an authentic manner within a larger story around a particular area or domain in which your technology fits.

(08:57): Host, Disha Agarwal: Understood. Very, very interesting perspective, Geertjan. So right now we spoke about how dev advocates can actually bring awareness to your product by one, understanding the pain points that the community might be facing and then subtly plugging in wherever you feel that your product can organically help out, right? In terms of adoption and retention, do you think that DevRel can influence those parts of the funnels as well?

(09:22): Geertjan Wielenga: Absolutely. It's being open and saying, well, you know, this is my background, trying to meet people where they are. It's it's not It's typically not about pulling people into your organization, but it's about going out and finding people and interacting with them, and then discovering what their needs are, and not necessarily wanting to sell anything, and also not necessarily pushing a particular angle or perspective. And this makes it quite hard to justify sometimes back in your own organization, because you're you're not making a very direct connection, and you're not always bringing in leads. You're not always bringing in a very clear message either. Sometimes you're bringing in quite a contradictory story and and more a sense of where different people are and where the ecosystem is and what they're talking about and saying things like, well, they're not really talking about the topics that are of direct relevance to us. So how can we rethink what we are doing in our organization to connect with the topics of interest that are out there in the community? And that kind of conversation in an organization you can only have if you actually have people who are out there not pushing things because if you're if you're pushing too hard, then you can have a very short conversation because the other person could say, well, I'm not interested and that's the end of the conversation. But if you're having a real authentic, holistic conversation about what the other person is doing and where they come from and kind of have a broad conversation, then that can really bring quite some interesting information in that can be of relevance to your organization.

(11:01): Host, Disha Agarwal: Understood. And how open do you see that product teams are when a dev rel is saying something? Do they hold a lot of weightage when they bring this really valuable information from the community?

(11:11): Geertjan Wielenga: Well, it's also interesting because DevRel team within an organization is sometimes connected into the product team, sometimes into the marketing team, sometimes into the sales team, sometimes they're they're an independent organization. It's it's partly because it's a relatively new and kind of typically more a senior type of position that the people who do this are more or less independent operators who somehow fit into different organizations within a company. So or within different teams within an organization. And so depending on where you where you fit within the organization, the kind of messaging that you come back with could be different and what you're actually doing if you're part of marketing, then you're in a different role than if you're part of product or if you're part of sales. If you're part of sales, it can be really interesting, but also quite challenging because then you you tend to have sales targets somehow, directly or indirectly. And then you really focus more on leads. If you're part of marketing, then it's it's a whole different situation again. I think if you're not, I mean, ideally developer relations would be its own entity within an organization. And I think one sign of DevRel being mature is if you were to see a lot of VPs or SVPs of developer relations that would be on the same level as the head of marketing or the head of sales or product because that's really where developer relations fits on the same level and with the same budget because that's also always a problem that it's it's more, it's a better fit to be within the product organization, but then the product organization doesn't really have a budget for travel, which is more what the marketing or sales organizations would have. So it's always a challenge and it it takes some time to figure out where the right place is in an organization.

(12:59): Host, Disha Agarwal: No, I think that's a fair point. You know, if if DevRel sits within a particular, um, what do you call like a marketing or a product function, then they get colored by what the targets for that function might be, right? So then the conversations are not that organic, they are not that authentic. When someone is starting out a DevRel function, you have any opinion on which team within that DevRel function should lie?

(13:25): Geertjan Wielenga: Well, it depends on the on the personality of the developer relations person or the team itself. But I think the best fit is probably product, I've found. Because again, with sales, you could end up having these lead targets. And then you're kind of having a different conversation and you have different intentions. With marketing, it's often, I think the problem with marketing often is that the focus is always on quantity. And with with DevRel, you're always focused on on quality. You're focused on having, going to a conference and having a few really good conversations. If you come back from a conference and you had five really good conversations with companies that are of relevance to your organization, then that's much more relevant than having 500 badge scans or 5,000 badge scans with people who you've given a t-shirt to that they care about. And so it's it's really about trying to find the right fit. But in general, I would say either being an independent organization or being part of the product team is probably the best fit.

(14:28): Host, Disha Agarwal: Understood. And when do you feel that a company is ready to have a DevRel function? Is there any milestone in terms of, you know, their revenue or any milestone in terms of their company size? When should companies really start thinking about having a DevRel function?

(14:44): Geertjan Wielenga: I would say immediately, especially, I mean, if you have a technology that is relevant for developers and you have sales people and you have marketing people, et cetera, and you don't have at least one person, ideally two or three, responsible for their role, then you can't really communicate effectively to developers. And to some extent, you could argue that, I mean, there is a problem in a way because developers are not the decision makers ultimately for buying a technology. So you could say, okay, you need to invest right from the start in developers, but it's it's going to take quite a while before the developer actually is persuaded. And also communicates this up the chain and that it is prioritized. Then if you were to target kind of the the economic buyer right away. So CTO, engineering manager level, then you could be more impactful, whoever that economic buyer is who you've interacted with, is going to be talking to the architects and to the developers because what you're selling them is a developer technology. And so this economic buyer will reach out to their development team and say, hey, we're looking at this technology. We've had a conversation with the sales people. And then if the developers say, well, we've never heard of this company in the first place, and here are seven alternatives from companies we have heard of, then that's the end of the story. So you need to have a developer relations team from the very beginning to lay that foundation of knowledge with the developers who will ultimately one way or another impact the sales cycle. And that's especially true in this in this era of of open source because developers have been trying out so many technologies through open source in their free time or at work without paying anything. So if, especially if your technology has an open source angle, chances are that developers have been trying out your technology already or you spread the message to them in one way or another. And so they're going to influence that buying cycle.

(16:40): Host, Disha Agarwal: Definitely makes sense. And what do you think that is one of the biggest mistake that companies make when they are trying to set up a DevRel function?

(16:47): Geertjan Wielenga: I think maybe having just one developer relations person and then thinking, okay, we we're done, that should be enough. I think it really helps to have at least two or three people who can learn from each other, who can interact with each other. I often feel quite sorry for organizations where you see there's one developer relations person. And also it shows the investment of the organization in developer relations. When you take a look at organizations with significant teams of five or six or more, that really shows a significant investment. We've been talking about, there isn't a direct line between developer relations and revenue. It's it's a very dotted line, it's very circular, it could could take years. Three years after you've done a presentation, somebody could come to you and say, hey, I remember that presentation from three years ago, now we have this problem with performance or whatever it is, could you take a look and could we look at your technology? Organizations where you see five or six people at least in developer relations, that's really a sign of the organization being mature and having thought about this and having really invested in it. In the same way as you have a support team, you don't say, well, we need less support people because they are not making revenue for us. DevRel is a kind of extended support team that that are technical and that are out there and that are interacting with your ultimate client base.

(18:09): Host, Disha Agarwal: Understood. So what I'm understanding is that since this is a function which takes some time to show results, that is why sometimes companies don't really understand the value of devrel, but if done right, this can be one of the biggest moat that a dev tool might have.

(18:24): Geertjan Wielenga: Absolutely. And I think also a good sign of the maturity of an organization is that the developer relations team grows over time. You actually see that now there are one or two and then a year later you see one or two other people. And you also see well-known people in the community joining that organization. That's also a really good sign, I think.

(18:43): Host, Disha Agarwal: If a company is setting up a dev rel function today, what should the people start spending time on? What should their 100, first 100 days look like?

(18:52): Geertjan Wielenga: It's a range of different activities and it's tied to the developer relations person themselves. So, some people are, I mean, it's it's really open, this is also what's really nice about the function, it's open to all kinds of personalities. So if you're a more introverted person, that's perfectly fine. I mean, technical writing is really developer relations. You are communicating to developers, be it not in not in person, but maybe via text. So you would be writing blogs, writing documentation on the on the sites of the organization where you're working. That that kind of work, I mean, that's that's definitely one part of it. Another part of it is creating videos and putting things on YouTube and doing step-by-step guides through through the form of video. Another aspect is going to conferences. And it's also setting up communities, identifying where there are places where your message could be really relevant. So that means interacting with sales and with marketing, with product and finding out which which areas are of relevance to your organization and what what is the right thing to do there? That that second question you would answer by finding out from those communities there. So what people are doing in Australia is very different to what people are doing in India, is very different to what people are doing in in England or have some communities there already or maybe they don't. In your technology area, there are user groups. And so you take a look at where are the user groups, because those are the very enthusiastic people. They spend time after hours talking about technology together. So those are the people to connect with. And so then you take a look at your technology area and the relevant user groups and where are they in the world and how can we support them? So it's not about how can we send our message to them, but it's about what can we do to help them? And often it's not a question of money, often it's a question of they need speakers. Often organizations, these Java user group organizations need speakers. Developer relations is about is communicating to developers. And you do that in multiple different ways. And you're gathering information as you're doing that and you're passing that information back into your organization. And so it means setting up a program, a schedule. How many blogs do we want to write? Do we want to write them on our own site? Which ones shall we publish on other sites? And it's about identifying champions for your technology. It's about making a list of, you know, here are the topics that we want to deal with in videos. Here are the conferences that are relevant per per region. These are the ones that we want to attend. Here are ones that we want to encourage others. It's such a wide variety of activities. That's what makes it really interesting and diverse.

(21:35): Host, Disha Agarwal: Yeah, I think you you mentioned it is it is very diverse and I think DevRel has their work cut out. Are there any particular tools or platforms that DevRels use to understand the developer pain points?

(21:46): Geertjan Wielenga: Well, I think Stack Overflow is a is a good example. Go there, search for your technology or the language or whatever it is, the scanner or whatever the the tool is, and see what people are saying out there. Something else is to take a look at what kinds of issues are coming into your organization. What are the incidents that are being filed? Do a search on Twitter, do a search on Google. Look at g2.com. You know, there are multiple places where people are complaining or complimenting what your organization does. And especially find the people, I think what is what is always the most interesting is find the people who are unhappiest and have the most complaints online. People who who don't like your product, who've tried it and who are not happy and who have gone away and have said nothing about it, are not very useful because you don't hear anything about them. But the people who are publicly critical, if you reach out to them and say, hey, you know, we've we've seen you say this and this, and apparently you don't like this and that. So did you know we've been working on this and this? And, you know, that kind of interaction can pull them in. And that same passion that made them negative can make them really positive once they've once they've turned around and they can become your champions, ultimately.

(23:01): Host, Disha Agarwal: Yeah. Very, very interesting thought, you know, turning your biggest critiques into your biggest champions. Understood. So, let's deep dive into the two pillars that we identified. One very important thing is content, right? So what do you feel distinguishes a great content from a just okay content? Are there any ingredients or any recipes for writing a good technical content?

(23:22): Geertjan Wielenga: I think good technical content has code snippets in it. And it's very step-by-step oriented and starts with a particular context, presents a problem in that context, and then provides a solution and takes you through it and in understandable text. And not super long paragraphs, you know, one or two sentences per paragraph, a couple of steps, not more than about seven steps, and maybe a link to a video. You know, something that is that is consumable. People don't have the time and the attention to read through and to try and figure it out. But if they can see how it's done in a video, plus have it in text, so it appeals to both types of learners, you know, some people really like video, some people really like content in terms of text, blog articles, and so on. If you appeal to both, and in the video, you actually go step by step through what you've written and and and make it consumable and maybe have a whole series. And at the end, you say, okay, this is the topic that we've addressed. So what should we do next? And have the have the users provide the next kind of topic that that they would like you to to address. That makes for for interesting content, I think.

(24:33): Host, Disha Agarwal: Understood. And have you seen this content sort of evolve? And have you seen the trend change or has this always been the case?

(24:39): Geertjan Wielenga: Well, I remember in the 90s, when I was a technical writer, I remember writing really thick books that were literally printed out and hundreds of pages. And as a technical writer, you know, I was sitting in the in the back room somewhere and and writing these these very thick books. And the only feedback you would ever get is when the salesperson would come back and would say, on page 372, you wrote this. And as a result, this caused a major problem at our customer. And you would never get any positive feedback. And you would only get it through the sales people who would actually go with your book to the to the customer. So, there's been a lot of change. I remember the first blog I wrote and immediately getting a response from somebody in a whole different country saying, oh, interesting, but what about this and that? And it's much more direct. So you can, you can really build up a reputation from being a writer of blogs, which many people have done, from from writing content and your name becomes more well known. And then you you start speaking at conferences if you like, or typically you first do a presentation internally at your own organization to your team. And then you go to your user group. And then you go to a conference. And at some point, somebody says, hey, don't you want to write a book about that? And you introduce to your publisher and you write a book. And it all becomes very organic. If, I think for me, a big breakthrough moment was when I realized I should be writing just for myself. So I was writing blogs on topics that were of interest to me. I discovered an error, I got an error message somewhere in my code. And I discovered what the solution was. And then I wrote a blog entry with the error message in the title of the blog for SEO. So somebody else looking for that a solution to that same error would end up in my blog. The best part was I was surprised at the answer because I didn't remember anymore writing that. I read my I read my own blog post and I realized, hey, that's how you do it. And I had completely forgotten that I'd written that and I'd learned that. And because I had recorded it for myself, it was there for me to find.

(27:04): Host, Disha Agarwal: Understood. So this sort of brings me to one more point. Do you feel that having a technical background to become a DevRel is essential because that is when you relate to the pain points, or do you feel that even if someone does not have a technical background, DevRel is something that they can pick up?

(27:18): Geertjan Wielenga: I think if you're a technical person, typically, you know, you would find yourself being a developer advocate being involved in in going to conferences and writing blogs and whatever. But even if you're not a technical person, and even if you don't think you would want to become that, I mean, I'm not really a technical person. Traditionally, I mean, I studied law and I stumbled into technical writing and then from that into developer advocacy and so on. And I kind of learned on the job. I I I haven't studied IT or software engineering or anything like that. But even if you were to not want to become technical, you have no interest in that, even then there would still be a role for you because you could become a community manager. And you need no technical skills for that. So it's about setting up events, it's about setting up meetups, it's about identifying where interesting people are, it's about making people enthusiastic. No technical skills are are, it's basically being an event manager more or less and also identifying where events could happen. And there's a lot of organizations, I think Elastic is one of these, where you have a split between developer advocates and community managers and they do work together, but the community managers are not technical people and they're having a great time and being very useful and very meaningful in that organization.

(28:35): Host, Disha Agarwal: Understood. Understood. We discussed that that is one very important pillar when it comes to dev advocacy. What do you feel? Is it easier to get yourself embedded in one of the existing developer communities or is it better to, you know, start your own?

(28:48): Geertjan Wielenga: If there isn't one that is directly relevant to what you're doing, then it makes sense to to start your own and and draw people in. But if there are a lot of user groups already, a lot of conferences, then you don't want to go and set up something that might look to be competing with something else. It's simpler and cheaper so on, just to join in with something that is already there and to learn and and to contribute to it. And and gradually, you'll be one of the people who are leading that that community just by being active and by by being collaborative and being helpful.

(29:20): Host, Disha Agarwal: Understood. Understood. And if a DevRel is sort of going to to these conferences, et cetera, is there like a checklist that they should keep in mind? How do they best make use of these conferences when they're visiting?

(29:31): Geertjan Wielenga: I think maybe a a checklist begins with just attend and just be there initially and see what's what's needed, see how you can be helpful and and and gradually identify what the gaps are or you know, what people are struggling with or you might find, you know, one of the biggest challenges, aside from finding speakers, is often finding a location for the meetups to happen. Because what you want is typically, a company makes available a room or a couple of rooms for your conference or for your meetup. So finding those companies that want to do that. And the companies always, if you find them, you find that they're quite interested because they want to see developers coming to their organization because they are hiring. And so if you bring 200 developers to an organization that is hiring, you know, that's very, that's that's very useful for that organization and they want you to come back. And so yeah, just check what's needed and and deal with what's helpful.

(30:35): Host, Disha Agarwal: Understood. Totally makes sense.

(30:37): Host, Disha Agarwal: And what do you think that how do you measure DevRel success?

(30:39): Geertjan Wielenga: Yeah, that's quite difficult. And there's actually a really good book on this topic called The Business Value of Developer Relations by Mary, I forget her surname, but she works for Camunda. The Business Value of Developer Relations. Yeah, measuring impact is a question of agreeing with the stakeholders in your organization what you want to reach because, a large part of what you're doing can be described as brand awareness. So how do you get brand awareness among developers? By writing X number of articles or blogs, producing X number of videos, going to X number of relevant conferences, having having a list of that per quarter, and tracking tracking that. And then also, it's partly it's lead generation. So you're at a conference, you meet somebody, and they're interested in what you're doing. You're not pushing them, you're not selling anything, but you're just talking about what you're doing. You discover, hey, this particular person is from this particular region. Then you find out in your organization who the salesperson is in that particular region. And you say to the person at the conference, hey, do you want to have a conversation with so and so? Just have have an introductory conversation. And sometimes they'll say yes. And that could be the start of a of a wonderful new contract for your organization, whereby you can say, look, I had a conversation, it led to this lead, and that lead led to this big sale. So it can happen. But you should try to not be measured based on that alone, because then you're a salesperson. So it has to be a mixture of providing relevance to the different organizations or the different teams in your organization.

(32:22): Host, Disha Agarwal: Any any KPI or any metric that you've sort of seen get measured? Because as we discussed, right, it's very difficult to put a number or to put a target for a DevRel.

(32:33): Geertjan Wielenga: Yeah, X number of videos, you know, 10 videos per quarter, 20 blog articles per quarter. Maybe number of new authors on on the community platform that's connected to your organization. Maybe number of conferences attended. I mean, those all indicate something, partly an an indicator of busyness, you know, how busy have you been, which is which is a problem. But at the same time, it it it's also is an indicator of to what extent you are spreading the brand. And maybe you could also, the brand of your organization. And maybe it could also be number of internal webinars that you've held at organizations. So you you might go through all the list of prospects of your organization. And you might have a target to have, you know, an internal webinar or brown bag lunch at five of those companies or something like that. So it it is a numbers game.

(33:30): Host, Disha Agarwal: Understood. Thanks, Geertjan. I think those were my questions. Thank you so much for giving us such a thoughtful look into what really makes DevRel work and you know, how a team should or how a company should think about it, how valuable it is, how they should try and measure it, and how companies can sort of divide it into DevRel and Dev Advocacy. I really, really appreciate your inputs here. But, um, you know, before we let you go, Geertjan, we'd love to do like a quick rapid fire. Can we begin?

(33:59): Geertjan Wielenga: Yeah.

(34:00): Host, Disha Agarwal: Yeah.

(Upbeat music plays, transitioning into the rapid-fire round.)

(34:01): Title card: "RAPID FIRE ROUND"

(34:04): Host, Disha Agarwal: So what's the best piece of developer advocacy advice that you have ever received?

(34:09): Geertjan Wielenga: Be yourself.

(34:10): Host, Disha Agarwal: What is the last thing that you spoke to ChatGPT about?

(34:12): Geertjan Wielenga: I was looking up things about IoT platforms.

(34:16): Host, Disha Agarwal: What's one DevRel trend that everyone is talking about, but you think is very overhyped?

(34:20): Geertjan Wielenga: I'm automatically thinking AI when you say trend. But the the whole trend of writing content by getting AI to write it for you, that whole prompt, I've I've looked into it. I've I've explored it a bit. But what comes out is very generic. And I think it loses your authentic voice. And what you're doing as a as a developer advocate is being yourself. And even though it's it's wonderfully, neatly, succinctly expressed, it's still not you. So I think it's overhyped.

(34:50): Host, Disha Agarwal: So, but do you, again on a side note, do you still feel that AI or ChatGPT specifically should be used by DevRels or just to sort of, so while they give their own thoughts and then ChatGPT just structures them or do you feel that it's better to be authentic even if it is not that great in terms of grammar or something?

(35:07): Geertjan Wielenga: I think think it's it's really helpful in in generating ideas. So if you want to write an article on some topic, and you say, you know, give me seven different angles or seven perspectives on this particular theme. So performance, you say Java and performance, what are some interesting angles that I could write about around this particular theme? And then that's really interesting. Then you get a bunch of ideas that you hadn't thought of. And then you write your authentic article based on that title.

(35:34): Host, Disha Agarwal: If you could take a six-month break to master any new skill, what would that be?

(35:39): Geertjan Wielenga: A language, a human language.

(35:41): Host, Disha Agarwal: What's what's a piece of career advice that people should absolutely ignore?

(35:45): Geertjan Wielenga: I think I think the advice that you should change jobs every two or three years or so is something that's actually advice. But the this the kind of trend of, okay, it's two or three years, now I need to move on somewhere else. I think that should be ignored. I think you should spend at least six, seven years, about twice that, to really get into technology, into an organization.

(36:08): Host, Disha Agarwal: Definitely. And what's one book that you would recommend to all?

(36:11): Geertjan Wielenga: The Business Value of Developer Relations by Mary Thingwall.

(36:15): Host, Disha Agarwal: All right. Thanks, thanks Geertjan for your time. It was lovely, lovely interacting with you.

(36:19): Geertjan Wielenga: Thank you so much.