Adam DuVander

All right, here we are. Welcome back to Breaking Changes, and I’ve got another one of my good friends here as a guest. Today I’ve got the head honcho, the big D in charge of Every Developer, also from his past as a former ProgrammableWeb API guru person, Adam DuVander, joining me on the show. Welcome, sir.

Thanks, thanks for having me, Kin. I’ve been doing, well, I have to admit, I started Breaking Changes kind of on my Rolodex, getting all my friends to come, all the people I’m super comfortable talking with, and trying to use that as a runway to making this show happen. So I appreciate your support, sir.

Oh yeah, of course. So you worked previously for ProgrammableWeb, you worked for several other companies along the way, and now you’re running Every Developer, which is independent, helping folks make sense of the, I don’t want to say developer marketing space because developer marketing doesn’t exist, which we will probably get to at some point here. But why are organizations needing Every Developer? What skills do you bring to the table that makes it something that companies are looking for?

Yeah, I feel like I’ve seen both sides. At ProgrammableWeb I was trying to make sense of the APIs that people were producing and the API products that people were producing, and I’ve told the story about having to dig within those press releases to figure out why the heck it mattered and how. I felt like that should be the story that they’re telling themselves. And then I went on the provider side and I saw, okay, there’s other things that you have to deal with. Yes, it’s important to be able to do that, but there’s a lot that’s going on. And so I gained maybe some empathy that I didn’t have when I was at ProgrammableWeb for what it’s like to be building these products within a larger vision and a larger company. And so I also got to do some of those kind of announcements and things at places like SendGrid and Zapier, and I hope did justice to the sharing of what actually matters about that. And then I recognize that there’s a need that’s greater than any one company for being able to help tell those stories of why this technical stuff matters, and help reach that audience that is sometimes skeptical of the messages, that is oftentimes skeptical of the messages that are coming to them. And so that’s what we at Every Developer help companies do: understand what are those problems that they solve that developers care about, and how can you tell that story in a way that attracts those developers and makes them feel like that’s an authentic message that’s coming to them, because it should be, when done right.

Yeah, and your style always for me reflects that balance, that nice balance, because it ain’t easy selling to developers or even talking to developers, not even getting to a point where you’re selling, like supporting and getting them interested in what you’re doing. So you’ve always managed to find that balance, I think, that sweet spot. But as far as your agency doing it, what’s different than if I just built this in-house? I’ve got my company, I could build this, I could hire folks to come in and do some of what you’re talking about. What’s different?

A lot of the clients we work with do have teams that do this, and I think that is important, to have some internal skills in these areas for sure. But oftentimes we’re brought in as that outside eye, to be able to see it with fresh eyes. And that’s something that, you know and I know from being on the inside, it can be hard when you’re kind of blinded by the larger picture of where things are going, and it’s sometimes difficult to see it from that developer perspective, which is so important to actually be able to do, to see it from the eyes of someone who you want to attract, because you want to make sure that the message that you have is resonating with them. And so I think that an outside perspective is probably the biggest thing. And then another would be that there’s not always the internal muscle memory for this type of communication. And so being able to come in, help someone see the way that people see them, developers see them, and then be able to say, okay, you can do this, you have the capacity to be able to approach developers in this way that will have them coming toward you, not running from you.

But they’re just developers. Can we just throw some documentation over the wall and they’ll be happy?

No. But also, oftentimes that documentation isn’t what they want anyway. You throw it over and they go, nope, not this, and they throw it back at you, right? And that’s only one of many types of content that you should be thinking about, whether those docs are the case. Many times the most common mistake is the docs just say, black and white, this is what it does, which kind of goes back to that storytelling from the top that I was mentioning. If it’s just black and white, just the facts, you know, Dragnet documentation, that’s an old-school reference for you.

We’re in the hat, so you’re dating yourself there.

If it’s just that sort of black and white docs, then that leaves the developer to tell themselves the story of what this does. They look through and they look at the endpoints, and there are times when they want that. But the more, if you want them to get to a realization of how this will help them, then you need to be able to put that in there. And so to me, documentation goes well beyond “here’s what’s possible, here’s what you can do.” Actually, what’s that larger picture, the what’s possible, the “imagine this,” contextualizing it in use cases and problems that the developers are bumping into every day.

Developers kind of seem like a needy bunch, you know? They’re kind of picky about what gets thrown at them. Why is that?

Yeah, I’m not sure that I agree that they’re needy.

Well, I am. I’m undefeated and you’re needy.

I wasn’t talking about anybody else, I was just talking about there. But yeah, go ahead. I think the reason developers sometimes come across that way is that it’s kind of their job to be skeptical. That’s like, you need to be able to look for edge cases and catches in code, and that’s how you do your job. And so then why shouldn’t they maintain that same outlook when they’re out looking for potential products for their company to consume? I mean, they need to continue to look for those edge cases in the products that they’re thinking about. And I think for sure it comes down to, if they’re getting a bunch of stuff kind of promoted at them, that’s going to, they’ve seen that before, that’s going to raise the hairs and make them say, okay, where’s the catch on this? I think that’s the case. I mean, everyone looks for the catch in marketing, but I think it’s especially apparent with developers, and can especially happen when the messages are coming sometimes from someone who doesn’t understand the technology behind it. And that can often, if it doesn’t hit the mark, then that’s going to raise some flags in the dev’s mind.

Yeah, I mean, I’ll backtrack on that word, needy or special or picky in any particular way. I would say we’re not any more needy than any other kind of target group that you’re marketing to or trying to reach with your business message. We just, I don’t know, certain types of stories, certain types of things interest us. And I think back to the heyday of, I guess, Web 2.0, the early days of Read/Write Web and TechCrunch, and then ProgrammableWeb came out. What are the types of stories that catch my attention, my eye? ProgrammableWeb spoke a certain language for me. It stood out amongst the crowd. So what was it like in those early days working at ProgrammableWeb? When you first started, give us a taste.

Yeah, so it was much smaller than I think it is now. It was primarily me and John Musser and one engineer and a few other freelance writers in the earliest days. I wrote for a year and a half before joining as the editor, and when I did that I joined full-time. I was writing a book on mapping APIs at that time, when we were introduced. And yeah, it had to have been below 2,000 APIs in the directory at that time, but there was still always something new, you know, maybe not daily, but there was always new APIs to look at. And it was a time where a lot more, so I mentioned mapping APIs, so Google Maps was sort of one of the ones that kind of showed the way of how to be, and so a lot of APIs were just wide open and there wasn’t as much connection to a business strategy, certainly not payment for API. I mean, Google Maps was free for a long time before they started charging for it, and even still, most developers can use Google Maps for free forever. You really have to be at significant usage. And so it was really a time of kind of exploration and possibility that in some ways I long for. I really like that looking at what’s possible, connecting things together. The founding of ProgrammableWeb was John looking for things to be able to connect together and kind of wondering to himself, could I look at listings on eBay and listings on Amazon, Amazon Auctions, and use APIs to cross-post and somehow work some arbitrage magic in there, those sorts of things. And he went around and said, I don’t see any place to actually find all these APIs, and that was really how it was founded. So in that kind of world of exploration that in some ways exists in a much larger way now, just a different way with all of the API-as-product tools that we see now. And the best part, of course, you and I have integrated with a few APIs in our time that went away, I’m going to say. So at least there’s now a business model behind these that can keep, as we make exciting things, can keep them afloat, keep our own projects, let alone the companies that provide those APIs.

Yeah, so that’s the, yeah, good.

No, I’m sorry, I didn’t mean to cut you off. The business model, sometimes it was painful, but now I would say we’re much, we’re not quite a totally mature, grown-up sector, we’re still kind of in our infancy, but, and I think those early days we were kind of naive about, this is free, this is great, and this scales, like I can load up as many images or whatever I want into these. And so I think we’ve kind of grown up in our approach. But my RSS feed for ProgrammableWeb, the blog posts and the new APIs, that’s what really caught my attention on a regular basis. Just a steady drip that kept me coming back and reading until I eventually came and wrote for ProgrammableWeb too, for a short period of time. But we’ve come a long way, and I have a steady drip of content types that I put out there. Sure, I’m always looking for that next creative thing. The new API feed for ProgrammableWeb was definitely very eye-catching and caught my interest as a developer, but reading blog posts with titles, with descriptions that speak to me are still the most valued currency in my world. A quick story that helps me learn about something new, solve a problem, do something, that’s a cornerstone. And then I would say other, some longer-form content and workshops and kind of training stuff is always, like, I like little nuggets that teach me something. So what are kind of the core content types that you advise your customers and clients, and you help them with when it comes to this outreach?

Yeah, you’ve hit on some of them already there. And really going back to the time when you were listening and hearing those sort of headlines of what’s possible with APIs, that’s a piece, like, as much as I long for that time of lots of possibility, that also had its own issues, because that was what led to some of those press releases that didn’t actually say what was possible, because everyone thought, oh, the way you do this is you just open this API and then magic happens, right? And so some of that content that is able to frame what that means, the classic piece, of course, would be an announcement post. But that announcement post should really be framed around why it even matters and what are the problems that it solves. And so really, as much as that’s one announcement post, it’s actually many potential articles that dig into the actual use cases. So what are the things that you want someone to do? And we would have providers tell us, oh, we don’t want to hold back anyone’s creativity, they can do anything with this, and like, okay, yeah, maybe, but let’s list a few anyway, right? And within there, certainly blog posts that dig into particular use cases, but then you can have sample apps that are built that speak to that use case, tutorials around each use case, those being other types of content. I mean, a sample app is really more code than content, though for a sample app to be most useful, I think it has to have kind of a tutorial alongside it, have a code repo that is easy to copy, those sorts of things that make it clear what the next step is that a developer could take with it. Other types of content, kind of going longer form, I really like, I call it guide content, but it’s kind of taking the developer’s problem to the furthest edge that you can. So understanding, you want them to find you because they have a particular problem that yes, you solve, but you kind of have to, if you put up that “hey, we solve that” too quickly, that’s seen as promotion. So how far down that line can you walk with the developer to show them that you know about your topic really well? I wrote a post for Heavybit that is called The Developer Content Mind Trick that talks about this, and it’s a big part of the guides chapter in the book, which, you mentioned briefly the title, Developer Marketing Does Not Exist. And the idea there is that you want to, if they want to build the thing that you’ve already built, okay, let’s walk them through, let’s show them what that really takes. When I was at SendGrid, the most popular guide we had, which the guides at that time were PDFs, which I would for the most part caution against, but it was a deliverability guide that walked someone through here’s all the things that you have to think about if you want to have email that gets consistently delivered to people’s inboxes. And some people might read through that and say, awesome, I have my checklist now, and as a developer I want to build, because that’s like the natural feeling that a developer has anyway. But if you can help them see some of those edge cases that they maybe wouldn’t have seen without kind of walking through it, then some amount of them are going to say, you’ve provided me a great checklist, I’m going to go off and build this now, but a good amount of them are going to feel like you really know what you’re talking about and you’ve clearly found these edge cases, and guess what, you happen to have a product that does the thing that we need to do. And so that at least will get you to the stage where they check out what you have. Now, you still have to have a great product and great documentation and all those other things that you’re going to need to convince them, but that type of content does a really good job of being able to attract those developers and gain some trust with them, which is really a big part of what you need to do. And content can do so well when, yes, you have this one big piece, but you can include within that additional blog posts that talk about one particular piece of that that then can link back to that guide as the sort of next step. So you can put out these feelers of content, smaller content that picks one particular use case or one particular area, and then can attract them in and point them to something where they can learn more. And so that’s really, like, if you can spark a developer’s curiosity and desire to learn, then you’re a long way toward actually being able to convert them, in market speak.

Yeah, I mean, I could see, you’ve got to throw out lots of little things and see what works, what catches people’s attention, kind of what lures are going to work, fishing, you know, to really keep them, well, onboard them, activate them, and kind of move them forward in their awareness. But as you said, also trust, I think that’s a critical one. But you and I have suffered from the same kind of syndrome doing this for so long. Where do you find inspiration to write all of these little nuggets? I’ve met several teams that do very well for like a three- to four-month period, and then they hit a dry period. Where do you find inspiration?

Yeah, I think you can go back to see what has resonated and what has worked, and there are always more stories within stories to be found when you have some areas of where you’ve seen a spark. And so looking there, talking to developers and understanding, I know, shocker, talking and understanding developers and understanding what issues they’re bumping into right then. You can find places online so that you can only read what they have to say, go on Twitter and listen to developers, you don’t have to talk to them if you don’t want to. And really continually be looking. It really is kind of a journalistic practice, that sort of ongoing part of finding those stories and seeing those stories that are already there and telling them.

So it sounds like you need on your team Every Developer, but also within some of these companies you need curious people who are going to scratch at these and try to understand. So are these developers who write these stories? Do you hire developers to write these, or who is it that writes?

Yeah, it’s a good question. I think that probably some developer background is necessary to be able to tease out some of these stories. It doesn’t have to be a senior engineer sort of level, but being able to at least have the empathy with the things a developer goes through in their work, and having been one who wrote some of that code and struggled some of those struggles. When I was at SendGrid, I used to joke that I invented SendGrid because I had bumped into that exact problem of email deliverability as a developer at a company that just wanted to send out some email to someone who just signed up, right, and it had hit spam. So being able to have that background that has experienced at least some of those developer pains goes a long way. Maybe the right person who has sort of a journalistic background can get at that via a lot of conversations with developers, but in my experience, some developer background helps a heck of a lot.

Yeah, I think you’ve got to at least be curious enough to hack at and poke at and reverse-engineer and want to know what’s going on. You may not have to have all of the formal training and things, but you’ve got to be curious and want to dig and scratch and get in there. So is this a skill set that people just show up and you hire and they have, or is it something that you can cultivate over time? Because I come across a lot of organizations who really haven’t had any luck hiring to find these types of people, but they’ve got some people that are interested internally. Can you cultivate this somewhat?

Yeah, I think if you have, and this is one of the roles that we play, being able to point out some of those angles, that once you have that sort of, like, oh, this seems like a topic, which is hard, like that’s the thing that might take the years that you and I have experienced of, like, oh, this kind of seems like there’s a story here, right? That sort of taste is a tough one to hire for and to find. But if you’re able to have some way to be able to find those little sparks, then I think the rest can be taught. And I think that the other can be taught too, it just maybe takes time. The actual investigation and writing and piecing together the story, I think that certainly can be taught. As for what to look for internally, I think you pointed out the curiosity. In the book I go into your developer marketing organization and kind of look at a mixture of the writing and kind of analytics and various things that you might not find, like it’s rare that you’re going to find these, whatever they are, eight or ten things in one individual, and certainly not at, you know, it won’t be that they’re topping all of these skills, but some kind of balance of these, that then you’re able to put together a complementary team. And I think that’s one of the areas, so at SendGrid that we did well, was to be able to leverage some of the developer relations approach. So these were developers who were many times out meeting the developers who used SendGrid, and how can we take those insights and scale what they would have been saying from one person, an evangelist, to one developer or even a room of, I don’t know, 50, 100, 300, but how can you take that and scale that even further with content to be able to enable them to produce the content? And I have seen a number of organizations struggle with that, where you have a marketing team that really wants to be able to hit their numbers, which might not be aligned with developer relations numbers, but if you can take this approach that we’ve talked about of really starting with what developers want, what they’re looking for already, and if you can find a place where that meets both the marketing need and the developer relations need, I think that can be a really good way to find them, to look there, if you have that in your organization, before looking, like sometimes I’ll see companies look to get engineers to write. And if you have someone who has some of those non-engineer skills that make that a really natural fit for them, then that’s great, but a lot of times they don’t, and so they need an editor to pair with them, or really a ghostwriter in some cases, because another thing that engineers need to do is to make sure that what they write is rock-solid, like when they write code it has to be rock-solid, they tend to take the same approach with what they write in content, which leads to over-polishing. And often, you know, how long did that take you? Oh, I mean, it was, not the whole week, most of the week, and you go, a week of engineering time, like, right, that’s not something that could be sustained across an organization typically.

Yeah, I mean, you touched on, I was going to dive into, like, how do organizations know how to scale this? Is it hiring more writers, is it bringing engineers out of the team? But you really talked about, I would say, a grounding aspect of, like, if you’re out there talking to your developers in the communities they’re on virtually and in the before times and hopefully soon we’ll be going out to actual events and meetups again, and you have your finger on that pulse, you tend to have a better idea of what you need to scale and where you need to scale. And I would say that’s another source you could pull from, is the talent in your community. Use it as a feedback loop to grab stories, but then also look for those talent acquisition people you can hire or bring on, or make champions, or some sort of community managers, and use that to kind of ground your, but are there any other ways? When it comes to scaling, what sort of advice do you have for a team, like, how do we scale, what are the areas that we should scale first?

So another area that I think sometimes gets overlooked is whether the content you’re producing is strategic, whether it’s even a connection. Often you get to scaling before you actually think about what you’re scaling. And so you could produce a ton of content, but if, so if for every 10 you actually wrote one that was connected to what you clearly know developers care about, not just the one person that got a bug to follow a particular topic, but you know that you hear about it consistently. You can do some quick searches, I’m no SEO expert, but looking to see whether other people search for this thing, what do they, and how do they refer to it when they search for it, right, to make sure that the things you are covering connect with how developers are actually thinking about the problem set that you approach. So really, sometimes that scale can actually mean scaling down, but scaling down on the amount of content but really making sure that it has the best possible chance. And there’s obviously a balance there, because you could spend all year on one magical piece of content that might not hit the wall when you fling it, maybe because it was based on something that developers cared about nine months ago, right. So you do have to have sort of some consistent drumbeat to be able to get the feel there, but making sure that the shots that you are taking there, that you have some reason to believe that that will connect. And sometimes that can mean real data, and sometimes that can mean that sort of taste that you and I talked about that I sure wish I had a better way to be able to communicate to people.

Yeah, I mean, so it’s not enough to connect that I get top page of Hacker News for one post, it’s got to be deeper than that.

I think so, because that one can bring a lot of traffic for sure for that day, and maybe that trend translates to something, but I’ll say in my experience it’s been much more fulfilling to have written things that get a few hundred developers every month checking it out versus the, you know, 10,000 or whatever it is on that one day. That sort of consistent attention, and knowing that you’ve solved the problem there, and you start to get people writing in about it and tweeting and really seeing that you’re actually solving a problem there, and that’s the stuff that’s hugely fulfilling. That sort of big spike from Hacker News can feel good, but there’s a sugar crash that comes after that.

Yeah, you’ve got to reach, I think, reach folks at a more meaningful level and see it as part of your feedback loop. You said you’ve got to see that there, people are searching for things that you’re making, that you’re making that connection, it’s not just page views. And I would say that dovetails with your wider strategy, because you’ve got a keyword strategy you’re thinking of, you’re looking at the searches, you’re thinking about how developers are searching, and then hopefully as part of that feedback loop you’re engaging with them and kind of reinforcing what your assumptions are. You’re not just relying on your dashboards, your Google Analytics or your API management analytics, those feedback loops are actually reinforcing what’s sticking against the wall and what’s not. So when it comes to using the products, we talked about them being developers or not being developers who write this content and produce this, and you mentioned DevRel. So do you have to really be intimate with the product? I know there’s a lot of marketing folks who don’t use the technical, so how do you balance that and get marketing folks, I mean, okay, I guess I led that one a little bit, but I feel like this storytelling should be, if you’re going to reach the strategy level you’re going to have more than just DevRel people, you’re going to have marketing, you have business folks involved, and so how do you reconcile that when it comes to that storytelling? You’ve got to have all those people at the table, but how do you make it so that, you play on your book title, Developer Marketing Does Not Exist, you play on this kind of, you know, marketers just want to market and market to developers. So how do you balance this across building a team and organizing it?

Yeah, and I’ll point out, I never said that developer marketers don’t exist.

No, no, and you got it right, but, so we have to reconcile that, right, like, no, developer marketing doesn’t exist, but there are developer marketers, then what does that person do?

And so what I go into in the book is this philosophy that does start with understanding that developer’s place and what they want and what they’re looking for, and being able to educate them and inspire them to go through the journey that does hopefully include your product at some point, but if you put that too much in the beginning, then many of them are going to walk away, right, because you want to be able to tell a story that makes sense for why your product fits in there. And so when you ask what they can do, I think it comes back to some consistent problem with developer content is lacking any point of view. And so, sure, sometimes it’s full of features instead of benefits, but really at the heart of that is every company is founded with an opinion, and it’s okay to share that opinion, in fact your content should share that opinion. And so I think someone doesn’t have to be a user of the product, like a deep power user, to understand why that product exists, and that point of view and that opinion that the company was founded on. And I hope that dev-focused companies, including some of the ones who are listening to this now, think about that as early on as possible, because it is there, and the founders know it, but it’s sort of implicit probably in their minds, right. And so being able to share that as part of your company’s story, both internally and externally, to make sure that, and content that doesn’t have a point of view is often boring also, so this is a way to also make it attract the right developers. If someone agrees with your point of view, they’ll be attracted, they probably will be attracted if they disagree also, but, you know, to be determined whether they stick around after they’ve heard you out on your point of view. But I think really trying to understand that would be, if there was a developer marketer on day one of a dev-focused company, that would be the important thing to figure out: ask why do we exist, and ask that until you get an answer that makes sense.

Well, I think for me, the developers are pretty blunt for the most part with their critique, and you should be able to listen to that as a business, as a founder, as a co-founder, as a business leader. You should be able to at least understand why it’s not solving, you don’t have to understand the technical details of why it fell short, but understand why there was a miss there. And it feels like you’re saying your product roadmap, your marketing, and your developer relations there at least has to be an alignment, and that feedback loop has to cover all of that, otherwise your product’s way over here, developers are way over here, and no amount of content is going to close that gap, right.

Yep, yep.

Yeah, it’s an interesting game, and I think that for me that bridge is the classic divide that we’ve all heard between business and IT, and storytelling is kind of how you heal and bring those into alignment, and it’s that perpetual storytelling that I think keeps you from going too far, you know, because you can go too technical too, and build the best tech, I’ve seen the best APIs get delivered and no one cares, and they were REST level four, you know, it was dialed in, and no one cared, because it didn’t have a business strategy, it didn’t have any of those things. So now I got off track of my list of questions, but I knew that would happen with you, sir, and that’s what I like. So as we’re heading back, I feel like, so in California where it feels weird, but we’re open for business as of today. What’s it like in Oregon right now?

It’s getting there. Yeah, I had coffee without a mask with a friend today, so it’s a new world. So we’re getting there.

Yeah, I’m feeling like we’re going to go back to meetups and we’re going to go back to events. Do you have any recommendations as far as, I mean, not just COVID, but just in general, like what’s the balance, how do you know whether your team should be going to meetups and events and being on the road, and how much time you spend just back writing good content? Do you have any good advice for folks?

Well, you mentioned how you get ideas, and a good conference trip always sparks multiple ideas for me, so that’s definitely both from talking to developers but also kind of sharing knowledge with colleagues at other companies, all of that happens at those events. So I’m not sure how to say how many to attend, but certainly I think we’ll see DevRel returning there. I think if you’re a developer marketer in an organization that has DevRel or anyone who’s kind of developer-facing like that, it’s worth, you know, once a quarter or twice a year, tagging along and seeing what that’s like, because guaranteed you will learn something there. And then we’ll also see a lot of marketing going back to events as a way to reach developers, and this same philosophy that I’ve talked about can be used in person also. And in fact, in some ways it’s easier, because it’s hard to fully promote something when you have another human in front of you who’s giving you all the signs that they don’t want to hear more about it, right. So it’s a way to be able to see what’s hitting the mark with the way that you talk about things. But it’s also, if you can look for ways to be able to educate and inspire at events as well, you’ll get many more people coming to your booth out of curiosity than out of sort of answering your bullhorn calls offering candy, I don’t know.

Yeah, I would say, over the years, I think there’s 5,000 blog posts on API Evangelist that I’ve written, and I would say about 60 are written either on the road or just after, because I come back with that head full of goodness, and sitting down with, I’m just rattling off the places I know that I’ve sat down with you, in Chicago, New York, San Francisco, Amsterdam, like all around the world, the places I’ve sat with you and had conversations with you, but other folks like you, and then coming home and being all directed. So it’s always that balance, because I would say I hit dry periods at home where I’m not traveling and I can synthesize stuff online and kind of read, but there’s nothing like that face-to-face feedback that you get from folks, and hearing what they face, that makes a difference. So I’m kind of eager to get back, but I’m also a little nervous too.

Yeah, it’s a different world.

So, kind of, not coming quite to a close here, but let’s get out of the weeds, I guess, of what you do. And how have you done it so long, how have you not burnt down? I mean, I know this is something that I struggle with, so how do you keep going?

Yeah, there was a time that I talked about the aha moment as the thing that I did it for, so developers are having that moment when they first use an API that does something cool, that sort of aha moment. I think that my aha moment has maybe changed a little bit now to be a little more meta, the aha moment is how can I help other people be able to do this sort of story-finding that I’ve done, which I get to do with clients, I get to do with the Every Developer team. And so it’s still that aha moment, but it’s a different aha moment, I think, than maybe it used to be. So finding those ways to get excited about the work that I do, which definitely includes conversations like this, I’m sure we’ll both write a couple blog posts after this call is over.

Yeah, I’m actually finding, Breaking Changes has kind of become my new creative drive, so I’m seeking people out, trying to find ways of driving my storytelling through this, using this as a vehicle. And I’m finding balance with the Zoom conversations in this, I would say, but I’m really itching to get back to Portland and hang out with you proper, and there’s something that you can’t replace with that. And it’s why I would say that’s why I was able to get this show off the ground using my Rolodex of friends, because I’ve hung out with you all in so many cities and talked at different companies that you’ve worked at, and that I think have made a difference in our careers. So what recommendations do you have for people that are looking to get into what you do, creating meaningful content for companies, either as a job or as a freelancer? Where do you get started, what do you do?

Well, the great thing is that anyone can publish content on the internet, it’s easier than ever. And so I think starting to look for those stories and telling them wherever you can, so that could be your own dev.to blog or Medium or your own site, and then looking for, I mean, look for the companies that you respect and get excited about. I know everyone listening to this that represents a company would be super stoked if there was a post that someone wrote that was positive about their company and dug into one little area and one little story. And so I think that you can certainly gain attention that way from those that you want to work with, and all the while kind of working on that muscle of finding the story and telling people why something’s important.

Now, that reminds me of back when I was first trying to find my voice and writing story after story and no one cared. I was trying to get on Hacker News, no one cared, I’m trying to, you know, Twitter, one retweet at the most, and then I remember John Musser, who founded ProgrammableWeb, pinged me on LinkedIn, was like, hey, I like your storytelling, you should do this, you should, hey, come write for us. And then he pinged a few other folks and said, hey, you should read this, you should read this, and I remember Daniel from Netflix tweeted something out, and then it just kind of ratcheted up from there. It was just doing it long enough until you found the right voice and captured someone’s attention that mattered, that was kind of an amplifier or a maven in the space to a certain degree. And you can get folks’ attention. And then, writing books on mapping, I think that’s a great way to do it. Do you still have a copy of that book?

I have, I believe, the last four copies in the world on my shelf back there.

Nice. That was huge. Google Maps was like one of the main reasons that I got into APIs, because it’s one of those, like, I would never be able to build this API, and it’s a super-critical part of much of the web.

And I mean, we take for granted now that everything that has a location attached we can now view not only on a map but in relation to where we are, and that was not always the case, right. And so those are some of the tools that give everyone the ability to do that now.

So if you had all the funding in the world, if someone walked up and said, hey, we’ve got a million dollars for you, would you still build up Every Developer like you’re building, or is there something that you would do different?

That’s an interesting question. I mean, the things that I am searching for are the ways to be able to help more people do this the right way, and so I would look for some way to be able to do that even more so, and whether that is more people or more software or some combination, I’m not sure. But it still would boil down to the same sort of approach that can happen kind of one blog post and guide and tutorial at a time, and so I know that would still be the output, whether that would be us writing those or really enabling a larger community to write those, I’m not sure, but yeah, I’ll have to think some more on it.

Yeah, I mean, from what I heard, same outcomes, just you try to figure out how to expand that reach. I mean, I see TED Talks, I see you pacing back and forth on stage with a microphone in front of large audiences, things like that. So to close, what’s the impact that you’ve made on the space? I feel like you’re one of the, I don’t want to say dinosaurs, grandfather sounds too weird, you’ve been doing it a while.

Well, you’re definitely making dragon references.

Yeah, you’re making dragon references, yes, okay, all right. You know, what impact, what have you left? I know you made your mark on me in my career and how I write and do things, because I’ve read so much of your work and I’ve listened to so many of your talks at my conferences and various things. But what do you feel like you’ve left, and are going to continue leaving?

Yeah, well, I hope that it’s, to me this concept, Developer Marketing Does Not Exist, is really about saying, pretend like it doesn’t exist, because if you take that away, what you have left is this really genuine approach to helping people and inspiring them to do what they want to do next. So I hope that the impact is that people see that that approach is actually the more successful route than the sort of direct promotion kind of route. So I hope that what I’ll see eventually is that at the very least every dev-first company comes at it with this approach, because it’s the way that they’ll be successful. And then perhaps at the next level is the developer-enabled companies, which are the many that have APIs but maybe developers aren’t their primary audience, but I think there’s still something for them to learn about this too. But let’s reach the dev-first companies first, and then we’ll go from there.

No, I think, and for me your book really just kind of brings it front and center for folks, like closes that gap, makes it so that people think about what matters. And I don’t want to push back on marketing, because marketing is essential, but there’s, especially in tech, we’re allowed to kind of disconnect us from our users, and I think the product, as I said, helps keep us aligned, but developer relations and actually talking and having those meaningful relationships, and so I think your book does a good job of kind of closing that gap, but, as I said, connecting it with a storytelling kind of approach, because that’s really, with the right feedback loop, that’s where you’re going to make the difference. And that’s, I would say, your contribution to the space that I’ve seen, is you’ve always had this, oh no, it’s a Portland thing, so I’m from Oregon, so, like, this nice-guy Portland persona that’s super knowledgeable, super deep, able to go down the technical holes but elevate to the business, and you’re just a super-nice guy, and I think you’re taller than me too, which kind of makes it a little weird, because you’re really big, but then you’re also super nice, but you have this kind of genuine approach to how you do things. And I modeled part of my schtick, I went a slightly different road, but I kind of borrowed some of those nice-guy, genuine approaches, and I would say Musser had that as well, and this came out not just in you guys’s writing but on stage, and that was why I always brought you both to the conferences that we do, and then you’re here on my show helping kick things off, because of that genuine approach. And that’s your mark, I would say, that’s how you don’t burn out, that’s how you do this well, that would be my advice to everyone, kind of building on the impression you leave. So with that said, the book is Developer Marketing Does Not Exist, you can follow Adam DuVander at everydeveloper.com, you can follow him on Twitter, he’s pretty easy to find. Thank you, sir, this has been fun.

Yeah, and thanks so much for the kind words and for having me on.

No, anytime. You keep banging on your door and we’ll keep scratching each other’s back in this game and see what we can keep building. I feel like, I won’t reveal other shows that are going to happen where we’re going to talk about, but other folks that you and I have hung out with, I feel like we’re just getting going, there’s kind of a new wave of the space happening, and what we’ve done so far has kind of been the trial period, and we’ve done a lot and we’ve made an impact, so anyways, there’ll be a lot more of this, I think is what I’m trying to say. So thank you, it’s great.

Yeah, thanks. All right, you.