Brian: PodRocket is sponsored by LogRocket, a front end monitoring and product analytics solution. Don't know what that is? Go to logrocket.com. Thanks. Hello, welcome to PodRocket. I'm Brian, that's Kate. Hi, Kate. Kate: Hi, Brian. Brian: Hi. With us on this episode is Kim Maida. Hello, Kim. Kim Maida: Hello. Thanks for having me. Brian: We are very excited to have you. I ask everyone to introduce themselves because they're better at it than I am. Who are you? Kim Maida: Sure. My name is Kim Maida. I am the vice president of developer relations at Ionic, and I am actually a former biologist. Now, I've been working in tech for over a decade, but still a scientist at heart. Brian: That's going to make... I did not prepare for biology related questions in the podcast, so... Kim Maida: That's all right. That's totally fine. Brian: I could wing it. We could talk about stuff I learned in seventh grade, bio classes. That's what I remember, actually. It's like, wow, no one cares about that, but they were how I remember where the radius and ulna bones are, and that ulna rhymes with pinky. Don't worry about it. You'll always remember that. Anyways. So VP of DevRel, it's not the, your first DevRel job. I'm interested to hear the, not necessarily the resume, but how did you start in DevRel and how did you get to where you are? It's not an interview, I'm just curious and just what's the arc [inaudible 00:01:43] Kim Maida: Sure. Yeah. I fell into it, which is interesting because I think a lot of people just fall into it, but I was a frontend engineer. I then became an engineering manager. I was working at agencies and a few different companies doing web development. And then I actually needed a bit of a break from management. So I joined Auth0 as a content engineer. Basically, my job was to write technical engineering tutorials for the blog. They have a very well-read blog. Kim Maida: In the process of doing that and teaching people about the technologies, teaching people how to code, teaching people about authentication, I got the opportunity to essentially speak at a conference, which I had never done before in my life, but I figured that it would be good life experience. So I went and did it. And I found out that I really, really enjoyed doing that. I liked to teach people things in writing. And I found I really liked to teach people things in person as well. Kim Maida: So I started doing more and more speaking. And then essentially, eventually I got back into management and I ended up managing the technical content team and the community team at Auth0, which was starting to get closer and closer to developer evangelism and advocacy. And then from there I started doing more and more speaking and ended up managing the developer relations team at Auth0. So my first official DevRel labeled role was actually head of developer relations. And then from there, I never really looked back, I guess you could say. I've been doing DevRel roles ever since then. Brian: I have so many questions because I think... Well, that's the first time I think anyone's had a very clear, almost linear answer, besides falling into it, which is a pattern I've heard a lot. And that happens with content sometimes too. But I want to start at the beginning. I think a lot of people can relate to, I don't know if you want to call it being a practicing front end engineer. And you said that you needed a break. I think people can certainly relate to that. And then you started running technical articles, which again, we have lots of people on the LogRocket blog that do just that, but then they also are saying, "I'm interested in being a technical writer, also getting into DevRel or dev advocacy or whatever the title of the year is. Dev experience engineer is my new favorite. Kim Maida: Yeah. There are many titles now. Brian: Yeah. What was it about the jump... How did you think about, and then actually execute the jump between writing and DevRel? How did that work out? Kim Maida: It was pretty serendipitous, actually. I had not had any specific aspirations to start speaking or preparing presentations or anything like that. I was used to having a role that was very public facing, just because we would interact with folks who read the articles, folks who would leave comments and things like that. But what ended up happening was there was somebody else working at the company who was speaking at an event at a conference, and I was also going to go to the conference and help present a workshop. And so that was the first step where I wanted to take the writing thing and go to in-person. And because the person I was running the workshop with was also speaking, it came up where the organizer actually asked, "Would you like to get on stage with him and also speak?" Kim Maida: I said yes, because I thought I probably should try it out. And essentially, he had mostly written most of the presentation already. So it was an easy way for me to get into that. And with this presentation, I was already prepared. I basically just had to learn the slides and we had to figure out the co-presenting thing, which, by the way, it is a lot harder to copresent than it is to present by yourself. There's all this awkward time where you're just standing there while the other person is speaking. And I would definitely err on the side of presenting alone for people who are trying to get into it actually, because it's harder to do it the other way. Kim Maida: We did that presentation together, and in the process of learning his slides and things like that, had figured out, "Well, if I was doing this, I would probably do it this other way," or something like that. And so basically after that, I just started to submit CFPs to conferences. And over time, I got better at crafting a good CFP that would be more likely to be accepted and just started speaking and traveling a lot more and discovered I really, really liked it. Brian: What I'm hearing, and please stop me if I'm wrong, is getting accepted to conferences and speaking at conferences is the first step to landing a full-time DevRel job? That seemed to be the main... Kim Maida: Not necessarily. Brian: Okay. Kim Maida: Yeah. I think that as DevRel grows and matures, it's actually more of a case of, there's so many components to developer relations that speaking has become... Sure, it's still a major component, but it's definitely only one small piece of the bigger puzzle. There are plenty of people who have gotten into DevRel through doing live streaming, or running workshops, or writing really good blog articles, or basically just going on podcasts as guests, things like that where you just put yourself out there, you start interacting with the community. Kim Maida: And then once you've established that you have a talent for communication, you have empathy, you can establish a rapport with people and you can be a good teacher and educator, and that you can connect with an audience. That's really what you need in order to land a DevRel job, especially because DevRel isn't... it's been around for a little longer now, but it's not so far into its life cycle that you actually have to have had three developer advocate titled jobs in the past. You basically just need to show that you have the aptitude for it. Kim Maida: That might change over time. The longer it's around, it might become the thing where they say, "You need 20 years experience in order to get hired as a [inaudible 00:08:43] developer." Hopefully, that won't be the case, but it is at a nice sweet spot right now where people can land jobs even if they never had a dev advocate job before. And they don't necessarily need to be a world-renowned speaker or anything in order to do that. They just have to be interested in it. Brian: That's why I like having folks in DevRel on this podcast, is because I feel like there are some patterns that have emerged or at least some commonalities, but no one ever says the exact same thing on either how they started and how they ended up and what the motivation was, and then ultimately, where they work now, how it's organized. It's always really different. But I'll get to that in a minute. I'm interested in hearing, well, two things, and one's backwards looking at the other, because you already mentioned it a little bit, but then also one is forward looking. Brian: Let's start with the backwards part. You mentioned what you feel like the essential traits are for someone in DevRel, some are empathetic and interested in teaching and that sort of thing. What's the core function, as you see it, in DevRel? There are job descriptions you can read, but what's the most important thing that you're doing that you think, and then what do you need to do that? Kim Maida: Yeah. I always think of developer relations as a discipline as being composed of basically four subgroups. And so you basically have your advocacy, which is often what people's job title says. So that's the clear one. But advocacy really represents the relationship that you're building with the developers that are using a technology product or software, and then advocating for them to the company, on their behalf in order to improve the offerings that the company has and to improve how the developer users feel about the product and what can make it better for them. Kim Maida: And then you have, related to that, developer experience, which is essentially, it's user experience when your users are developers. So it's, how is the product efficient? Is the experience good? Is the CLI really straightforward and the commands are good? Do people enjoy actually developing with the product? Kim Maida: And then you have evangelism, which a lot of DevRel jobs in the past I think have really been developer evangelist jobs, but they labeled them as something else, as advocacy or something. But evangelism is where you go and talk about the product and talk about the technology and how it can help people and how they'll benefit from using it. And then there's community, which basically encompasses everyone who is using the product or could even potentially use it. And it also includes the people who are building it. So your own coworkers and your own teams. And how do you grow that community? How do you nurture it? Kim Maida: And so when it comes to what things does someone need in order to work in DevRel specifically, you need to be able to communicate effectively, you need to be able to see things from other people's points of view, both from the points of view of the people who are using the technology and also from the point of view of the engineers and the product developers who are working on the product so that you can have both sides of the coin at the same time. Kim Maida: I would say emotional intelligence is a pretty big one also because you will often run into people who are having trouble with your product, or they're not really sure why they should be using it in the first place or they're frustrated with something and being able to connect with people and build trust and have a relationship that doesn't end up sounding like you're just selling them something, is very important for having a rapport with the folks who are in your community. Kim Maida: And I think that at its heart, building trust is probably one of the biggest things that I've learned about successful DevRel in general. You want to be genuine and you want to build trust. And without those two things, you're not going to have a successful relationship with the developers who are using your product. Kim Maida: And then there's also, you have to be, on some level, fairly adventurous, I think, in order to work in DevRel, just because it's on your plate to go out and try new things, find out, what can we do differently, or what can we change? What new ways can we use to connect with people? And then you have to be willing to take that and say, "Well, that didn't work, let's try something else." Or, "That did work. How can we then evolve and take it and run with it?" Brian: I think the trust component is interesting to me. Obviously, it feels intuitive. People aren't going to tell you what they think of other product really if they don't trust you, and then they're also not going to take your suggestions. I'm not sure how effective doing a formal talk about a product or how a product can help your company. I don't know if that's more or less effective than the conversations you have in between sessions with people about like, "Oh, this is the things that you could do," or "Here's how I would solve that problem." But I think the most interesting part is that that trust is not really attached to the company or the brand, it's attached to you, the person. Kim Maida: Yes. Brian: I think this is true for almost every dev advocate I talk to or DevRel person. It gets so hard because there's no standard title, and so I never know what to say. Anyways, you're building your own brand and doing your own thing, but then you leave to another place and they have to start again, and you don't. And that seems really appealing. I like that part. Kim Maida: Kind of. People do build up their trust and their reputation in a specific thing. So then when you do go and change companies, you have to make sure your expertise is at a level in your knowledge and that trust is built up around the technology that you're representing now. So there is a little bit of, not starting over, of course, but definitely you fall back a bit so that... because maybe somebody trusted you on a specific topic, but they don't necessarily know that you're now becoming an expert in something else. Brian: Could be a different audience too, I guess, also. Right? That makes sense. Kim Maida: Yeah, yeah. Brian: Okay. And the other thing that you said that I was going to lead to, and your answer is a good transition, is you mentioned interacting with the community. And one really obvious pattern that's emerged in these DevRel-themed episodes is that communities... Well, I guess it has been a big deal for, I don't know, five years? Six years? More than that. But almost everyone's is really interested in building a community. Not everyone has a very clear vision of what that means or what that is. I'm interested to hear what you think. What is your- Kim Maida: Yeah, it is tough because it's not just about, who's in the community? It's also about, where is that community? For example, are you trying to build an online community with a forum? Are you trying to build a champions program? Are you trying to get more GitHub contributors involved? Are you trying to build a community that will give you direct product feedback and things like that? Kim Maida: Basically, you have to take all of those things and coalesce them into tangible human beings who you can communicate with. You can have this huge, nebulous community that exists, but then if you don't actually interact with them at all, then I think that's where a lot of companies are, "How do we take this community that exists and become something where we have an actual relationship with them? And they're not just people who like our products and use them, but they become a part of the company's ecosystem in a way that the company is also giving extra things to the people who are making video courses and writing blog posts and championing the technology." Kim Maida: And that's definitely an evolving story still. A lot of people have heard of Google Developer Experts and have heard of Microsoft MVPs. There's a lot of these experts in ambassador programs out there. And I spent a lot of time either participating in as a member or building out and running these types of programs. And it's very interesting how much they can differ from each other. And there's definite vibes that you get from certain ones. Some of them are very... The company pushes out information and then asks the members to do something, like go speak or something, and then report how much you talked and things like that. Kim Maida: And then there's other ones who you're trying to engage more with the things that they're actually working on. Like if somebody creates some content, then will the company then do some social promotion of their content, or highlight them in a newsletter, or help them out, essentially, rather than saying, "How many people did you speak to about our product this year?" Or something like that. Kim Maida: I've always felt like the key to having a really successful program of that nature is to not just expect people to do all the work and the company needs to do some work as well in order to reward and recognize all of the time and effort that folks are putting in and make sure that you're elevating those voices so that the company obviously benefits. And then the people who are contributing benefit in a more tangible way than just they get to say that they get to put a label on their profile or something. They actually can say, "The company helped me land another contract. The company promoted my videos. So it got 10,000 more views." And then it would have... Something like that. Brian: ... No, you have to give people something for them [crosstalk 00:20:03] It sounds stupid, yes, but you have to give people some incentive. Kim Maida: Otherwise, it's free work. You can't expect people to basically be advocates for your company and not receive anything back. Brian: Couldn't agree more. And I think that's like... I wonder sometimes, it seems to me like the most successful, or... I don't know if success is really the right word there. Certainly the DevRel programs with the most visibility are at larger companies. It's more difficult for smaller companies to have a big DevRel team because they're expensive, frankly. And there's also not that many of them. I think maybe a year ago, because we're recruiting for that position, and maybe a year ago I did a LinkedIn search and in the U.S., there were maybe 500 people with that title and 300 of them worked at Google. Now, I don't think that's really much of a hyperbole. It's like, "Oh, wow. Okay. Well, that's a problem." Kim Maida: I think that's changing, though. Brian: I hope so, because I would really like to a team. I guess where I'm going with this is, do you think it's possible for a smaller company to have an effective DevRel program? And if so, what is the most important thing they should focus on? Is it an online community or is it help? Kim Maida: Yeah. I have worked at several smaller companies and done DevRel, and I've also worked at larger companies. I mean, not huge. I've never worked for a company the size of Microsoft, for example, but it is totally possible. And I do think that the commonality that I've seen through all of the companies that had a very small DevRel team has actually been that more people do DevRel at the company than the people who hold a position on the team that's called developer relations. Kim Maida: So this really works well when you have a smaller company where the folks who work at the company are interested in advocating for the company in a broader way than, "I'm a developer advocate, so it's literary my job." So we have a lot of folks at Ionic. For example, the Ionic DevRel team currently is just myself and Mike Hartington. Mike has made amazing name for himself and reputation. A lot of people when they think of Ionic at a conference or something, his name and face pop-up. But he is not the only person at Ionic who does DevRel. There are a lot of folks on other teams across the company who will speak at events, will come on podcasts, will write blog articles, will do all of these things. And I think it's important that the company have the room to support that. Kim Maida: And those activities, a lot of people do it because they love it, not because its their 9:00 to 5:00. So if a company is very like, "No, we're not going to support you going and speaking at this event," or, "No, you don't have time to write this blog post. You have to be heads down on your other projects," then you're going to run into more issues, because essentially, for one thing, it sends a bad message about company culture; that they don't want other employees to advocate for the company. Then what kind of company is that? Kim Maida: But I think in general, and you run into a lot of people who have been doing this type of thing, while their job title is software engineer or something like that. And then eventually, they may transition into a developer advocacy role because they really enjoy doing that. And so there's a lot of folks in that boat. Supporting those people is very, very important to having a successful relationship with your developers. Kim Maida: And it also sends a really good message in general about advocacy for the company and evangelism for the company when you have engineers or founders or co-founders who are doing developer relations activities. Because then it says, "Well, more people are willing to talk about the great things that this company is doing, or they're willing to engage with the community than just the people whose literal job is to do that." So it's always a good vibe to see that happening. Brian: Yeah. Is that the counter argument to, let's say you're a company with less than, I don't know, 50 engineers, and the response is, "Well, our engineers are here to write code, then that's where their time should be most spent or best spent." I'm not sure if that's always true, but I do hear that a lot. Kim Maida: Yeah, yeah. Which is understandable, but it's one of those things that I think is a sentiment that's changing as DevRel in general grows and becomes more ubiquitous. You do have a lot more companies who are realizing if you look at the competitive landscape and you are a company of X size, 60 people, and you look at another company that is of similar size and they put a lot more effort into developer relations and/or they have more people who are doing employee advocacy. And then you look and see, how big is their community? How much adoption do they have? How much are people talking about their technology? How easy is it to go online and just Google something that you want to know about the product and find a great video tutorial or something that... or a talk that was recorded? Kim Maida: You can see the difference where a company's put zero effort into the DevRel or restrict activities only to one or two people who actually have the job compared to companies where you have a bunch of great technical talks from the engineers as well, and things like that. So I think people are starting to recognize that DevRel's an essential function of companies that grow through having a developer community of users. So it definitely was not always that way, but it is something unseen, start to change. Brian: This is a non-sequitur, but essential function has always been one of my favorite phrases. I've worked in government for a small period of time. I heard that and I was like, "That's really cool. I really like that." So I'm happy to encounter it in the world. Okay. My last question, at least about that aspect, is, when I am talking to someone about potentially working in a DevRel role here, I almost always hear the question... Two things: Do I have to travel, or do I get... And each person has their own opinion on whether or not that's good or bad. But then also they're asking, will I be writing code regularly? Brian: And I have taken the stance that, yes, I'm not sure how you would stay current if you don't, but I also don't know if I'm right. Do you think I'm right? Is that something that you have to do? Because I also don't know how it would work because it would be difficult, I believe, to write in production if you are jumping in and out of teams. So that leaves growth engineering and other stuff on the periphery of, I guess, the product stuff. Kim Maida: Yeah. It depends. It definitely depends. It depends on the company, it depends on the company structure, and it also depends on how much the individual is able to advocate for the type of thing that they specifically are most interested in. In general, at a highly technical company, the developer advocates would write code. Often, it could be demo and sample style code, but some companies do actual rotations where folks who work on DevRel actually do product engineering. Kim Maida: I think Netlify is a good example of this. They have a developer experience team and the folks on the team basically rotate into product development. I think the sentiment around that is, how are you going to be well-informed on the technical aspects of a product if you aren't building either the product itself or building actively with the product? In my specific experience, being a developer advocate, speaking at technical conferences involved, or writing a lot of code, it starts to fade away a little bit as you get into leadership and management of DevRel team, because your focus becomes more strategic depending on how much room you have to do individual contributor style work. Kim Maida: But in general, I think it's not that difficult to find opportunities to write code, particularly if you're doing highly technical talks with demos and things like that. You're going to have to write code in order to create that. But there's also a lot more than just speaking at a conference. If you give a workshop, then you will probably build an application in your workshop. And so you will be building that whole thing out and then you'll be teaching everybody else how to do it. Kim Maida: And then similarly for if you're writing technical blog tutorials as part of DevRel, or if you're live streaming, you can live stream how to build with... We just released Capacitor 3.0, for example, at Ionic, and did a live stream on how to build something with Capacitor 3.0. So there's definitely a lot of opportunities to still be active with coding. Kim Maida: I've also heard of places and people who are developer advocates but they don't write any code, or don't even have a background as a developer, which, in my personal experience, has not been the case at the companies that I've worked at. So there is some level of interest from me in finding out how companies with that type of structure get really comfortable with doing that. But overwhelmingly, I think, the dev advocates still write code. Brian: I think that's why... Someone came out a while ago in an interview and just straight up told me, "The reason that we..." I guess that person felt empowered to speak for the entire DevRel community. "The reason we like developer experience engineer is it lets the world know that we're actual engineers and we want that cred." And I was like, "Okay, that makes sense, I guess. But then what does that do for those people that you just mentioned who maybe don't have experience or an interest in writing code? Will they be successful?" I don't know. Kim Maida: Yeah. I think they definitely can still be successful, but maybe not doing the exact same things that somebody who is an experienced engineer would do. There's a lot of DevRel roles in community growth, there's a lot of DevRel roles around program management and things like that, which are very fun, very compelling, but don't actually involve writing code. So if you want to talk about standing up on a stage and giving a technical demo, well, that's different. But there's a lot of other things that are involved with DevRel besides specifically writing code examples. Brian: Yeah. That particular persona of DevRel person, the engineer part, would strongly prefer to report into engineering or product and gets immediately bummed out if you mention that it's possible to report into marketing. That's the worst thing that could ever happen. And so, maybe there's some other... Kim Maida: That has always interested me because there was definitely a point in my career where I was... I've always reported to marketing. In every DevRel role that I've had, and they've all been highly technical, so I felt like... Initially at one point in my career, probably early on, I was like, "Oh, I'd really, really rather report to engineering. I'd really, really rather report to product." But then in practice, it didn't really make a significant difference that I was reporting to marketing because I was still working with engineering and product. So it was about, how is the structure of the community? Are you interacting heavily with engineering and product? Do you have touch points with them, or are you just only trying to talk about marketing? Kim Maida: I also don't want to belittle marketing, because marketing is actually a great area for DevRel to report to. And I think that a lot of people are people who are classically trained engineers, which I am, so it's not that I'm like, "Oh, well, they don't understand." I was the person who wanted to report to a different segment at one time. But marketing to developers is an art in and of itself. And I think that understanding that nuance is actually a pretty significant part of understanding successful developer relations. Kate: Yeah. You're telling us, Kim. Brian: Well, Kate and I are just frantically nodding our heads like, "Yeah, that's true." [crosstalk 00:34:28] It's funny. Even in content, content is for sure marketing. It's inbound marketing and even most content... No. 50%, let's say. We get a little squeamish when someone calls us a marketer. I'm like, "No, I'm not the one that's serving you ads." Occasionally it's funny. Occasionally, let's say that a LogRocket article makes it somewhere, makes it to Hacker News and it gets on the front page and every now and then I'll get someone who... or many people that will tell me that this is blatant inbound marketing. Yes, that is exactly what it is. Kim Maida: Yes, that's our job. Brian: That is correct. [crosstalk 00:35:14] I think we're doing it well in front of you, but yes, that's... It is. I don't know. I think we probably are aligned here, that I strongly prefer creating content, and I guess marketing to the technically minded. It's so much easier to understand, "This is what they want, which is things that are useful." Kim Maida: Yeah, exactly. Exactly. Brian: And this is the utility. If you make a mistake, they'll tell you, and that's great because otherwise you could just... It's just very simple to me. And occasionally, you get someone who yells at you, and that's fine. It's like, "It's the internet. I don't get that worked up." Kim Maida: Yeah. Working in marketing... All my entire DevRel career, I've always worked in marketing. It's highly enjoyable to do marketing at a technical company because your audience is developers and coming from a background as a developer, they want what I want. So it's not like I had to learn an entirely different new skillset in order to work in the marketing department instead of in the engineering department. Kim Maida: It was actually very natural because I know that from being a developer, that developers want their work to go smoothly, they want to be efficient, and they want it to be interesting while they're doing it. And they then want something at the end that they enjoyed making and then are proud of. They had a good time doing it. So when it comes to understanding who you're trying to reach, being an engineer, working in marketing to engineers is very natural because you are the audience. So you know what they want. Kim Maida: And I think a lot of people have commonly said, "Oh, you don't want to report to marketing because devs don't like to be marketed to." And that's not necessarily true. It's actually not a truth. I know that I'm always looking for things that will make my life easier and better and be fun to use and things like that. And that comes often out of developer marketing. Kim Maida: And so it may be true that devs are a little more sensitive to BS, hence comes the, if you are just genuine and you're working on building trust, this is just the thing that's of tantamount importance at an ethical level. Companies that don't build trust and aren't genuine, probably you don't want anything to do with them anyway. So it's like a natural flow for developer marketing to have those things be core tenets of what you're trying to get to. Kim Maida: And then you say... Marketing to developer is about, is it genuinely useful? Is it helpful? Does it improve life for developers? Does it make their team flow more cohesively? Does it have a great developer user experience? And if yes, then they're going to be open to trying it. They're going to be open to building a relationship with the technology or the brand, and they're going to be happy to become practitioners. And I think that that's the crux of developer marketing in general. Kim Maida: And those things often come pretty naturally to people who have a developer background. So I think it's a little bit of... It can be a misstep for folks wanting to go into DevRel to say, "Oh, no, I don't want to work in marketing." It's like, "Well, no marketing, in many cases, is a really great place to do DevRel." Not to say that working in product or engineering as DevRel wouldn't also be great. It would. But I think the reluctance to be in the marketing org is maybe a little bit misplaced. Brian: I couldn't have said it any better. Cosigned. The one thing I will say is, it's just such a... it's a straight line, two-way street. Give the people what they want, and what they want is useful stuff, no garbage marketing tricks. For us, one of the things which is, to me, always [inaudible 00:39:37], especially in the beginning, was we would get compliments on the call to action, a little blurb at the bottom of our posts that's like, "Hey, we have a product that we're trying to sell and it keeps the lights on. It's the reason we do this." Brian: But that's it. There are no fly overs or pop ins. And it's very obvious where that advertisement is. So you can just choose not to read it if you get to the end. And we get so many compliments on that from developers. Like, "I appreciate you... And I understand that you have to market. I also appreciate that it's not in my face." The other thing- Kim Maida: Yeah. But then people also appreciate that they know where to go... If they are then interested in the product, they know where to go. It's not obscured like, "This isn't marketing, we swear." So then they have to figure out how to engage with you. Brian: Well, what's funny is that I think sometimes, some people, and this is maybe a tangent, but some people think that developers as a group are mythical creatures who are impervious to all marketing and are not interested. And it's completely not true. Kim Maida: They are definitely interested. Brian: I think the difference is, kind of what you said, is the BS part. You can publish a borderline clickbait title, but it has to deliver. It can't actually be garbage. Which is like, why would you publish garbage in the first place? When I think about it, I much prefer creating content for developers versus, say, marketing to marketers. I feel like marketers are way more frustrating to market to. It's unclear what they want, they think they could do a better job than you. Maybe I don't respect the products that they're hawking, so that's just a me thing, but that's it. I don't expect you to have a response to that. That's just me being spicy on my own podcast. Brian: Okay. The last thing I want to ask about, because you have experience in both of these arenas, and it seems like a question a lot of people have, or a lot of people have a hard time figuring out, what are the key differences between DevRel at an open source company or an open source product and a commercial product? What are the key differences and how does that work? Kim Maida: This is a really interesting question because there's almost no company that doesn't have some commercial side if they are open source, because otherwise, they honestly often don't succeed. I think that Ionic is actually a really good example of this done right, where you have open source products. Ionic Framework is open source, Capacitor JS is open source, Stencil is open source. And these things will be open source, free forever. We'll never surprise people and be like, "Oh, no, we're closed sourcing this. Now it's going to become commercial open source," and all of this stuff. Kim Maida: But what we do do is we have additional features and offerings that are available for larger companies with a lot of money for enterprises that they can add on if they're using the open source and they need a little bit more, they need to manage a bunch of CICD2 or something, they want automatic updates to app stores and things like that. Kim Maida: And I think that the nuance of doing this correctly is very important because if you have a piece of open-source software and you have a huge community of users who are using that, and then all of a sudden you say, "And we built this other thing for... this thing that everybody's been waiting for. Oh, but it's not actually free. Now you have to pay." Then, from the company side, that might be what the company feels like they need to do in order to fund the open source, because they want to grow the team, they need more people to maintain it, they want to keep it living into the future. But it can make the community very angry. So then people get extremely upset. Kim Maida: So I think the successful model is really to have your free and open source and then have things that are non-essential in a way that folks who are trying it out or folks who are working for themselves or smaller startups probably don't need it. They can just manage with open source. But large enterprises, these companies that do have a lot of money, they want to pay for something so that they can ensure that the open source is not going to go away someday, then they're more than happy to get a little bit more professional services or get some fancy add-ons or really robust plugins and things like that. And that model tends to work very well. Kim Maida: In DevRel, it's an interesting nuanced balance because you want to build community among developers at the very top of the funnel where you want adoption. You want people to learn about the technology and be able to try it out. You want it to be accessible to those people. So you want to start them with the open source and they might only ever need the open source. They might never touch the enterprise products at all. Kim Maida: But then also, you want to make sure that folks who do try it out and then love it, and then work at enterprise companies are aware that you have more things that could really continue to make their lives easier. So it's an interesting balance. A lot of companies are at a point where they've created something source and then they're thinking, "Oh, gosh, now we really need to make money, or we won't be able to pay for the team to continue developing the open source." Kim Maida: And I think one of the keys if you're looking for a position in DevRel where you get to do both, you want to look for a company that's had a plan from the start, which is, they exist. So it's not that people haven't figured this out. But it can be very tough to be a representative of a company if they're in the midst of trying to figure it out and it's already been quite a while. Kim Maida: You definitely want to, as a representative DevRel, be aware of the whole picture. You can't come into DevRel and expect, "Oh, DevRel means open source and then sales is the commercial side. I'll never even have to think about that." You do have to think about it because you may be at the very top of the funnel, but things go through the funnel and there may very well be plenty of opportunities where people come to you at a conference and they say, "What do you have for this next step, because our company is really at a point where we need something more, and now what do we do?" Kim Maida: So you want to be cognizant of the whole picture, be able to talk intelligently about the whole picture, but you're not necessarily the person going out there and saying, "Everybody should pay for our commercial products even if you're a single developer building your first application." You have to know when people need it. When it's applicable and when it's not. Brian: Yeah. That little conversation or big... Whatever. That side conversation is absolutely more powerful than anything. If they engage with a salesperson later on, your conversation is, no offense to my sales friends, and I think they'll agree with it, whatever they say, it doesn't matter as much. So I don't think I made a lot of sale... Fortunately, I don't think the salespeople of LogRocket listen to my podcast, so nailed it. Cool. Okay. That was a great answer. I have always wondered that myself, so thank you. Brian: It's plug time. You have to plug anything. You can plug other people, projects, stuff you're working on. This is your time. Kim Maida: I have been trying to write more blog articles on dev.to. So I'm just dev.to/kimmaida with no spaces. I've been trying to find time to write more blog articles about developer relations. I have a couple in there right now, but I have ideas to write more. So if folks are interested in connecting with me too, I'm on Twitter. Also, it's just Twitter/KimMaida. I try to be consistent and just use my name so that I can always be found. Brian: Awesome. We'll put all those links down in the description and stuff so that if you missed it, you can just click them. Okay. Kim, thank you so much. This was a really great for me. I hope you had a nice time. Kim Maida: Yeah, I had a great time. Thank you so much for having me on. Brian: You are very welcome. It's our pleasure. Hi. Thanks for listening. Please remember to like, subscribe, email me if you want, even though none of you do, go to logrocket.com and try it out. It's free to try then it costs money. We'll see you next time. Thanks.