Aligning DevRel with your business stakeholders

Robin: Hi guys, how are you?

PJ: Good, how are you doing all good.

Robin: Good. Well, look, I couldn't have wish for a better set of panellists for this topic. Matt and I just kind of teed it up. But again, so I'm Robin from Peritus, but we have a great crew here of different perspectives to bring to the table. So I thought we'd do is do a quick introduction and then I'll tee up the topic and we'll take it from there. So let me suggest we go, I'll go around the wheel a little bit, so we'll go in my wheel. What does your wheel look like? I'll close it off and tee up the top.

Vandy, why don't you go ahead. Yeah, perfect.

Nnamdi: Everyone, very nice to be here. My name's Nnamdi Irregbulem. I'm a partner at Lightspeed Venture Partners where I focus on investing in technical tools for technical people, which ends up meaning developer tools, application infrastructure and data science, machine learning. I've personally been a self-taught programmer ever since I was a kid, so I really love this stuff and a big part of my effort in working with founders is figuring out DevRel and encouraging them to think about this topic as early and possible as possible in their journeys as founders. So excited to be here.

Robin: Cool. Okay, Carolyn,

Caroline: Good morning. From Vancouver, Caroline Lewko. I've got a company called Revere Communications and we're an agency for developer relations, but I've been doing DevRel since I founded my first developer community back in 2001 for wireless and since then have supported a lot of supported startups, supported big companies, have come in as a fractional DevRel leader in organisations. And how many 20 some odd years later. I'm still thinking DevRel is just super exciting and of course I have to plug our book. We wrote a book on developer relations and all of the things that we had learned over the last 20 some odd years. I thought, what am I going to do with this? I just want to open source it and make all these frameworks available to everyone so we can elevate like everybody's been saying.

Let's elevate what's happening in de.

Robin: Yeah, I'll give you a call. Thanks for having me. Awesome. Read it. Help me get calibrated on what's going on in this sector really quickly. pj.

PJ: Hey, so greetings from Buffalo, New York. My name's PJ Haggerty. I'm the founder of dev relate. io, which is a developer in community relations as a service company. We started focused on small organisations who couldn't do Devra or couldn't meet the needs of their community by themselves. So we started off in that vein in sense. Then we've grown and we work with companies that are small and looking to reach out to communities, to companies that are huge and just don't know how. So that's what we focus on.

I've been doing Dev for about 13 years. Before that I was a developer focusing in open source technologies. I'm a big fan of that and I like to say that I've applied that to the way that we actually do our community work. Beyond that, I'm one of the hosts of the Community Pulse podcast, so I'm pretty excited to be here and be part of the conversation.

Robin: Yeah, awesome, awesome. So just I'll give you the 15 seconds on me just so I grew up in build and scale many businesses across enterprise software sector, so I'm kind of new to the DevRel sector. That's why I really appreciate great books by Carolyn and all the podcast interviews that we've done over the last seven or eight months. So we're super excited about the trend. We think there's a particularly valuable role that we hope to play as this market can evolve, but I kind of bring an operator's perspective to it, having run a lot and scale a lot of software businesses. No doubt this is the way of the future, but I think that is really important that the community efforts can be linked to really material conversations that happen at the c-suite. This is where the world is going. So I think everybody's in the deral industry has a tremendous career ahead.

If they can figure out how to do that, communicate their value, align with the other stakeholders, show them how they can help the community but also benefit from it at the same time. So that's why I wanted to add this kind of free flowing conversation for you guys.

Caroline: Every waking hour.

Robin: Carol, I know you advise a lot of people at that senior executive level, so how do you get them to think about the business impact of community?

Caroline: I guess it depends on the size. So we certainly work with larger companies and often it's those executives that are trying to convince their leadership on Devra and what we always want them to take a look at and consider is what are the priorities of your own company? What's the ROI that everybody else is looking for and let's figure out how we tie developer relations into that. And if you don't have that tie in, if you can't prove why a dollar spent on your developer programme is the best way to spend money as opposed to a dollar spent on somebody else's programme within your company, they're going to move the money over somewhere else. So you really need to be able to have those. I think those are super, super important.

PJ: Just to jump in, I can't help but agree, Caroline. I think that what a lot of people miss, especially when they're initially looking at DevRel, is determining what the metric of success looks like. They often tie it into something that makes sense in other worlds. A CFO will look and say, okay, well how much literal ROI do we get if we spend on an event or we specifically run a specific programme? How many people are top of funnel? How many people are mid funnel? And DevRel doesn't always work quite that way. I know that there's been so many jokes about like, oh, we measure our progress in hugs and high fives.

I mean, yeah, that's true. We are a relational based system, but at the same time we have to figure out how those relations term work in the metrics of success that our organisations want to be a part of. But step one is what do we consider success? How do we figure that out? And once I think someone at the c-suite level can determine that, then they can determine exactly what they want to do to leverage their dev.

Robin: P of A is asked to follow up on how do you encourage people to look beyond a vanity metric because there's so much data you can measure and declare victory marketeers, I've been one a lot of my career, so it's easy to address up market metrics and celebrate. That's all good, but there's a difference between what is a vanity metric and what is truly business impact. Yeah,

PJ: Right. I mean for me, I've always asked my clients and the people that I work with, well, what does this metric mean to you? If you come to me and say, Hey, we want you to write eight blog posts, we want each of those blog posts to have 2000 reads. Okay, well what does 2000 reads mean?

What do you think that's going to get you? What does this leading to as far as your value of success? I could easily go out and find 2000 people to read a blog or article. That doesn't mean they're interested in the things you had to say. Even if they finished the article, then we can get into how metrics are measured and all that. But if you're not willing to ask yourself why, that's a metric that I'm willing to step in and say, Hey, why is that your metric? Determine why this is your level of success. Because a lot of times it is based on older ideas of marketing or sales that lead people to say, this is what I think is success.

And with DevRel, that's not the case.

Caroline: Well, I'm going to disagree with you a little bit on that one.

PJ: Okay,

Caroline: So I think there's two ways to think about it. I mean, developer relations, depending on the company, if it's a developer first company for instance, your whole company is about developer relations. So any marketing that you do and anything that you're measuring has to be driving towards the bottom line because that's what you do. And so do you want to make sure that who's ever reading the blog, is that going to make them, I guess the things to measure? Is it going to help them build something faster or is it convince them to sign up and use your API or tool or whatever it's going to be? So I mean those are definitely measurements that you can use and put into that. If you are more of a developer plus company and your tool or your product, your developer product is something that's enhancing something that something that's already existing, then the measurement might be a little bit different. But I think you always have to look at that high level measurement and so is it actually going to create more awareness for your existing product?

Great, you can measure that or is it actually going to decrease support costs? You should be able to measure that as well. Those are still very much ROI driven metrics that are important to think about. So it's not just about those blog posts. Where do those lead up? Where do those roll up and where do they roll across the developer journey?

PJ: Absolutely. I should have been clearer about that. You're absolutely right.

Robin: Well them to get in and then, but Carolyn, I think we'll circle back later on. You teed up this kind developer journey framework for thinking about how you can create value at different steps of that developer journey. So we'll come back to that and think about that. But Nandi, why don't you jump in?

Nnamdi: Yeah. Vanny metrics are such a funny topic for me. I have a very simple heuristic for whether something is a vanity metric or not, and the question is, does this metric make us feel good about ourselves or does it actually drive value for end users? If it just makes you feel good about yourself and can for end users, it's very likely a vanity metric. And the perfect example that I love to bring up is I work with a lot of early stage companies that are either pre-launch or soon after launch, and oftentimes it's become very in vogue to build these wait lists of users and people who have signed up and you feel really good about it and you put it in your pitch deck. Look on these people who signed up for our wait list. I think that's a total van handy metric. This does not prove that you've driven value for anyone other than yourself.

Robin: You don't invest in companies with long wait lists.

Nnamdi: It's not a negative signal, it's just not necessarily a positive one. And so I always kind of bring it back to what's actually driving value for end users and then presumably that will eventually drive value for you as a business, assuming you can extract value from there. But yeah, that's kind of a nice heuristic that I tend to use.

Robin: Yeah. Well there's a question that came in on the channel here. I'm just going to read it out so we get some audience participation going. It's from Parmar, I hope I said his name correctly. It says, do you have some concrete examples of successful KPIs being used in firms you've worked in or with

Caroline: One of the companies we were recently working with too? I think one of the challenges with DevRel and DevRel products has often been how do you measure what's happening within a product? And they were using something called Mix Panel to be able to go, yes, we can see when somebody's actually starting with the product and what they've built and when they finished with it. And so there you want to find the time to hello world, right? How long does it actually take them from the time they've started your API? Until they can look at their dashboard and go, yes, this is finished, or they've made that call. So those are some important metrics to look at. Active monthly users depending on the product can be good or it could be a vanity metric too.

You need to be able to think about somebody might just need your product once and that's okay, but as long as they can use it as quickly as they can and be able to get the support that they need, then that becomes really important. I'll let you guys fill in some other blanks.

PJ: Yeah, I think one of the biggest things to understand too is the difference between KPIs and OKRs. Our philosophy has always been like OKRs is the goal. That's your metric. PI is the tactic you use to get there.

So I think I was working with a company that open source, they were focused on contributors. So our metric was can we get 10,000 contributors over the course of the next month? And our KPIs were like, can we start an LMS that actually makes it easier for contributors to onboard? Can we write some case studies of what it's like to be a first time contributor? Can we mark 200 tickets that specifically say low hanging fruit, so it's for a beginner that will increase our contributor account. So I mean your KPIs are really the tactics you're using and with us the tactics are what made it easy, what was the bridge we're building for contributors? What gates are we knocking down for contributors? And the OKR was the actual metric which we did hit, we exceeded, we actually doubled it, but the whole point is the OK R, that's the metric you're trying to hit.

KPIs are just the things you're trying to do. They're more like checklist items.

Robin: KPIs will change over time. So what you mentioned leads up to the goal will have to change because you're instrumenting different things

PJ: And KPIs need to be fluid because I mean in that example, great, so we got 20,000 new contributors. Wonderful. Now those are new contributors, what are we doing next quarter? However you're measuring these things to actually grow that and say, we've got all these new contributors. Well, they need to move along their journey somehow. Now we need a whole new set of KPIs just for them.

Nnamdi: Right,

Robin: Right. Awesome.

Nnamdi: Yeah, there's any number of different metrics out there. I work with a lot of data and application infrastructure companies and that oftentimes are spinning up things in the cloud or on virtual machines, and one really important metric is just number of folks actually running in production. It's like there's that book Crossing the Chasm of going from product development to marketing. There's sort of another chasm of going from just trying out the thing to actually using it in production. And I really love that one because it actually suggests that you're driving real business value for someone that they're willing to go through the pain of making sure that the product is hardened and working and bug free and capable of running in production in a long lived setting. And so that's a big one that my companies often use.

Caroline: That's a good point too. We sure see, I mean this isn't supposed to be a talk just on metrics, but we sure see a lot of companies talking about how many members are in their community and what does that mean. Then I think that really becomes vanity metrics, is that how many people have signed up for your newsletter, your information source, whatever it is, but knowing how many people are actually using the product and using it to actually make something of value is if you can measure that, that's really important.

Robin: Yeah, I always think about as an operator, when I always coach, my teams of activation is kind of pay to play, so get people activated, then you have to look at the engagement however you measure. It'll be different on the different business, but if people aren't coming back and using it more and more often, then you have a problem. You need to really understand it and ultimately then it becomes are they expanding? Are they getting more of their company to use it or are they using it more intensively so that now you're on a path to monetization? So that's generally what I look for in my own business and as I talk to my peers. So hey, that's a good segue to a sales question. So there is somebody who's asked a sales question of the channel, let me read this correctly, and the ID is one Syrian, so I have to look up his name, I'll say his name at the end. I tend to look at our sales orgs as the one-to-one to bottom line sales.

I look at rela seed planters who crops grove over time to become leads for the sales orgs. Is that the appropriate mindset and if true a vanity seed today can become a warm lead tomorrow. So how to seed into active growing healthy plants that can be harvested for whatever you want to do.

PJ: Well Robin, that is very close to the metaphor you and I talked about the other day exactly from Nadi and Carol. So I used to work at a company called Engine Yard and we really, really, really enjoyed train metaphors.

We talked about how our DevRel team, our job was to build the train tracks and marketing was to build the engine and then sales job was to drive it home. So it is kind of that idea, but I don't want to get into the idea that DevRel is pre-sales. That's a big mistake that a lot of people get. Marketing is pre-sales, developer marketing is pre-sales. DevRel is like pre pre that. So let's not even put sales in the same place, but you're not wrong. It's possible that a seed that is planted by DevRel ends up being a worm lead or a full on ambassador level lead in a couple weeks, in a couple months depending on your cycle there. I've had folks in various organisations I've worked for who in no way would think about using the product we were working with and simply showing up in their community, made a connection and that suddenly grew into a lead and we saw a huge growth there.

So that's not a non apt metaphor.

Caroline: Little a little far. I've got two comments on that. I think sales gets a really bad wrap. If you're in a company, you're in sales. If you're going out talking to one of your developers, you're selling unless even if you're in a nonprofit, there's some reason why you're in business. So you're always in sales, whether it's pre-sales or post-sales or whatever it is, you're in sales. The second one I would say is there's such a movement towards self-service that oftentimes unless you are a very, very large company, you're actually not going to see sales at all. So in that regards as developer relations, yeah, for sure, because the advocates are out there and whatever else you're doing online is explaining to them why your product is so fabulous and then you've got a great developer experience for them and they do it.

They might not see a sales technical sales person at all.

Nnamdi: What I would add, and this is sort of irrespective of whether one wants to call it pre-sales or pre pre-sales, is that if you are going to connect it with sales, you need to take that seriously. And what I mean by that is going back to the notion of any metrics and the wait list example, it's something that useless metric, but you need to know how it eventually converts into something that you do actually care about. So if you don't know the rates at which people off our wait list, convert into users, convert into whatever, then it is truly a vanity metric. But if you know that at some rate people who've come off our wait list, convert into users of our product, convert into leads, et cetera, then you actually have something that does eventually tie to some metric of either customer or business value. And so it's sort of like if you want to use DevRel as sort of the seeds for eventual lead gen, totally fine. Just know at what rates that tends to convert so that you can actually take the metrics seriously.

Robin: The way I think of it's the more things change, the more things they stay the same. So businesses are businesses, so the goal of businesses marketing is always going to try to expand and nurture the funnel. That's kind of what they do. Now, how has changed? Same thing with sales. Sales. Their job is to acquire paying customers and that's not going to change, but you don't want them piling on the community chasing people away. It starts to feel too salesy.

So understanding how and when they should be connecting with the customer so that the human salesperson has value to the process is important. I think the third is churn risk. So SaaS businesses are SaaS business, although the metrics are changing, churn is a death to any SaaS business. So understanding who's churning off and where and why are they churning off and how is that impacting your forward renewal stream? That's the other third business metric that again, I think the how and maybe how we measure might even change, but those seem to be the fundamentals of any gross subscription business.

Caroline: That brings up a good point though about what you were all talking about is that corporate alignment and for developer relations, because we haven't had as much respect over the years. We've often worked in these silos, but really it's and hoping that somebody's going to notice us come and say hi, and we're going to tell you how fabulous we are, but it's as indicative on us and Devra to go and meet other people within the company and go to sales and go, please let me understand what you're doing so we can support you and we can compliment you. As opposed to just sitting back going, no, that's not us. We're not in sales.

PJ: Right. No, I agree with you 100%. I think that what a lot of DevRel organisations miss is actually that internal opportunity. They're so focused on that external flow and that external interaction and what they actually miss is you need to be nurturing the same thing internally. You should know everyone in your sales org, you should know, maybe not everyone, but as well as you can at scale. You should know everyone in the marketing org. You should plan things and deal with these things together because when you are dealing with events or you're developing content, whatever it is you're doing in dre, it's connected to everyone internally and everyone needs to know. So you're absolutely right.

If you are a wallflower, first of all, this job is not for you, second of all. Second of all though, it is really not going to work out for you internally if you're just outwardly facing extroverted and inwardly facing introverted, that is not a recipe for success. Also, we've talked about metrics. How do you establish what your metrics are if you don't know what everyone else wants you to do or how you can help them be successful?

Robin: And I know you're really passionate about content, right? So how do you think about the role of different kinds of content that's going to create impact across these different business disciplines that all have a stake in the community?

Nnamdi: Yeah, it's a good question. The first point I always make when I get asked about deral content is always get it out the door and then figure out how to optimise it later. In other words, I think most orgs that I've worked with, especially small startups, have enough difficulty just getting content out on a regular basis that trying to figure out exactly what it should be and what not to do to do, I think is the second order thing. So first focus on getting content out on a regular basis, and then as you become a sort of more formal organisation and you start having these functions build up within your team, that's what some smart discussion we were just having around making sure that you're understanding what the other needs of the other folks in your organisation are, making sure you have good rapport with them, making sure you understand how they see the business and what efforts they're working on.

That's when you can start to tie content into some of the other things going on in your company. And so it can be anything from, I think it's planet scale that has these release weeks where for the entire week they're sort of talking about the new products that are coming out and it's a coordination across the entire organisation. I think it's a perfect example of coordinating content across your internal organisation. It's almost like David Raffin talks about the cadence of when some cycle we have a release and around that release or around this conference or whatever, everyone in the company is oriented towards whatever content, whatever outreach needs to happen. I think getting into that kind of stuff was great and it's something that all folks in the team can.

Robin: Yeah, there's actually, it's more of a comment than a question that just came in around de and support something Carolyn you referred to earlier on. So lemme just read it out and we can riff off of that. Any business that has a set of APIs and invests in developer support team, so not dev but developer support team within their tech support is doing Dev rel. They might not be doing it well if they only focused on post-sale support. They just might not be doing well. But I think it does bring up the topic of the tech support. People have a huge stake in the community and probably also what I've seen is that they probably are one of the best sources of high value content. They get to see all the stuff that turns into cases and all the stuff they don't want to turn into cases even more importantly.

So when I talk to support execs, what they say, there's so much that we know internally that we think should be public knowledge. Now how do we prioritise and publish that in a safe way but also increasingly automated way? So that's one problem I hear about that they're struggling with. They know they do that, that there's direct benefit to case deflection and happier customers, but there's just so much of it, but they have to sift through and figure how to publish. A lot of it's not very structured with all the growth of internal Slack channels and the like. And then the second problem I hear from support people is that as we grow, as we get out of PI Piper status for our business and now the business is going crazy, everybody gets super busy on building product, reacting to next feature request, et cetera. So the founders and the top engineers and top tech support people just don't have the time to respond anymore. So how do you scale the responsiveness as your business starts to thrive?

And then how untrapped, all that internal stuff that so for the benefit of the community. So that's a different set of problems that I've heard a lot.

Caroline: I think every company we've been involved with over the last 20 some odd years have had that problem where you'll get feedback from developers going, this isn't working, and you try and feed it back to product and they're going, well, we don't have time to deal with that right now because we've got to get this next version out, but you can't get the next version out. This isn't working. And you know what, when we were writing the book and really thinking about it, we purposely said, let's talk about support in a positive way. Let's talk about it as developer success.

And I think if we can think about it that way, because often that support and then that feedback loop just gets so mixed because you're either wanting to get developers in the door or products out the door and then all of a sudden and then often the measurements like that, how many are coming in and what's the product going out? And until we really start to think, I think about developer success and about making sure they're creating a product with your product and they can't be successful if your product is not working or if there's not an update that they're looking for, you're not giving them information in time or whatever it is. And so I really think we've got to change that mindset internally about it being developer success as opposed to, oh, it's just support.

Robin: If support is chasing cases, then we'll never get out of our J wheel. I don't think you're ever going to scale. So it's almost like the early days of customer success. So it used to be customer success was about how do you have a great initial positive experience with your product and you're getting value. That's what we used to measure. Then it became more of a renewals game and it's kind of changed the definition of what people think about. But I think going back to those roots of, Hey, people got to love your product and see value of it, otherwise they're going to go somewhere else, even more so in this developer first world.

Caroline: Well, I keep saying you got to remember that your product is an input into another product. They depend on your product for the product.

PJ: Exactly. And have choice positive choices.

Caroline: You can't just wipe your hands of it like you can, oh, well, somebody went out and bought my french fries or my hammer. It's like, I don't have to worry about it anymore. You have to worry about it because you're an input into something somebody else is building.

Robin: Yeah. Well maybe I can just, we'll flip the switch a little bit. Say, okay, if you guys were talking to a CEO who wants to embrace this kind of community approach to growth and is unsure how to think about how to invest, what would you tell her or him?

PJ: I think my first biggest piece of advice would be don't worry about building your own community. Find the community you should already belong to and become a good citizen there. First. Like I said, we work with a lot of open source folks and it's a lot easier in open source because first of all, oh, you're part of the open source community and then you're maybe a member of the Python community and then you're a member of the DevSecOps community within Python, so there's already communities out there. I think one of the big mistakes a lot of organisations make is they go out and say, oh, we're going to be the company X, Y, Z community. And it's like, that's great. No one exists for that yet. You have no users, you have no developers, you don't have that yet.

Go participate in the community, be a good community citizen first.

Robin: It's great brand building.

Caroline: I would say number one, align your internal teams. Tell them why and why we're going to do it. Build a good journey if you can go out and talk to everybody that you want. But if all of a sudden developers come and they can't figure out what you're doing and the experience is very difficult, you're not going to be able to do anything with that and then go and nurture that community and start with the willing.

Nnamdi: Yeah, I feel like you guys have already took all the good stuff. I don't know what to say. I think you basically covered it. I actually appreciated PJ, what you said around going to where people kind of already are. It's a big failure mode to say, we're going to plant the flag on this totally irrespective of what already exists and we're just going to do it. And it just invariably ends up not working super well. I think going to those communities that already exist, understanding their needs, their pain points, just sort of ingratiating yourself with folks, I think helps engender a lot of goodwill and leads to the good product development whenever you start actually shipping.

Robin: Well, let's flip it around then. Andy will go with you first this time, so you can take the good stuff first. So if you have a lot of dev rails, hopefully are listening and watching this so they get their five minutes to come into the C-suite to pitch, here's how we can use community to grow our business faster, how would you coach them how to approach that conversation?

Nnamdi: So I'll go back to my classic fallback, which you mentioned earlier, which is content. I'm just the big content guy. I think it's one of the most scalable things you can do as an organisation, especially as a DevRel team. And the reason I mentioned is that again, a context. I work with a lot of early stage companies that really just don't have that much headcount and really don't have that much time to spare for different activities. And the nice thing about content is once you put it out there, it's out on the internet working for you 24 hours a day, seven days a week, and it has a sort of, there's power law distribution relative to content where maybe most of the pieces you put out don't necessarily do that well, but a couple do extremely well and they basically live on forever. And there could be articles that you wrote three years ago that are still driving a very large share of traffic to your product or service. And so I think content is one of the most scalable, especially in a low resource environment.

Robin: For

Nnamdi: Sure.

Robin: Content never sleeps, right? Yes. Well, I think the other cool thing you and I talked about is that you can also measure content a lot of interesting ways if you're trying to measure what's impact on depending where in your business and the stage of the developer journey. There's so much you can tap into now that you link it to ROI as you track. You got it.

PJ: I'll go next. I'll be in the middle. I would say that first of all, nady was 100% correct exploding content, but I would also say going back to the metrics idea, what c-suite folks really like is clear and concise charts saying things like, Hey, I know that if we invest $10,000 in this sponsorship, we're going to meet 5,000 people when we go to this event. Or I know that if we do a podcast instead of a webinar, we have longer lasting interactions with people as opposed to a one-time thing. Bring it, bring in the numbers. C-suite folks love the numbers because they know they can turn around to the board and say, Hey, look, this is what my rail professional said. This is exactly what we're doing. This is the one case where you can kind of use some vanity metrics and get away with it.

So they're not going to ask you specifically. I've never worked with a C-suite person who is like, Hey, tell me specifically why we're doing 600 to 800 word articles instead of 800, 1200 word articles. They don't need to get into that level of minutia. The granularity is not important. They want big picture, but give them big picture numbers like, Hey, here's our activities, here's what we have our OKRs set at. Here's what we're hoping to do, and here's the information we've received and feedback already. That's the key, and a lot of that is going to be based on the content you're producing.

Robin: Awesome. Awesome. Good input, Carolyn.

Caroline: Yeah, I guess if you're going to c-suite and you're wanting to set up a programme, increase your budget, get more recognition for it, I think you always have to come back to why are we investing in dele? Are we growing revenue? Are we reducing support costs? Faster time to market new channels? We really need to be able to articulate what that investment means to the business. And charts always work. The more

Robin: Beautiful, the better, but simpler the better. So well, I'd say two things. I think it's an opportunity to elevate, so going in and defending or articulating why REL is certainly one approach, but I think coming in and saying, Hey, there's a bigger game here and let's call it developer success. The term that Carolyn used. Developer success is a team sport, so while we as a Dev Rel team might be leading the charge, this is a company initiative to acquire happy customers faster and that just simplify it to that. I think the other thing that works for me, when somebody comes to me try to convince me of something, and I shouldn't say this too much if my own team does it, but is fear, show them what the competition is doing and if we don't do this, we're going to get run over by the competition and look at the awesome job they're doing on content, on activation, on how active they are and all these different community channels that are relevant to the business. It's like we're just being outgunned and there's no reason for that, right? That's an awesome way to motivate a ceo. I could say from perspective,

Nnamdi: One good thing about social media is it drives a lot of fomo. So

Robin: I've heard some CEOs of billion dollar tech companies that are prowling around all these community boards looking for negative sentiment and sending snippets to their team. I just literally was chatting with somebody last week that does, that's all. You don't have other things to do.

Caroline: I wanted to ask a question to Ram remote, if that's okay. As an investor, some of them are finally starting to get it that developer relations is something interesting and is a way to make some money. What do you say to other investors who don't quite get it yet?

Robin: I think you mentioned Nadi Ramon was the host, but Yeah.

Caroline: Oh, sorry. No worries.

Nnamdi: I figured

Robin: You met me.

Nnamdi: Well, it's not in my interest to say much to other investors. If they don't get it, that's better for me. Everybody's losing right now. But maybe if there are other investors who I maybe have more aligned interests with, maybe were involved in the same company. It's funny, I think as in investors, it's very easy, especially as companies scale and there's more metrics and numbers to look at, it's very easy to reduce these things to a exercise. We're scaling this fast, we're adding these many users and whatever, but almost uniformly, if you look at the dev centric that have created a lot of value, they've created a zeitgeist around their company, they've moved mountains as far as community goes. They've galvanised large groups of developers to use their product and almost created grassroots, almost like, almost like consumer-like what you can see in a consumer companies type dynamics around their company. And so one way or another, I think to reach big outcomes and big companies within the depth, the developer world, you have to do this.

There's no sort of just putting one foot in front of the other and making all the metrics go in the right direction that gets you there on some level. There has to be some thing that's sort of hard to encapsulate that ends up sort of driving you forward.

Caroline: They talk about, right? Say that again. The multiplier and the moat.

Nnamdi: Exactly.

Robin: I say for the left enlight investors that unlike Nadi who gets it, is I think investors are pattern matchers, right? You're professional pattern matchers, you're like little machine learning people, but metaphors and showing what's working is probably the best example. So you just take a couple of stories that you can pepper in. Look what Docker did. I mean to me, it's an amazing story. Docker three, four years ago decided to get out of their enterprise distribution business reboot as a bottoms up developer first company, and now what? Last I heard, $60 million growing 40, 50% think it's a miracle and they're not the only ones. So I think telling those stories and showing how what you're doing is similar to those success stories is one easy way to get it across without having to dive too much in the numbers. Ultimately, it is the story that catches you, not the numbers will back up the story

Nnamdi: Hopefully. Yeah,

Robin: That's what I like to believe. Yeah, great question. So there's another comment from Nitin on the channel. The content aligned with the goals of your sales folks that supports great customer conversations works really well. I think it's a great insight. I think probably helping salespeople, if you think, okay, how else can you help salespeople? Because you don't want them being already salesy on the communities themselves. They have to show up and be helpful to people and nurture 'em, but showing them what kind of content is going to resonate people that are at this stage of the journey or experiencing this, here's how you're going to get them more motivated or more educated.

I think that's super useful. If you can tap into this kind of great organic conversation and help them be more effective in their next sales call, they meet that person at an event, what are they going to say to that person, right?

PJ: I think the keyword you had there was education. Your sales folks will see where everyone's getting tripped up, and I'll include that when I say sales, I include the onboarding teams and your technical salespeople. Anybody who's involved in the process of getting someone started with what you do, they're going to see exactly where every fail point is. They should definitely be the people that are informing you, especially on your documentation, your getting started guides, your learning stuff. All of that needs to be coming from the sales organisation. The ones who know they're the ones who, yeah, so on step three it says you should do this, but actually what happens is this, and you can't do that. We need to fix the documentation. That should be an immediate, and this is why again, the communication between sales and DevRel is so key.

Nnamdi: I would say sales people and then sales engineers specifically are a wealth of information. It's actually shocking how much they know when you actually just sit down and talk to a sales engineer about what they're seeing in the accounts. And so spend a lot of time with those folks.

Caroline: I agree. I think sales engineers are some of the gold and companies that are just often overlooked.

Robin: I think going back to more things change, they stay the same. All the businesses I've had that were successful growth businesses, I will say that it was the pre-sales people that made it happen. When you're trying to sell, especially when you're trying to sell something new and you're in a highly competitive environment, the passion they show in getting out there, engaging with the customer and clarifying things, that's what makes a huge difference. And then it becomes at some point, hopefully a perpetual motion machine. So I think this is a whole new era. Pre-sales people, if I had, we're still trying to get into escape velocity, but if I was running a hypergrowth business, I would always be investing first in pre-sales ahead of the sales reps because they're the ones that are going to get you closest to how the customer user really thinks. I think their role changes. They can actually be good synthesisers too of what the heck is going on here so that we can help the rep show up better or we can help the marketing people write better content that's going to influence people or find the right people to write content for us, right?

PJ is finding the right influencers that are saying the right stuff to gets people through the hoop, right?

PJ: That's the one place we want to be careful because I think a lot of times sales says, let's align ourselves with influencers, and you're much better aligning yourself with practitioners.

Influencers can be flash in the pan, they can be come and go. You can maybe leverage them for some brief or some ephemeral content, but in the long run an influencer, what's going to matter? You want that long-term community growth. You want someone who's like a practitioner. This is why I think ambassador programmes and superstar programmes and that are so much more valuable because you don't want someone who says, oh wow, the Kardashian of Ruby on Rails said this. You want someone who's saying, Hey, Jane down the street who uses this every day and knows what she's talking about is saying this is the way to go. I believe, Jane,

Robin: I'd say the 50 DevRel podcasts that we've done so far, only one person said they use TikTok to reach out.

PJ: It wasn't me.

Robin: It wasn't you. Okay. So I thought I'd give each you a platform to share some last thoughts on how you think about, again, how help people align re with the business stakeholders. Any share. Can I

Caroline: Just add a question in there that maybe we can also wrap up with? Certainly, we talked about the CEO level a lot and we talked about sales and marketing, but I don't think we touched on enough about the product people and how we really need to form alignment with them. And I've seen it again in larger companies and I've seen it in startups that are so product driven and we sort of learn as you go, and sometimes it's personalities, but be interested to hear from you folks. I mean, we can talk about customer success and we can make sure that they understand that this is an input, but engineers have been, and software engineers have been taught to be gods these days, and it's often really hard to get 'em to see that they got to play nice with everybody else.

Robin: I think it's a great observation. I just frame it a little bit too, there's a new trend that the people are talking about. The CPO is the new CMO that a lot of companies that had a product who actually owns all these touchpoint functions from developer marketing or Dev re to pre-sales and postsales, the ones that kind of are almost like general managing the whole thing come together, but they're doing it from a perspective of an awesome product experience. So that's another way they

Caroline: Often don't do it from the community experience.

Robin: They probably don't do it enough. So having them get religion as that trend emerges might be interesting. But anyway, I didn't need to interrupt your final words, guys. That's it.

Nnamdi: Yeah. I think as far as final words, I think it's a little bit to what we've just been discussing. I think the best thing to do is to just get alignment as early as possible into our discussion earlier. Make sure you have a seat at the table. The common failure mode I see is startups scale is that the DevRel team is one of the earliest folks there, and then as the company matures, you start hiring in VPs of X, Y, and Z, and the conversations around bringing those folks on board are totally orthogonal to what the DevRel team has been doing to date, and then they end up getting left out of the conversation. And because there's no c-suites or sometimes no VP level DevRel person, deral just rolls up into one of those things, it's easy to kind of get lost in the shuffle as companies scale. And so don't be shy. Fight for your right, so to speak, make sure you're represented and that you're able alignment with the rest of your org and do it from the earliest stages.

This stuff gets calcified at a certain point and it becomes harder later on to fight back.

Caroline: Are you promoting to your companies to have a vp DevRel?

Nnamdi: Not necessarily. If they wanted to do that, I wouldn't necessarily be opposed to it, but it's less about, there has to be one and more just like whatever we do, let's just be super explicit about it and not have it be something that just kind of bends and then DevRel gets lost in the and fall, if that makes sense.

PJ: Yeah.

Robin: Pj?

PJ: Yeah. I think that my final thoughts are really around focusing on building your community, both internally and externally, if you want to be successful, if you want to find value. And the thing that Deel is doing, I think this goes back to what N'S saying is you have to build it up. You have to give it the respect that it deserves and its place in the organisation along with everything else that you're doing. I think that goes with what Caroline's saying too. If you're not talking to sales and product and marketing and the C-suite and all the VPs, what are you doing as a DevRel organisation? You're not cultivating that community, and that's exactly what we do. So cultivate internally, cultivate externally, plant the seeds and watch 'em grow.

Robin: Yeah. You're back to the farming metaphor. We got you.

PJ: Yeah. Cut off

Robin: One of our podcast guests. Describe that as they see themselves as a two-sided mirror, right? They're influencing the community and hoping that they can be engaged and successful with the company, and then they flip it around and say the same thing to all the different stakeholders in their company. How do they benefit from and know how to engage so they can scale their connections with the community. So it really is two sided. It's a tough job doing both of these things.

Caroline: Absolutely. It's a tough job, but it's such an important job, and as we all know, it's very rewarding too.

Robin: Yeah, it was fun. Yeah. Cool. Well, this has been an amazing conversation, so thanks all of you for taking some time out of your day to join. So hope the audience enjoys it as well, and I'm sure we'll see you all soon. So thanks again, deep dives.