This week’s podcast-as-a-resource is focused on your technical content strategy. Richard talks to Adam DuVander, Principal Consultant at EveryDeveloper. Are you developer first or developer enabled in the way you sell software.
Discovery is Adam’s bread and butter. He helps companies understand how to be discovered in the first place – so what are developers or developer advocates trying to solve in the first place and then how Adam’s clients can describe how they can help.
So why can’t people do this themselves? This is the classic over-expectation – a developer will write about features, not benefits. And marketing without a technical competence will need a translation layer – that’s Adam and EveryDeveloper.
Forget asking for phone numbers or long forms to submit. Adam will bring you through how to market to developers, and the currency he has identified is knowledge. Yes, Code is important, but the experience that’s gone in to creating that code and the decisions and choices made to create that code is very interesting. How about use cases? Bring them on!
Another interesting approach is tell developers how to solve their problems without you, but also if they wish, you’ve built a tool to do it for them. The example of this in action is Edith Harbaugh’s Launch Darkly.
Then they have a detailed chat on developer first or developer focused – reaching developers directly, digging in to their problems and connects to this audience. Not scattershot, targeted help for specific problems. The developer enabled approach comes in to play when the buyer is other than the developer, but the developer is the user of the technical tool, and therefore must act as a champion for your solution. So they have to be armed with the language and explanation they require to get this discovered tool or service. Can all the stakeholders agree to move forward? Use cases, documentation and sample apps etc. can make all the difference here.
The developer first or developer enabled model for Adam’s clients has been a game changer for their marketing strategies.
Reach out to Adam DuVander on LinkedIn.
"Developer Marketing Does Not Exist: an Authentic Guide" - get the book.
Great blog post on how marketing and developers can collaborate.
An example of how to tell developers how to solve problems without you!
Find out more and listen to previous podcasts on our website.
Subscribe to our newsletter for weekly updates and information about upcoming meetups.
Join the Dublin DevRel Meetup group.
Interview Intro
Richard Rodger: [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started.
In this episode, I'm talking to Adam DuVander about technical content strategy. And it's really important to understand whether you are developer first or developer enabled in the way that you sell. Join us for a deep dive on those concepts. Let me also offer gushing praise for the books that Adam DuVander has written.
And if you are involved in developer relations, you need to read his books. I unashamedly recommend them, the first being Developer Marketing Does Not Exist, and the most recent one, Technical Content Strategy Decoded. I've just finished them and they are awesome. All righty, let's talk to Adam [0:00:56]
Main Interview
Adam DuVander
Richard Rodger: [0:00:58] Hey, Adam, welcome to the Voxgig Podcast. It is great to have you on here. [0:01:02]
Adam DuVander: [0:01:04] Thank you for having me, yeah. [0:01:05]
Richard Rodger: [0:01:06] Awesome. So, you are the proprietor of EveryDeveloper.com. What do you do? [0:01:11]
Adam DuVander: [0:01:15] We work with technical companies, with technical products, and help them reach the audience that uses it. Primarily, that's through content, content strategy, helping them create something that will attract and engage that audience. [0:01:31]
Richard Rodger: [0:01:33] And the audience that we're talking about is developers? [0:01:35]
Adam DuVander: [0:01:38] Primarily developers. Sometimes the audience doesn't call it developers, but the same sorts of tactics are needed to reach that technical audience. It might be architects or it might be someone that wants to call them engineers. There's a lot of hazy ground in system administration and operations. They don't always call them developers, but it is that kind of technical audience, that anyone who's in dev rel would be very familiar with. [0:02:16]
Richard Rodger: [0:02:16] Yeah. But it's not specifically technical content like tutorials and getting started guides. You operate, you were saying, more than the marketing level. [0:02:27]
Adam DuVander: [0:02:30] It – yeah, it can be those types of guides for sure. Anything that will attract that audience. Sometimes we end up in documentation but most of the time we don't, because documentation is what that developer uses after they've discovered you. And our focus is much more on how can we help them discover you in the first place. Often that is through understanding what are the problems that they have, what are the things they're researching. What is it that this developer, engineer, architect wants to get better at? What are they trying to solve in their job?
And we can find that out and then speak to that in a way that connects to our audience's product. And that's what – that's the stuff that everyone in dev rel is really well-positioned to do for their companies also, because they understand those problems and that audience in a way that many others don't. And so, that's what we help our clients do, is understand that and engage. [0:03:39]
Richard Rodger: [0:03:40[ And do you find that your clients, are they – is it just a lack of resources that they cannot generate the content or do they – is it a strategy problem? They haven't quite figured out what sort of content they need to develop. [0:03:54]
Adam DuVander: [0:03:56] It can definitely be both. It's often that the ones who are responsible for that attraction are the ones who don't have the backgrounds in the product, so they need some help articulating how do these features here connect to the problems. Because otherwise, you end up in doing that – making that classic marketing mistake of writing about features and not writing about benefits. But it's quite difficult to write about benefits if you don't understand how those help, so helping to be that translator between those and helping our clients understand that audience better is where we play. [0:04:49]
Richard Rodger: [0:04:50] And why are the companies not able to do it themselves? Surely the people in marketing should be sitting down with their own developers? [0:04:57]
Adam DuVander: [0:05:00] And I think they do in some cases. In some cases, we end up in projects where we're sitting down with both of those sides and helping them have this collaboration and helping them with that translation. Many times, marketing looks to dev rel to help play some of that translation role, and we all know that dev rel has many different projects that they could be working on.
And it's not always – the incentives aren't always aligned in those two orgs, depending; they could be in completely separate organizations. I know that Caroline Lewko did some research on that, and it was something like a third or less are in marketing. So, that leaves many other departments where dev rel might sit.
And I have a blog post about – here's how these two can get along and realize that everyone wants the same thing, which is to authentically engage that technical audience. So, finding the ways where those goals overlap and how can, in our case, content help provide that. But there could be other types of solutions there too where dev rel and marketing could collaborate. [0:06:24]
Richard Rodger: [0:06:28] I'm trying to picture it in my mind. You're sitting down; you're in the conference room. The developer's on the left; marketing on the right, you're in the middle, joker in the middle. [0:06:38]
Adam DuVander: [0:06:40] Sometimes, that's – going back to my time at Sendgrid, that was my role, as – in developer communications, was I worked really closely with the dev rel team. I also worked really closely with marketing, and many times, it was helping them see how each of those groups was doing great work. [0:07:04]
Richard Rodger: [0:07:07] When you're marketing to developers – let's make it very concrete. This conference room that you're sitting in, this is a series A startup. They've definitely got some traction. But it's mostly developers that do the initial signup, so that's who you've got to get on board. How do you market to those developers? Because I'm a developer and marketing doesn't resonate with me a whole bunch. I'm like, "Show me the code." [0:07:40]
Adam DuVander: [0:07:42] And that's my background too. I should say, that's – and so, this is a wonderful softball for me to mention my book, whose title I think answers your question. [0:07:55]
Richard Rodger: [0:07:57] I was getting there.
Adam DuVander: [0:07:58] And that book is Developer Marketing Does Not Exist, and that doesn't mean that there – get rid of all the marketers in those developer-first organizations. No, they have to change the toolbox that they use. And as you mentioned, when you use the traditional marketing toolbox, it comes across as marketing, and developers many times run away.
And what we need to do is, make sure that the marketing doesn't seem like marketing, doesn't have that smell that sends a developer running. At the worst case, things like huge forms that they have to fill out, something where it's asking for your phone number. You know what's at the end of hitting Submit on that. You're going to start blowing up with sales calls. Those are the sorts of things that a developer is not looking for.
If you look at what's the currency that a developer community uses, I believe that it's knowledge. If you look at open source and how it's adopted, it's sharing code. But behind that, it's this knowledge and this – these best practices that are baked into that code. That's the thing that developers appreciate, and if they see that coming from a company, they're much more likely to pay attention. And so, that's the approach to take to be authentic with that technical audience. [0:10:02]
Richard Rodger: [0:10:03] What does that mean in concrete terms? I've got an API and SDKs or whatever .Are we talking about having 50 different tutorials for different use cases, or is it something else? [0:10:14]
Adam DuVander: [0:10:16] Potentially. Definitely, use cases is the first place I would look with an API. And that goes back to my time before developer marketing, when I was a journalist at Programmableweb and before that, Wired. And having to answer that question; why would this thing that is – someone's announcing, why would this be used? And so often, that announcement was just all about the fact that they were announcing.
And some of that might be the time in the evolution of APIs, there was a time where it was still notable for someone to have an API. But still, even at that time, answering the question of why is this useful; what could someone build with this? Plenty of answers were, we don't want to hold back anyone's creativity.
But you need to have something to spark that creativity, and that's where those use cases could help from a documentation standpoint. And then what you're also talking about there is, from an attraction standpoint, how does someone even realize that your API could be the solution to this problem they have. They are likely searching for that problem, so finding is a way to tap into those search results is one of the best ways to be able to reach a technical audience. [0:11:53]
Richard Rodger: [0:11:55] Does that mean if I'm engaging EveryDeveloper.com, you guys are also writing code? Or do I write the code and then- [0:12:05]
Adam DuVander: [0:12:05] Sometimes, sure, yeah. We – the – our team, we don't always produce the content. Sometimes, we're helping enable a client to be able to produce it internally. But all of our writers are – and editors are developers as well; they have that background. So that yeah, sometimes that is what's needed, a little bit of code to be able to connect things together.
I do, especially with this – I know being a dev rel audience, I do caution that just because there's code doesn't mean it's technical content that will necessarily attract and engage that audience. It is technical content, but often, technical content is not enough to engage. So, that's where it goes again to that point of, let's – yes, we might need some code if that helps explain this problem that we're attempting to solve, but let's understand that problem first. [0:13:16]
Richard Rodger: [0:13:17] Gotcha. One format that I've seen – I'm curious if you do this as well, and also how effective that is. The format is, general technical question is addressed and then quite a lot of content is written in the first two thirds of the article, let's say, going in depth, providing perspective, really useful material on the problem itself.
It might be, how do I build an Irish language model; how do I deploy it, something like that. And then the final third of the article – and maybe bait and switch is the wrong term to use, because you've already given a whole bunch of useful content. The final third of the article is, "And we have the solution and this is how you can apply it." So, what do you think of that format? [0:14:08]
Adam DuVander: [0:14:13] It depends how long that is, how much effort you've given. I call that earning the right to be able to say, "By the way, we have a tool that does this." If you've given enough value, education, knowledge in that top part of the article, then I think you've earned the right, in some cases in the deepest version of that, something that I've called signature content, I call that the developer content mind trick. And that is, in the best of circumstances, you're describing how they would solve that problem without your product.
And that's when you've earned the right to say, "By the way, we've got this product." Because you already told them, "Here's how you solve this without us." By the way, we've been doing this for a while, but LaunchDarkly does this really well. And from the earliest days as – and their CEO, Edith, says that her goal is to say, "You can build it. You shouldn't, but you could." That sort of conversation, it's building up that audience. Yes, you can do this. But as you've said, by the way, we already have.
Can that be done poorly? Absolutely. And your description of it, maybe the two-thirds, one-third, that feels a little bit too weighted toward the product. And definitely, if someone is feeling any bait and switch feeling, then you've done that in a way that – going to raise that sort of guard and say, "This is marketing. Oh, no. Let me run away." Ideally, you want them to – you want the reader to explore further after this one piece, and not just – they might not be ready to sign up.
But what is the obvious next step for them to take? It is a little bit closer to the product? Are they looking at your documentation? Are they reading the next thing that is related and has another two-thirds or more of the article that is digging into the background? If you want to train that LLM, here's how you do it. That sort of next step, where it's not necessarily product focused still, but it's helping continue that educational journey. [0:17:14]
Richard Rodger: [0:17:15] Yeah. Developers are – I know; you know, right? We're so prickly. Just the wrong tone, that extra paragraph and you're out of there; you lose. You've got to be so careful. You have – as you've mentioned, your first book, Developer Marketing Does Not Exist, you go into all this stuff in that book? [0:17:38]
Adam DuVander: [0:17:40] Developer Marketing Does Not Exist, yeah, it's very much the philosophy. It applies this education not promotion philosophy to multiple different content types and areas. Certainly, things like blog posts and tutorials and guides, like we've talked about now, but then also, what does this look like when you go to events? What does this look like when you're interacting with the community and other things like that.
And that's often where there can be done type of content, maybe that comes from dev rel, that fully resonates; they understand the audience. But then if you have this other content that – or at events, that there's certainly content within an event that is incongruent with what you've seen elsewhere, then that kind of muddies the waters for what was a good interaction before.
It's how can you have this philosophy throughout all of your interactions. There's a reason that I start with developer experience as the first chapter, because my definition of that is very broad; it's every interaction a developer has with your company or product. That can go to who do they meet in the expo hall both, and is that interaction one that feels authentic? It's all about that philosophy. You mentioned the second book, which is Technical Content Strategy Decoded; that takes a piece of that and turns that into action, so it says, "Okay, now, it's – we're ready to create this content strategy that can apply this philosophy.
And doesn't – in that one doesn't go into events and advertising and other things like that that Developer Marketing Does Not Exist goes into, but it goes deeper into here's how you build this strategy. Here's how you do it in a way that can be scalable and can connect with an audience and help them engage with your content. That's how I keep them separate in my mind is philosophy in action. [0:20:12]
Richard Rodger: [0:20:13] That book is in the process; it's coming out soon, right? The second one, which is- [0:20:18]
Adam DuVander: [0:20:19] The second is available as an ebook right now, and very soon will be a print book and an audio book. So, hitting all the formats with that one as well. [0:20:32]
Richard Rodger: [0:20:35] I gave you softball, I'm getting a bit trickier now, okay? Because different products and companies need different strategies. Maybe you can walk us through an example of a first company and a particular content strategy for them and then the difference between a second company which maybe has a different type of market maybe, that sort of thing. Maybe the first company, developers use it directly, but with the second company, you gotta get the CIO on board or something; I don't know. [0:21:11]
Adam DuVander: [0:21:12] Exactly where I was thinking with that. And that comes down to whether they're what I call developer focused or developer enabled. A developer is involved in either case, but as someone that's developer focused, that's where it is; that developer first is another name that people will use for it. And that is, they want to reach that developer directly. That is a lot of what we've talked about now.
So, that would be digging into those developer problems and figuring out a content strategy that connects to those. Wanting to make sure that it's not scattershot reactionary topics and that instead, you understand these – HubSpot calls them content clusters. I talk about them as concepts, and building a concept catalogue is what I talk about in the second book, in the take action book. What are those areas where we think we can attract a lot of developers directly and help them understand this problem that they're trying to solve and eventually how we can help do that? The- [0:22:35]
Richard Rodger: [0:22:35] So, that's the developer focused strategy. [0:22:38]
Adam DuVander: [0:22:38] That's the developer focused one. So then, the developer enabled is more – it is a tool where someone else is the buyer, whether that is in that engineering chain, or often it's over in another department. But it is still a technical tool that developers are the ones who have to build, have to integrate, and because of that, have to be involved. But they are unlikely to be the one who discovers it.
So, here is where you again need to talk about these problems that it solves, but it's probably in a higher-level way, in the sort of way that developers might be less interested in that. They may discover it when they're on a project, but it's much more likely to have someone discover. It's that more classic B2B content.
Honestly, with developer in the name of our company, we do little of that, and we are more likely to think about where does that developer need to interact with that, and that is, where's that next step. That is a time when it's more likely to look like documentation, because again, they've discovered the product already.
So, the attraction part is not part of the goal; it's the – in some cases, it's just that simply the goal is get a developer's thumbs up. Other stakeholders have already bought in, but this is a place where – and we work with clients like this – where the deal is lost because a dev comes in and says, "I have no idea how to use this," or even worse, this looks like it's going to be awful to be able to integrate.
And I would – that might be when they go and they do their searches and they find something else; they find an alternative. And so, that would be a situation where having some attraction content for a developer would make sense for that type of company. But this is where you want to have documentation dialed in. This is where use cases would help, making it super clear when they arrive that you're solving the problem that they have been asked to solve.
And certainly, sample apps and getting started guides: the same sort of things you'd want to see in a developer focused company you still want to see. You want to see that great developer experience, because you're either looking for the thumbs up or you're even looking for them to further champion it within their organization, but not necessarily to discover it.
A lot of those things still have to be there, but I've had companies like that come and say, "We want to be the Stripe of such and such." And I caution them that not everyone has to be the Stripe of whatever you're doing, and you still want to have some of those basics that Stripe does have, but you don't have to – that's not your bar; that's not everyone's bar, right? [0:26:08]
Richard Rodger: [0:26:11] Adam, it's ironic here, because in the developer enabled area, developers can kill the deals. So, the difference that you can make – you can move the needle way more for those companies in some ways, if you think about it. Because – so we do a bunch of integrations for our clients.
And I can tell you that reading documentation or API documentation or doing integrations, those type of vertical companies, where developers don't do the discovery, is pretty painful.
And I can definitely kill deals, because I might have, in specific verticals – these are business verticals, boring stuff – I might have learned an existing API - it might be just a little bit better documented – and I'm like, "No way. These guys are better." [0:27:12]
Adam DuVander: [0:27:13] Yeah. Having a preferred tool and being able to say- [0:27:20]
Richard Rodger: [0:27:20] I just find it-
Adam DuVander: [0:27:20] -yeah, I think we should get over here. [0:27:21]
Richard Rodger: [0:27:22] I just find it so ironic, because the stuff that you do, those guys are starting from such a low base. If they just did a tiny little bit of your stuff, they would win. [0:27:33]
Adam DuVander: [0:27:36] Many times it is just small tweaks, so that's definitely what I encourage folks to do. It's not – especially if we hear, "We want to be the Stripe of" – it's like, no. Just take a look at – we've broken down developer experience into 13 criteria, so take a look at one of those a quarter and do something. You'll definitely see improvements as you do that. [0:28:05]
Richard Rodger: [0:28:06] Do you think developer enabled will become the majority? Because developer enabled seems like it's the place where a lot of vertical solutions live. [0:28:16]
Adam DuVander: [0:28:19] Yeah, I think it already is, honestly, the majority. There – many of those we don't even see. How many APIs exist on – behind firewalls that are opened up for particular partners, that are not at all marketed. The vast majority, for sure, fits into that mold. Unfortunately, most of them those might be maybe [0:28:54]
Richard Rodger: [0:28:54] I just feel like crying.
Adam DuVander: [0:28:56] Yes, exactly.
Richard Rodger: [0:29:00] It's such a terrible thing to work with. [0:29:01]
Adam DuVander: [0:29:05] Yeah, often is. And there's – my past also includes some time at Zapier, and I worked on the platform there which is connecting the APIs marketing the platform. And we were under 750 when I started and a couple thousand when I left. It was quite the – and they have continued to grow into the many thousands. I don't even know how much they're pointing to that number anymore, because it's hard to keep up.
But many tools that need to integrate with other tools, and those are just the SaaS tools that we're familiar with finding and signing up for and trying. And you have all – most of those are developer enabled, if there's a tool to be built. And then many others that aren't on Zapier or any of Zapier's competitors and aren't broadcast at all. Maybe there's a partnerships page that vaguely describes, if you fill out this form, that you might hear back about something. [0:30:29]
Richard Rodger: [0:30:31] When you're – just to narrow in on the actual work of doing those integrations, was that super painful? How did Zapier organize it so that developers could efficiently integrate with new APIs? Was it just – did people brute force it or did – was there special techniques being used or what? [0:30:53]
Adam DuVander: [0:30:55] It's the platform that enables it and says, "Here's how you connect an API into triggers and actions, which are the two primary methods." New data coming in triggers a zap and data goes out as an action. And there's roughly connect to end points, but usually not one to one. Sometimes it's – this requires multiple calls.
Enabling the description of those and putting a lot of that work on the provider themselves. Very few of the Zapier integrations are built and maintained internally by Zapier. Most of those are external partners who have connected their API to it. It's still a lot of work on both of their parts to understand when it has problems and where to address those problems. And the larger question for me in my time there, which is relevant to our conversation here, is, is that even a developer on the other side.
In many cases, that Zapier platform audience is developer enabled, or in some cases, someone – it's someone in product or support, sometimes marketing, someone who wants to say yes to a user on, do you support this; do you integrate with this. Or solve their problem. And that often, in a SaaS company, is not a developer who's attempting to solve that problem.
That was one of the things that I've written about this too, that we discovered, is just how not-developer-y, in the traditional sense that all of us who are talking about dev rel would think about developers, that Zapier audience is, the Zapier platform audience. It's a little more like the primary Zapier audience than I even recognized going in. [0:33:15]
Richard Rodger: [0:33:17] Do you think we're going to see a lot of AI agents and things like that talking to things like Zapier now? Is that – should we be worried? [0:33:27]
Adam DuVander: [0:33:30] I don't know about worried, but it's definitely – we will quickly get overwhelmed by all of those tools and we'll certainly be about figuring out which ones do what we want to do, which ones help our work and which ones are a distraction. But I- [0:33:49]
Richard Rodger: [0:33:49] This is the internet connected coffee pot and this is SkyNet; it's like stick to the coffee break. I really like this distinction. I see your book covers it at a structural level, this developer focused, developer first versus developer enabled. That's a really powerful model to approach this issue at a strategy level. [0:34:20]
Adam DuVander: [0:34:20] It's been helpful with clients and with even leads that don't turn into clients, to help them realize that a lot of – in some cases, it narrows down the scope because it's – we don't need to be the Stripe of whatever we are. It's – and helps them focus in on what are the problems we're solving and who has those problems, so what's our goal.
Richard Rodger: [0:34:47] Here's a question for you, Adam. If I'm a developer enabled company, do I need to have developer advocates? How much developer relations should I be doing? [0:35:00]
Adam DuVander: [0:35:04] That – I don't know that I have the answer to that question, but it's one worth asking for those organizations for sure. The work looks different, much like I've described with the content, so it's more of how do we give someone to interact with, to be able to help make this decision or be able to help get that thumbs up. And the more you talk about that, it sounds a lot more like sales engineering, which there's an element of that that dev rel has, so – or dev rel can have.
So, being able to describe exactly what that is. One of the things we didn't talk about in developer enabled and that can help get the thumbs up – you mentioned the other tool that you might propose – how did you find out about that tool? You may have found out about it because they have a dev rel team, because they have some of the effort.
If there's some effort put into the attraction piece, which is a little bit in the awareness bucket from a marketing perspective. But if you have some effort into that, then you've heard of it before. And then when you get asked, it's a thumbs up because you've heard people talk about it and you've even poked at it maybe at an event.
You aid, "This is cool. We don't need email infrastructure right now. We're fine with what you have." Until you get into the meeting where they say, "We've adopted this big enterprise tool and we're about to sign" and you say, "Are you sure you don't want to use Sendgrid or another SMTP as a service? So, that's another piece of developer enabled – and a reason why someone would have a dev rel team is to help with that interaction with the communities. [0:37:14]
Richard Rodger: [0:37:14] Very – yeah, it's very powerful signaling. [0:37:17]
Adam DuVander: [0:37:17] Yeah, it streamlines the thumbs up. [0:37:18]
Richard Rodger: Yeah, you're signaling that you care about developers, which I care about, because my boss is shouting at me and I'm the one working at weekends to deal with your crappy API. So, it has a place. And that's interesting that you mentioned about sales engineers, because there's a little bit of overlap there, isn't there. That traditional role involves going on calls and doing architecture diagram PowerPoints and that type of stuff. But maybe it's starting migrating a little bit, evolving a little bit into developer advocacy as well. [0:38:02]
Adam DuVander: [0:38:05] Yeah, and the line could be whether someone is actually a sales lead or whether this is pre-sales activity. And the line will be different for many companies. But it's worth – especially if you're in dev rel at what sounds like a developer enabled company from what we've talked about here, it's a question worth asking. What are the activities that make the most sense given my company, my products, right? [0:38:42]
Richard Rodger: [0:38:43] Absolutely. Adam, we have come to the end of the line unfortunately. We could keep going forever; this is super intriguing stuff. Thank you so much for the books. One of the things they do is add to the baseline foundation of knowledge/figuring out what developer relations actually is.
One of the things that come out from this podcast is, we're so early. We're not quite making it up, but we're figuring it out for sure. We've got at least another five or 10 years to – before we even understand what best practices are, how to measure stuff properly. So, you putting it down on paper is really helping the community. Thank you. [0:39:34]
Adam DuVander: [0:39:35] Thank you so much, yeah. And it was great to be part of this, thanks for having me on. [0:39:38]
Richard Rodger: [0:39:40] Awesome, and I look forward to book number three, next year. [0:39:42]
Adam DuVander: [0:39:43] That's right, yeah. I'll get to work. [0:39:45]
Richard Rodger: [0:39:47] All righty. Take care, Adam. Bye-bye. [0:39:48]
Adam DuVander: [0:39:49] All right. See you. [0:39:49]
Endnote
Richard Rodger: [0:39:50] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:40:17]