Disha Agarwal - Reo.Dev (00:00)
Hello everyone, welcome back. Today we're discussing one of the most important and often misunderstood functions in a DevTool company, which is developer relations. At its core, DevRel is about helping developers succeed with your product, earning their trust through education, community, and technical clarity. And now with AI, developer experience is really changing.
And it is really interesting to see how DevRel is evolving in this new reality. And to unpack that, I have with me today, Marcos Placona, who's a seasoned DevRel leader and the founder of DevRel Bridge, where he works with DevTool companies to design DevRel strategies that drive real outcomes. Marcos, So amazing to have you here today.
Marcos Placona (00:39)
Thank you.
Thank you very much. Very happy to be here.
Disha Agarwal - Reo.Dev (00:42)
Perfect. Marcos, could you start by telling us a bit about yourself and how you found your way into developer relations?
Marcos Placona (00:49)
yes, I am Marcos I am the founder of a company called DevRel Bridge. I am a software engineer and I've been in tech for, I guess the best part of 20 years now when I'm in DevRel for about 12, 13 years. Now the DevRel path for me was, I guess almost,
accidental because I was an engineer who kept some kind of like gravitating towards the community sides of things. So I always like to be involved in meetups and go to conferences and creating concerts as well. Like I've had a blog for as long as I can remember. And I realized that, you know, even though I liked software engineer, like I liked working as a software engineer, I realized that I
also liked the whole educational sides of it. And the reason I say kind of like came up by accident was I was actually speaking at an event. was, you know, this was 2013, I think. I'm based in the UK, so was at a conference called DroidCon London. I was an Android developer back then. And I was speaking and when I finished my talk,
someone came to me and said, hey, this is like, you know, it's really cool. Like you're really good on stage and like, you know, your talk really resonated with me. Have you ever thought about developer relations? And back then I was like, I have no idea what developer relations is. Okay. So I was like, no, because I don't know what it is.
Disha Agarwal - Reo.Dev (02:15)
Yeah.
Marcos Placona (02:22)
And then this person comes to me and goes well, know you get to do all the things that you that you're doing right now Except that you do it as a job and Mike what do you mean? do it as a job like, you know You get paid to do the thing that I'm doing for free and sometimes spending money on and and this person goes yes
So I started to kind of like look ⁓ into it. And then eventually that led me to Twilio where I led developer relations. Twilio was, and I think it's still is kind of like the gold standards of developer relations companies. Like a lot of companies kind of like try to emulate ⁓ the work that Twilio was doing.
And I also, for me, I also got to understand like, you know, what does like world-class developer relations looks like. So yeah, that's kind of like how I got into it.
Disha Agarwal - Reo.Dev (03:14)
What an interesting story, Marcos. ⁓ it's so interesting ⁓ that the serendipity happened and just one conversation made you land where you are today. So Marcos, what does DevRelBridge do today and why did you decide to start it? Were there any gaps that you saw in the market?
Marcos Placona (03:33)
Yeah, that's a good question. when I left Twilio, I had been at Twilio for seven years, And I had basically worked with every international team at Twilio because when I joined Twilio, Twilio was only kind of like focused on US markets and
Back then Twilio was like a 200 person company. So I left Twilio seven years later when Twilio was a 9,000 person company. And it just felt really big for me. It ⁓ didn't feel like a startup anymore because it wasn't. ⁓ And then I always kept on going back to like, I really enjoyed when I worked for startups. So I left Twilio, went to work for a company called Circle in the web through space.
Disha Agarwal - Reo.Dev (04:01)
you
Marcos Placona (04:19)
And that was like, you know, it was, was really interesting, very different, But also it was a space where there was a lot of DevRel things to figure out So for me, just felt like a challenge, but also
stayed at Circle for two years and realized, well, you know, this is also a little too big for me. I really liked working with startups. Now there was one thing that I kept on doing, which was I kept on doing small kind of like consulting gigs with early stage startups where they were trying to figure out DevRel.
Disha Agarwal - Reo.Dev (04:37)
Okay.
Marcos Placona (04:50)
And that's where DevRel Bridge was born. So DevRel Bridge is a developer relations consultancy. And we work mainly with developer tool startups, like typically series A and B, ⁓ that know that they need to engage with developers, but they haven't actually built that internal muscle.
Disha Agarwal - Reo.Dev (05:11)
So DevRel Bridge is your true calling and is born out of the passion that you have for DevRel.
So, building onto that, according to you, is DevRel and what role does DevRel play inside your DevTool company?
Marcos Placona (05:23)
So DevRel for me is the function that helps
developers succeed with your product while driving measurable business. And that for me is the big differentiator because I feel like a lot of DevRel programs, they focus on the function that helps developers succeed and then they forget about the driving measurable business outcomes. Now for me, that is the critical bit, okay? Because if you're not doing this bit,
then your DevRel team is going to be the next one who will end up being cut when that company decides to kind of like change priorities. DevRel is not necessarily marketing to developers and it's not just community management. It's not just conferences.
To me, DevRel kind of like sits in the intersection of products and marketing and sales as well. Like it's kind of in the middle, okay?
And then if I had to describe in a very kind of like simple way, I would say that it was about just reducing the time it takes for a developer to go from, I've never heard about your product, to I'm actually building something real and I'm going to tell all my friends about it that for me is the
Quick and simple way I like to describe it.
Disha Agarwal - Reo.Dev (06:40)
Such a refreshing trademark because ⁓ I agree that a lot of times we hear about the maintaining the relationships with the developers, but the measurable business outcomes part, I don't see that as a conversation with a lot of Devrel So it's just so refreshing to hear that.
Marcos Placona (06:57)
DevRel is right now, is very, it's very different than what it was back in 2013, 2014. And I say this because the DevRel that I did back in 2014 was much more about the vibes than, actually delivering those measurable results.
So back in the day, we were lucky that we didn't necessarily have to tie the work that we did with new customers coming in because, you know, you didn't have to do much to be different. Whereas like right now I feel like, you know, just people just don't get as easily impressed as they did before because we live in a different time.
Disha Agarwal - Reo.Dev (07:34)
Mm-hmm.
Got it. And that was supposed to be my next question. How have you seen DevRel evolve because of this new reality?
Marcos Placona (07:48)
Five years ago five ten years ago like things were things were slightly different now AI has changed how developers discover and learn. Okay again back in the day The way developers discovered were through maybe a stack overflow or maybe a conference now No one goes to stack overflow. I feel like people are going back to conferences now
there was kind of like the periods of like COVIDs and post COVIDs where like people weren't going to conferences. And I feel like people are going back now. But the reality is like, right now, a developer finds a product by asking Chatgpt So it's down to kind of like the LLMs to make that decision for the developer.
And in most cases, that developer will literally just copy that code from the LLM. And therefore that is their products of choice now I feel like there are companies as well as DevRel teams kind of like focusing more on creating content.
that is more readable by LLMs and everything. So I feel like a lot of the companies I saw a comment from Zeno from Resend where, this is kind of an old one, but he said that he was able to increase a lot of his conversion to Resend by adding an LLMs.txt file into the website because suddenly ⁓ his website was now being indexed by LLMs.
Disha Agarwal - Reo.Dev (08:54)
We're
Marcos Placona (09:11)
I don't think it's uncommon to say as a developer, when I find a new product, I want to be able to onboard on this new product in five minutes. don't tell me I need to fill a form, request an API key, wait for approval, and then talk to someone in sales. So the expectations are higher.
Disha Agarwal - Reo.Dev (09:21)
Yes.
Marcos Placona (09:33)
who treats a Devrel as a revenue function, who invested in content that converts, who measured activation, instead of just measuring awareness, they're doing really well, like, they're thriving. Now, the teams who are running the 2018-2019 playbook are probably struggling right now.
Disha Agarwal - Reo.Dev (09:54)
Understood. So what I'm understanding is that even in the community, there is this feeling that, know, now DevRel needs to perform in terms of business outcomes as well, ⁓ because that's where everything is headed.
I get your frustration because if you're a cost center, how do you determine what is the ROI that you are bringing and then how do you determine what is the investment that will go here and here? So I totally get where you're coming from. But Marcos question on this, we were also discussing the possibility of everything moving towards an agent to agent GTM, wherein as you said, that a lot of times now agents are coming and they're evaluating and it's also possible that the product is becoming
⁓ You know, it's sort of evolving in a way wherein it can give you all the information which you need to evaluate. As you said, developers don't want to talk to sales. They don't want to wait for permission for an API. That should happen automatically. So in a world wherein even the evaluation is led by an agent and the, you know, from the supply side and the demand side, both are led by agents. How do you see DevRel sort of evolving? And do you feel that how will they sort of make sure that their role is
important and what role would they play in this.
Marcos Placona (11:05)
I would say content needs to be way stronger than it was before
But also there's something here which is, agents will never be humans. Okay, so like they will never be able to kind of like just make sure that
developers are having a good experience with your products. They will never be able to kind of like create those one-on-one connections. And I feel like the place where DevRel thrives the most are on places that don't necessarily scale. And what I mean by this is
when you do a video or you create a blog post, basically get, you can get a thousand or a million eyeballs into that content. So like it's a very scalable thing. Whereas when you go and speak at a meetup, you will get a hundred people if you're lucky.
like if you're very lucky, if it's a big meetup, you get a hundred people. But the reality here is like, there is still components of like, know, these are the one-on-one and the more like intimate opportunities that you get to talk to a developer, to have a good understanding of like what it is that they care about, what it is that they're looking for.
But this is something that an AI agent just won't be able to do. the reality is there is this kind of intimate
moments where you go, you speak to a meet-up, you talk to developer, you understand the product or you understand the problem that an AI just isn't like it's just not going to be able to emulate. So I still, yeah. So I still think there's value in the human connection. the value here needs to be, very quantifiable.
Disha Agarwal - Reo.Dev (12:37)
Make sure.
Got it.
Make sense. Totally understand, Marcos And while you're on the topic of events and conferences, I think that you also mentioned has been one of the core things ⁓ in DevRel. And I was also speaking to Kyle Hughes from Draft.dev recently, and they did a marketing survey for DevGTM folks. And their findings were ⁓ that, you know, events and conferences are making a comeback. Could be because, you know, during the COVID, there was a lean period, and now people are sort of coming back to make those human connections. In your experience, is that happening?
and then how should a DevTool think about events and conferences in today's world?
Marcos Placona (13:19)
Yeah, so the one thing that I like to say is, events, haven't gone away, but the way we approach them has changed, I guess, completely. Okay, so the old model with events was just measure success by...
how many badges did I scan or how many people did I speak with? Now that for me is dead. for me, it's about the strategic selection. So you go to events where your target developers actually hang out, okay?
This could be, you know, like whatever event that you feel like makes sense in your developers hangout. And then you measure conversion. You don't measure attendance because I feel like the, the events organizer should be the one measuring attendance, not you as a, as a dev rel So you measure conversion. Like did people from the event actually sign up? Like, did you have something that would actually get people or prompts people to sign up? ⁓ And then if they signed up, did they make an API call?
Can you attribute any kind of like pipeline to it? So DevRel right now is much closer to things like a Salesforce or a HubSpot than DevRel was before. And I feel like, one of the biggest mistakes with the kind of like the old school DevRel, which people still do, is like, you know, trying to stay away from the CRMs.
Disha Agarwal - Reo.Dev (14:23)
Thank
Mm-hmm.
Marcos Placona (14:39)
And
if you stay away, it's like, how are you going to measure impact? So I basically tell my clients, like, you every event should have a clear conversion goal. Like if you want to go, you want to sponsor an event, it's going to cost you like $25,000 to sponsor. If you can't track from met at the booth to sign up and activated, then you have to rethink about like, you know, whether the event is worth.
Disha Agarwal - Reo.Dev (14:42)
Yeah.
Marcos Placona (15:06)
the investment.
Disha Agarwal - Reo.Dev (15:06)
Understood. And beyond conferences and meetups and community and we discussed content, ⁓ what are some of the more effective ways to reach and engage developers today? Are there new avenues or is this where developers would hang out?
Marcos Placona (15:19)
I would say, using documentation as a growth channel, and I say this a lot and it kind of sounds a bit boring, your docs are kind of like the highest leverage thing you have. If you're a developer too, it's the highest leverage thing you have because not only developers reading docs, LLMs also really like docs.
Claude or your chat GPT and you say, hey, I'm evaluating this and you look at where it goes, like it goes in the docs. Okay, so like when your documentation is excellent, if it has like, know, clear kind of like quick starts and runnable code samples and everything, that just makes a big difference and like it's a highly effective way.
of building community and making sure that you're building a product that people actually want to use. I also like to mention like, you know, technical contents that solves your problems. And these are like, real technical contents, not just using a blog for like product announcements, having real things that are like no fluff, actual tutorials that help developers accomplish something.
the last thing that I'll say,
is just treating your developer experience ⁓ as a product. Like making sure that you treat your onboarding flow, your SDKs, and your error messages as a product. Like run usability tests, measure completion rates. I feel like every company who's really winning right now.
they've been obsessing about this over time. Like they've been obsessing about, you know, making sure that their docs are really good. There's really clear error messages that their SDKs are spotless. it's much easier now to kind of like maintain an SDK, for example, because you have this SDK generators and everything.
Disha Agarwal - Reo.Dev (17:06)
So a lot of avenues, Marcos from what I understood, ⁓ you have your events, have your content, you have your documentation, community, a lot of things that you can do. So if there is a DevTool founder who's just starting DevRel for the first time, what is one starting point that you recommend? And also, when do you think a company should actually start investing in DevRel?
Marcos Placona (17:24)
this is an interesting one because obviously I run a DevRel consultancy. funnily enough, I have a lot of conversations with founders where I tell them like, you you're not ready for it. Like you don't need DevRel.
I think what I've seen in the past is founders hired DevRel when they weren't ready for it yet. So my kind of like advice to most founders, especially on the seed to Series A, is like don't hire anyone yet.
Try your own product as if you've never seen it before or get someone that you know to try your own product as if you've never seen this before. Go through sign-ups, ⁓ hit the docs, try to build something basic and time yourself. If you get stuck, then there's something for you to fix. ⁓ If it takes you more than five minutes, then there's something for you to fix. And then I tell founders,
three things and I tell them in this order. So the first one is, nail your messaging. Okay, so can you explain in one sentence what it is that your product does? And Disha I'm not kidding here, but like a lot of the founders I speak with, can't.
And, but also like the other question that I ask is like, why should a developer care? Like sometimes they nail the whole like, what is the product? But they don't necessarily know why a developer should care. So the, the second thing that I try to make sure founders understands is like, you know, go and fix your quick starts, make sure that developers can go from zero to I just built something real and it works in five minutes.
Disha Agarwal - Reo.Dev (18:42)
Mm-hmm.
listen.
Marcos Placona (19:03)
That Quick Start is kind of like the most important piece of content because it should have runnable codes, it should have expected outputs at each step, and it should also have like a clear next action, like what you want them to do
The third thing that I tell founders to do is like, now you just go and publish some content, like just publish some like really high content stories on your products that solve real problems. Okay. And then this whole process, like the realities, especially now with AI, this whole process, like it costs almost nothing. It gives you a good foundation before you start spending time hiring a dev role because
Disha Agarwal - Reo.Dev (19:37)
Mm-hmm.
Marcos Placona (19:41)
What really hurts me to see is when someone hires a dev rel too soon and they expect that person to tell them what to do.
Disha Agarwal - Reo.Dev (19:49)
Mm-hmm.
Marcos Placona (19:50)
So for me, it's much more about like making sure that they have a good solid foundation to hire the real person. And then ⁓ when that person comes in, they're basically set up for success.
Disha Agarwal - Reo.Dev (20:02)
Understood. I have a couple of follow up questions here. One is, ⁓ so do you feel that ⁓ DevRel, you should invest in DevRel after a certain stage and is DevRel a necessity for all companies or do you feel that there are companies who can do without DevRel also? That's my first question. And second is, when you said that you first ask founders to answer these three questions, explain their product, why developers should care and all. So are you suggesting that... ⁓
For all startups, it should be the founders first who are in the shoes of a dev rel and trying to ⁓ understand ⁓ how that should work and then get someone to sort of carry that forward.
Marcos Placona (20:40)
a lot of the most successful founders I've had the privilege to meet, they've been the first dev rel at their company. So they've been the first, And I think when you're in this space where you're building something,
You just need to be everything.
I have conversations with founders and they say, hey, I think we need DevRel. And I go, I don't actually think you need DevRel. I don't think you'll ever need DevRel. If your product doesn't have any focus on self-service, then DevRel is probably not for you. Because where DevRel thrives the most is at the top of the funnel and sometimes kind of like middle of the funnel.
Disha Agarwal - Reo.Dev (21:15)
Makes sense.
Marcos Placona (21:24)
But the reality is like DevRel is not to be confused with someone like a sales engineer, I don't think DevRel is for every company. think
Like there's some work that I do with some of my clients, Tisha, where we, basically work with founders on kind of like making this realization. Okay. Like, you know, not a hundred percent of my clients end up hiring dev rel after an engagement. So whenever I,
Whenever I work with the clients, around the three month time is when I kind of like take a step back and start thinking about is DevRel the right thing for this company? And if DevRel is the right thing for that company, I then ⁓ make a suggestion to try and get some headcount so we can hire a DevRel. So I help companies hire their DevRel. I help them with like their interview loops and everything, almost as if I were a like a head of DevRel at that company, okay?
So I helped them out with that. Now, there are some companies where on the three month mark, we say, well, actually, DevRel is not for you. We've accomplished many things Maybe you need a technical writer. Maybe you need someone to look after your docs. Or maybe you need someone to focus on your community.
There will always be signs. If developers use your products organically, if you're getting enough questions, if you're analyzing GitHub questions
if you're analyzing like LLM queries, for example, and people are kind of like, there's some sort of like intent from developers in those, then ⁓ these are kind of like positive signs that bringing a DevRel would be a force multiplier
Disha Agarwal - Reo.Dev (23:13)
Thanks.
Sure, so you already laid the groundwork and then that person is taking it forward. Makes sense. Marcus, you also mentioned that you help teams hire their first devrel. In your experience, what kind of a person makes a good first devrel hire for a small team?
Marcos Placona (23:27)
I would say your first ever hire, ⁓ they probably need to be a bit of a generalist who can both think strategically, ⁓ but they're also very happy to get their hands dirty. Like an early stage company, for example,
You can't really afford to just have a strategist. Like you can't really afford to go hire someone like at my level full time to be a first dev rel because like, you know, much more of a strategist than someone who actually goes in and just does all the executions. But also you can't hire someone who's like just a pure constant creator because you're falling into that trap of like.
You know, one of them is going to want to create the strategy, but the other one is going to execute, but they don't know what it is that they're executing. Okay, so you need someone who can kind of like do both. ⁓ The types of profiles that I look for is someone with real engineering backgrounds who can write well and also who enjoys teaching. Okay, like someone who enjoys the education side of things. ⁓ Like, you know, they should be able to build a demo app.
Disha Agarwal - Reo.Dev (24:12)
Makes sense. ⁓
Marcos Placona (24:35)
they should be able to write a tutorial about this demo app, and then they should be able to also talk about it on stage. And this is why finding that route is really hard, okay? Because you often find someone who's really good at coding, but hates being on stage, or someone who's really good being on stage, but doesn't really like ⁓ creating content. So it's kind of a rare combination. ⁓ So your first hire is usually gonna be hard. But specifically, I would say,
Disha Agarwal - Reo.Dev (24:45)
Yes.
Yeah.
Mm-hmm.
Marcos Placona (25:04)
Look for someone who has shipped code, not just written about it. And also, if your dev rel person can't answer a technical question on the spot, then they're probably not the right person to kind of like help you out. And also, I feel like this one is really important, which is they need to be comfortable with like ambiguity, especially at an early stage.
Disha Agarwal - Reo.Dev (25:18)
Yeah.
Yeah.
Marcos Placona (25:29)
A dev role doesn't really have a playbook yet. you know, if they come after me, they'll have a playbook. Like if they come work for a company that I've been working with, they'll have a playbook.
someone who's like proactive, someone who's resourceful and someone who's very comfortable operating without like a lot of structure. Like someone who can just go and execute.
Disha Agarwal - Reo.Dev (25:47)
makes
Yeah, no, think think enjoying to educate and teach, think that's such a important aspect. I'm not sure many people actually take that into consideration when they're hiring a dev rel. So so insightful.
Marcos Placona (26:03)
Yeah, I,
one of the things that I work with some of my clients is when they get to a point where they're ready to hire, uh, we, we really take a lot of time crafting together a, like a good job description because, you basically want to find someone who's like,
Disha Agarwal - Reo.Dev (26:21)
What?
Marcos Placona (26:24)
ticks every single box in that job description. And if it turns out that they don't tick one of those boxes, you need to, as a founder or like as someone who's hiring a dev rel person, you need to understand that, you know, if they don't tick one of those boxes, like what is it that you're kind of like compromising on? Okay. You know, there are certain things that I wouldn't compromise on. Like, you know, I wouldn't compromise on someone being technical.
There's a lot of confusion about this where people say, oh yeah, I can build things. I go lovable and I can prompt stuff. But the reality is when you get in front of another developer and you need to talk to them, you need to know how to speak their language because credibility goes a long way.
Disha Agarwal - Reo.Dev (26:59)
Yeah.
this.
Marcos Placona (27:11)
so yeah you need to kind of like spend a lot of time ⁓ finding this perfect candidate
Disha Agarwal - Reo.Dev (27:17)
Makes sense because it's such an important function and if you don't get the person right, it just sort of goes downhill from there. Marcos, coming back again to the very first thing that we discussed, tracking metrics and how that is very important. And you mentioned that eventually everything comes down to revenue. So I had a couple of questions here. One, apart from revenue, is there anything else that you advocate tracking? And secondly, for a company which starts dev rel motion, what is the realistic time
Marcos Placona (27:24)
Yeah.
Disha Agarwal - Reo.Dev (27:48)
to actually see some consistent results.
Marcos Placona (27:50)
I'll answer your second question first, You need to give it at least three months, because a lot of the work that your dev rel person is going to be doing, it relies on relationships and it also relies on what I call the long tail.
So you need to give it at least three months until you start seeing some results. Depending on what it is this person is doing, it might be quicker. But I always like to tell my clients, I don't really do engagements with anyone for less than three months because it feels like we're not necessarily going to get to a point.
where I can say, here's what we delivered. like, you know, some engagements may be like just about deliverables, like some engagements might be like, I want to build six blog posts, for example, in which case, yeah, we can do that. ⁓ But the reality is like, if you want to look at the results, then ⁓ at least three months. But it goes from like three months to a year, okay. But you can definitely see.
Disha Agarwal - Reo.Dev (28:31)
Thanks.
Marcos Placona (28:51)
tangible results within 90 days. Now for me there are kind of like three layers of metrics that I like to think about. ⁓ So one of them is the activation metrics.
one that I like to use is time to first API call. You can replace API with anything else, okay, depending on like what your product does. But basically time to kind of like the first time they executed your product. And then there's the activation rate, which is like what percentage of sign apps actually reach a meaningful milestone within your product.
then if you have tutorials, it's gonna be something like your tutorial completion rates. ⁓ But what I like about these is like they directly correlate with your future revenue. Okay, and this is why again, going back to the three months, like, you know, it's not gonna be a night and day type thing. You need to give it time, but like all of those things, actually correlate with your future revenue. Okay, like someone makes an API call.
Disha Agarwal - Reo.Dev (29:30)
Mm-hmm.
Yes.
Marcos Placona (29:50)
you're now, they're basically now on the clock to like, okay, when are these people gonna start kind of like using their credit cards here? Okay. And then if a developers makes their real first API call, they're significantly more likely to become a paying customer.
Then ⁓ the next one for me is content and channel metrics.
This could be something like documentation views, for example, the views to activation ratio, blog to sign up conversion. But see, everything that I'm mentioning here is like, I'm not just focusing on views, I'm not just focusing on blogs, I'm focusing on views to activation, blog to sign up, support tickets to activation. So if you're just looking at support tickets, then you're looking at the wrong metric.
Disha Agarwal - Reo.Dev (30:28)
Yes. Yeah.
Marcos Placona (30:34)
my blog has a million views so if it doesn't lead to anything then it's like it's it's not the wrong metric but it's probably incomplete
DevRel should be the one creating all of the conditions for sales success.
Disha Agarwal - Reo.Dev (30:48)
such a comprehensive view of how to look at things, Marcos. And of course, we are great proponents of the fact that you should look at data. And unless and until you look at data, you don't know where you're going.
where people are dropping off, you don't know what to improve, what should you do better. So totally aligned on that. So Marcos, before we sort of wrap this up, just one last question. If you had to give one piece of advice to a DevTool founder who's looking at DevRel, what would that be?
Marcos Placona (31:03)
Exactly.
I think I said this before, don't make the assumption that you need to hire DevRel, You may not need to hire DevRel, But I would say...
Be your product's dev rel first. Because if you do that, there's a few things
Like I've seen companies hiring DevRel where the founder has been kind of like acting as DevRel. And when they hire someone, they hire someone almost like as a force multiplier.
again, eventually that founder's gonna, you know, they're gonna have to step away. But now you have someone who's like really at a good place to be able to continue that work. And maybe the next thing you're gonna do as a founder is like, you're gonna find a second head count for DevRel when you continue kind of like, you know, just increasing this way. But I would say, start with like, you know, you go be the DevRel.
Disha Agarwal - Reo.Dev (31:59)
Yeah.
Understood. Makes sense. And thank you so much, Marcos. I think this was incredibly valuable. I think ⁓ I can feel the passion that you have for DevRel and your perspective and insights were just so amazing to hear. And I think everyone listening would have a lot of clarity on how to approach DevRel.
Marcos Placona (32:21)
Awesome. Yeah.
Awesome. Yeah, very happy to be here.
