How To Build Beautiful Friendships with Marketing and Sales

For most organisations that pursue DevRel, it’s part of a broader go-to-market motion that brings together Marketing and Sales, amongst others. So, how can DevRel, Marketing, and Sales work together most effectively, especially when they risk treading on each others’ toes?
Hear from our panel presenting their take from DevRel, Sales, and investor perspectives. They look at how the different reasons for DevRel, as well as the company’s stage, both impact on the relationship between DevRel and other departments, alongside best practice for working together. There’s also advice on how to tackle the causes of friction between DevRel, Sales and Marketing, where it arises. Listen in to get advice on aligning your DevRel strategy with that of your Sales and Marketing colleagues.
Huge thanks go to Common Room for sponsoring this episode!
Podcast video
Watch video on YouTube
https://youtu.be/VNx7DrlUntQ
Show Notes
Sections

• Figure out how to connect developer advocates to customers and prospects to help them be successful. The difference with Sales and Marketing perhaps is that DevRel looks to build longer term relationships and to solve developer problems, rather than making a product pitch (00:16:32)


• Integrating the teams, making sure that people understand what their goals and responsibilities are, and being transparent around codependency is super helpful (00:28:00)


• At each stage of the buyer journey, different roles add different types of value. (00:31:00)


• DevRel can be helpful in the onboarding process because the department understands the developer specific needs (00:33:00)


• Understanding what it is like to work in the other's role is key. Just doing the job together can help (00:50:00)


• If you're starting out, have a clear understanding with leadership about where boundaries are (00:54:00)


• Many things that come naturally to DevRel can directly support Sales (00:57:00)

Hosts
Matthew Revell: Matthew runs Developer Relations consultancy Hoopy, as well as DeveloperRelations.com, and the DevRelCon event series. He works with companies to help them build and execute Developer Relations strategies. Matthew also creates content and research to help DevRel professionals become more effective. With his team at Hoopy, he works with clients around the world to advise them on developer relations, developer marketing, and developer community.
Josh Grose: San Francisco-based Josh is Head of Growth at Common Room, the intelligent community-led growth platform that helps deepen relationships, build better products, and drive impact. He is focused on outcomes. Usually involving ruthlessly prioritising the things that matter, a bit of creative problem solving, lots of learning, a healthy dose of collaboration, and plenty of doing.
Guests
Dana Oshiro: As General Partner at Heavybit Industries, Dana invests directly in pre-Seed and Seed stage startups, while managing the platform and marketing team. Over the past decade, Dana has helped 150+ B2B, developer and infrastructure company founders from companies like Netlify, LaunchDarkly, and Snyk scale their businesses.
Laurent Doguin: Paris-based Laurent is Director of Developer Relations and Strategy at Couchbase, the company that delivers Capella, the cloud database platform for modern applications.
Matty Stratton: Matty is Director of Developer Relations at data infrastructure company Aiven. He is passionate about helping organisations use great tools to focus on what makes them special and drive relevant cultural change.
Tim Hughes: Tim is Head of Sales at Temporal Technologies, the company that develops and distributes the world's leading open source durable execution system, making code fault tolerant, durable and simple.
Useful Links
Show sponsor: Common Room
Matthew Revell:
DeveloperRelations.com
DevRelCon London 2023
Josh Grose:
Twitter
LinkedIn
Dana Oshiro:
Heavybit
Twitter
LinkedIn
Laurent Doguin:
Twitter
LinkedIn
Couchbase
Matty Stratton:
Twitter
LinkedIn
Mastodon
Personal website
Aiven
Tim Hughes:
LinkedIn
Temporal
Transcript
Matthew: Hello and welcome to a DevRel Roundtable on a subject that I think most of us will have at least touched on at some point in our DevRel careers, and that is the relationship between Developer Relations, Sales, and Marketing. Now, we've got a great group of people to talk about this particular topic. Before we get into the full episode, I want to bring in my co-host Josh Grose, who is head of growth at Common Room. Hi, Josh.
Josh: Hey, Matthew. Good to see you.
Matthew: And you. So, thanks obviously go to Common Room for sponsoring DevRel Roundtable. I'd love to hear a bit about what you're doing at Common Room and why this particular topic is of interest to you.
Josh: Yeah, definitely. I think what's most interesting about this for me is I had the realisation of the value of Developer Relations multiple times in my career, where I worked with our open source groups when I was at Dell EMC to help us to carry a story that not only could teach and provide value to our customers, but also connect some of our proprietary products back to overall outcomes for companies that had open source leanings. 
Then most recently, I was at Splunk and we were working on Open Telemetry, a really large open source project for collecting metrics. And what I found there was we could carry the most influence when we were engaging directly with developers through knowledge transfer education. And so as I saw companies and individuals start to gravitate, it became clear that that was going to eventually lead to product activation, potentially even buying, and social amplification, all of those things. And so here at Common Room, what I focused on predominantly is working with organisations that are open source, open core, because of the natural fit of community developer relations and the relationship it has with overall business outcomes.
Matthew: Great, thanks. Well, talking of business outcomes, let's bring in our guests to ask them how DevRel and the relationship between Sales and Marketing affects their business outcomes, as well as everything else about their work. So, I guess let's bring in Laurent Doguin.
Laurent: Hello, my name is Laurent, and I'm Director of Operations at Couchbase.
Josh: Hello Laurent. Do you want to give an introduction about yourself, as well as where Developer Relations falls under Couchbase, and what some of your goals or KPIs are for your organisation?
Laurent: Yeah, absolutely. I am French. I live in Paris, in France. I'm the Director of Operations, so everything operations at Couchbase. It's a bit of a mixed report to marketing. We have a community team that reports to Marketing. We have a TA team that reports to engineering. Now, my team, DevRel, is really focused on outreach. My job is to give more work to the community team, basically. Increase our community funnel, increase the size of our communities, so that they get more stuff to do. So that's more outreach. Most of the metrics we do in my role is to increase other people's metrics, in the sense that we support the community team, and we support every other department in the company to become more developer friendly.
So that goes with field marketing, that goes with community team, that goes with SDRs, making our SDRs more developer friendly, making them more able to close deals. We work with filtering. We enable field engineering to be more developer friendly, so deliver more developer friendly or developer focused content. So, we are sort of tracking all of the developer focused effort that these teams do. 
We are still trying to figure out exactly what we're going to use right now. There has been rebooting very recently at Couchbase. I would love to set up a peer review process for that because my feeling is that if you always help everybody else, then your best metric is what they think of what you do. So I'd love to implement some peer review at Couchbase. This is still ongoing. And if not, then we'll go with the classic, 'let's measure input and let's see if we can tie all the input work that we do into some output', using some products like Common Room or others.
Matthew: Great. Well, let's dive into some of the detail of that in the episode proper. I'm going to bring in Matty Stratton, who is Director of Developer Relations at Aiven. Hi Matt.
Matty: Hey, Matthew. How's it going?
Matthew: Yeah, very good, thanks. Good to have you on the roundtable. So, I'm going to ask you the same question that Josh asked Laurent. Where in Aiven does DevRel fall, and what are the core goals for your team?
Matty: Yeah, so, our Developer Relations team sits in Marketing. We report to the same VP as our community team and our PLG team, which I think is really interesting, and I actually learned a lot about the synergy of that at DevRelCon in Prague. So that was really, really cool. We can talk about that some more. Where we focus and kind of think about our metrics and our goals, DevRel can encompass a lot. And so of course, on one hand it's all of it, right? But, our focus is primarily around awareness and enablement. 
So we still have a fair number of metrics that we're working on that are more output than outcome, and we're working on it. We're a pretty content heavy team. So we're doing a lot around how we're driving long form, very technical enablement content to be able to help developers be successful with all the various open source projects that encompass what Aiven is.
But we also do set metrics around, and measurements, at least at this point, around activations and service enablement. Creating new trials is interesting, but we also look at the developer journey, seeing people do things with that. And it's an important thing because a lot of times we set measurements and, we'll talk about this more later, but what I sometimes call my internal measurements or my measures, but not a goal, right? 
So we can sit there and say, we want to understand this, but you've got to be careful because you'll start setting a goal that has to go up, up, up, up, up, up the ziggurrat all the time. And some measurements are okay if they dip and they go up because we want to see if we did something? So what we're trying to do with some of those is see the effect that we have. And then also, we got a lot of plans for measurement that directly connect to how we see our impact on Sales and Marketing, which I'm happy to talk about a little bit later.
Matthew: Let's bring in Tim Hughes from Temporal.
Josh: Tim, you're the Head of Sales at Temporal, and I feel like you are the ‘canary in the coal mine’ in terms of seeing a symbiotic relationship between Sales and DevRel. Where does DevRel fall within your org, and are there goals or KPIs that they have to support Sales and Marketing?
Tim: So today, DevRel for us falls inside of product organisation on the open source side, which I think makes a lot of sense in terms of where we are as a company and a project. Temporal and its predecessor Cadence, is around seven years old or so now. Our core kind of goals or things we think about as a company right now is how do we grow the project, and how do we grow it as fast as we can with a high quality around it? 
And from a Sales perspective, we really look to the community as the key place that we find the organisations who are ready to engage with us and start a sales process, or at least start up the process of understanding how our commercial offerings can help their journey of adopting Temporal to drive their mission critical workloads, certainly over time.
And so the relationship there is pretty obvious and pretty tight. The sales organisation has direct correlation between our performance and the size of the community, but also the quality of the community. And by quality, I really mean how many people are adopting the projects, so finding it, learning about it, identifying where and how we can actually assist in developing software inside their organisations. 
And then certainly as they go through that journey, understand where it makes sense to raise your hand and start engaging with Sales, and how we can help out. So for all of those things, I think it makes a lot of sense for DevRel today to sit inside the product org, where they can help have a bigger impact on how people find, use and adopt our open source project, which eventually leads to our paying customers.
Matthew: And Dana Oshiro, you are General Partner at Heavybit Industries, which amongst other things is a fund that invests in developer tool companies. So for your portfolio companies, what role do you want DevRel to play?
Dana: So first off, Heavybit invests directly in very early stage companies. So, it's pre C through to Series A, which is maybe something to note because as far as teams are concerned, there's not really a clear line between departments to be honest. I think DevRel plays a pretty generalist role. And in some cases that person has been everything from product marketing and helping take a product. Basically doing a lot of persona-based feature testing and discovery pre GA. 
There's always the awareness and early usage kind of metrics. They're building social proof and finding user-generated case study type of content. And then of course, docs, developer experience design, onboarding, simple APIs. So it's a pretty generalist, sort of kitchen sink role. And in the same way that they're interacting with Marketing or Sales, it's usually one or two people, if Sales does exist, to be quite frank.
Matthew: Great. Thank you. So I wondered, do the different strategic reasons or strategic goals that companies have for DevRel impact how they relate to Sales and Marketing? And I think for you, Laurent, it is particularly interesting because, am I right in saying that your team at Couchbase falls under Marketing, gets at least some of its funding from Sales, and yet what you're doing is Developer Relations? So you're kind of right in the middle of it all.
Laurent: We've been going through hoops and loops with DevRel at Couchbase, a 10-year-old company. And, COVID happens. The A team couldn't move out too much. The A team was reassigned to the developer experience. They're building more developer integration, and now there's an issue that we don't have anyone that's community facing, outreach facing. And that feedback came from the field, from the assist, from Sales. And Sales realise they're selling a very technical product.
Couchbase is a database company, sales cycles are pretty long. You need to be very thorough in the way you set up work. I was going to say it's not an easy SaaS, but that's kind of saying SaaS is hard as well.
The solution engineer said we are meeting more and more developers, which is great because Marketing started targeting more developers. Couchbase was a long sale cycle, moving to a database as a service, more SaaS-like project, less critical, less high performance, less scalability use case, more data use case for everybody. If it's for everybody, you meet every developer. If you meet every developer, you need to make your speech more developer friendly and less 'this is how you scale a massive cluster and talk about metric and all that stuff'. 
Developer experience becomes more important than performance and scalability. So solution engineers, solution architects realise that we have a different crowd. It's not about architects anymore. It's not about DBAs anymore. We have so many developers who are meeting every day in our sales activities, that we need to get better at that. This goes up into how Sales has been funding this function because they need us, they need to be more developer friendly.
So the way it's built, we're building the team right now. We have four different sales regions. We're going to have one DevRel per region, basically at the start to support SEs. That's our main activity. It's hard to split between supporting Marketing and Sales. And we are sort of trying to figure out what's the best way - supporting SEs, building more content. It will be measured on that. Our scaling forces are assets right now, we are building the team. 
We can not go all out with traditional DevRel activities. We have to scale through the team. So we have to make them better at talking to developers. And so that's mostly where it's originated from. It's also originated from 'well, we don't have a DA team anymore, so we need to go and rebuild community and endeavour'. I know that's the marketing part. We need to support the field marketing. So we need to do all the conferences, all the events, all the webinars and stuff like that. So, this is where it comes from. 
Now, again, in terms of metrics, we're still figuring this out. I'm not going to say I'm against metrics. Metrics can be gamified, and that's sort of a problem to me. When you go to a conference and you set up a game, for instance, you try to get all those leads coming in to be nice with field marketing and say 'look, we have all those leads'. 
You probably have some people that just give you their phone number or email just because they wanted to win that Lego set that you have on your booth. So having too much of a metric approach to me is an issue in the DevRel team. It suits other teams very well. I think my function right now is to help other people scale and see how to measure myself or help them scale. So it's just about my input and their feedback on what we do to help them to be better. And we can see that training SDRs, training SEs, we have better feedback and we have a better sales situation right now.
Matthew: So for you, it really is about that integral relationship between Sales and Marketing. But Matty, you were talking about the importance of feeding back into the open source projects that Aiven relies on. And just to set the context, Aiven provides hosted instances of many open source projects for storing and working with data, for example. So, do you get involved with the sales and marketing team?
Matty: Yeah, and we're kind of building that muscle right now. So for context, especially for people listening, I've been at Aiven since August. So what is that now? Eight months? Maybe a lifetime, maybe just a few minutes. Depends on the horizon that we're looking at. But kind of looking at how we can start to build to that. So how are we involved with Sales at this point? So I can tell you what we're starting to do, and then maybe the next part that we're getting in place. 
One of the motions, and I will caveat this with, this motion only really works when you've got a pretty well defined and mature sales engineering organisation, because if you aren't careful and you try to do this, your DevRels become Sales Eng. There's nothing wrong with being a sales engineer, but it's a different role and a different skill and a different approach.
What we try to do is figure out how we can have our developer advocates connect with customers and prospects to help them be successful, but not necessarily in a way to pitch the product or give specific training on the product or do something of that nature. So for example, we can have a customer that says: 'Hey, we're trying to solve this data governance problem'. So actually we don't wait for the customer to come to us. At the end of the day, what do SDRs and AUs want to do? They want a reason, an excuse to have a conversation with a customer, right? So one of the reasons can be: 'Hey, you know what? Laurent's going to be in region at this event. We know your office is there. We'd love to have him come in and talk to your team about data governance', right?
Not talk about how to use Aiven, not talk about our product and our pitch and our demo, but this idea that's relevant to the decision makers and the practitioners that would be Aiven customers. And this has a couple of really effective things. One is, again, in past lives of doing this, how many times I'd walk out of a meeting and the rep would say to me: 'I've been trying to meet that CTO for six months, and now we have an excuse'. But it also shows some value to the customer or the prospect that says: 'Hey, when you have this relationship with us, you have access to these subject matter experts and to these things that are not just us coming in and demo-ing'.
And then the point to how that connects with your Sales Eng, is the Sales Eng is the fast follow, right? To be able to say: 'Okay, cool. So all these ideas we just talked about, by the way, this is how you can do that with Aiven, if that's of interest to you'. You have that connection. And so we're building that muscle here at Aiven and figuring out how we do that. You have to also make sure you're really crisp with teaching your field how to do this with you. Otherwise, people just look and they take a guess. They're like: 'Oh, well, this is how I want to use a DA, I want to do this'. And we are putting together kind of our catalogue to say: 'Hey, these are the things we can do'.
The other place is getting into the idea of a DQL or DevRel qualified lead, as Mary Thengvall talks about. We used to call them 'warm handoffs' and then nobody knew what that meant, so kind of rebranded as DQLs, because XQL means a thing. But even then I think a DQL doesn't look like an SQL or an MQL or whatever. To me it's a touchpoint, but it's not something that goes into a campaign. 
So what we're building now and working towards is this idea that when we have a touch point with someone, and there's a DA, and then also with our community, we're going to get that into Salesforce under that and say: 'Hey, okay, I talked to Tina Smith, who's an SRE at JP Morgan Chase'. Cool.
What never can happen there is a rep goes in and says: 'Oh, Tina's a contact, I'm going to reach out to Tina'. No. When you're looking at that opportunity, you go: 'Hey, Matty talked to somebody over there. Let me talk to Matty and find out more about what we understand of that case'. You have to be really crisp and protective of how your CRM and how all that stuff is set up. 
There's a whole thing about developers not wanting to be marketed to - that's baloney. Developers don't like to be traditionally marketed to. And shoving them in a drip campaign is a sure way to p**s them off, right? So if we're going to capture those as DQLs, we put them in a way where if there's anything that looks like a campaign, it's something that provides value to them, but fundamentally it's just additional context.
And then from a self-serving perspective, this is how we start to show influence, right? Because then we can start to say: 'Okay, this deal happened. I mean, were we influential?' Who knows? Connecting influence is still guesswork. Getting back to Laurent's point, we don't want to sit there because by doing it this way, I think it helps counter away from that sort of gamified metric. You don't set targets to say we should have X number of DQLs this month. That's just a thing we do as part of our operational thing, but we look at the outcome and then we want to be able to measure those outcomes. 
But we have to be really careful that they don't look like goals. Because you talk about funnel, I mean, DevRel floats so high above the funnel, right? Attribution is so hard to do that you kind of have to look at it as an after effect. Just say: 'Hey, was this influential?' It's a lot harder to see a direct connection between 'I did this exact activity and it turned into this exact revenue'.
Dana: Sorry, I'm not super familiar with DQL. Will you walk it back for me? Sorry.
Matty: Yeah! So, okay. So just a little quick history lesson. And I believe in the Business Value of Developer Relations book they're still referred to as 'warm handoffs'. I think they got rebranded after the book. So there's this idea of saying, in community and DevRel, we have this idea of a 'warm handoff', which is some connection point of someone we have an interaction with that we hand off to somebody else in the organisation, whether it's to product, feedback, maybe it's marketing for a case study, maybe it's a sales lead, maybe it's recruiting. 
So the problem is then, as an industry of the entire world, nobody knew what the heck the words 'warm handoff' meant, but we know what QL, qualified leads are. So we started calling them DQLs, DevRel Qualified Leads, which again is slippery and messy because they're not necessarily sales leads.
So really what these are is they're recording contact points that happened, but it's not like a booth scan should never be a DQL. And this is actually the problem with, like Laurent said, the gamifying. I was at a place where we said we're going to have X number of DQLs a month. And you know what we would do? We set a booth scan at a community event like DevOps, says: 'That's a DQL'. Well no, it wasn't helpful, unless we put the context. These are our way of tracking a connection point of a person who's connected maybe to either to an opportunity or an account that we have so that we have that context. But it's not someone to outreach to, right? And I've definitely had that. 
I mean, think about it as a much more operationalised way of what a rep does when they reach out to the DA and say: 'Hey, I see you're connected to Joe Smith at Panera Bread. Can you tell me about what they're doing there? Because I see you connected on LinkedIn'. How about if it's a little bit more? Because what the DQL says is: Hey, I met Joe Smith from Panera at DevOpsDays Pasadena, and we talked about this'. So now there's some information, but at no point is it an outreach contact, it's kind of that internal connection.
Laurent: Sorry, if you go through a traditional SDR folder, we have a different state of qualification and we know that a 'warm handoff', you know, at the end of the federal, all the colleagues that we get from a conference will be stage one and that 'warm handoff' would be S three, four or, you know, deeper.
Dana: It's not tied to revenue, but certainly within the concept of product qualified leads, there's definitely certain activities that are identified as moving more within a lead funnel, where I have seen teams pretty directly measured.
Matty: I think that's why I really don't like calling them leads because a lead is a lead to the thing. It actually is kind of a diagonal entry point. It can be a diagonal, it can also be the first contact. Because we don't know, right? Like it can be like: 'Hey, I talked to Tina at JP Morgan Chase, they're not even an opportunity for us yet'. Okay, well then that ends up being created. Or it can be that they're an existing accountant. This just gives us some more information. So I think that's the problem with it being a QL. Leads imply sort of this very linear flow of a pipeline, right? And that's not really what this is.
Dana: Multi-channel attribution has never been done very well.
Matty: I just want to see that we touched that opportunity, right? Like even that is even sometimes enough. Although you're right, because the way it happens, I remember at PagerDuty for example, it would be the way that they did sort of the indirect attribution. But then this became a metric with our team. And it was funny because it would be like: 'I talked to so-and-so at KubeCon once and it turned out to be a $2 million deal. So we got a piece of it'. I mean, we didn't get paid, but, you know, it looked like we impacted that revenue and we're like, did we? Who knows?
Josh: I think we're getting into attribution. We could have a whole session on that, especially as the number of digital channels is growing exponentially. I want to hear from Tim because what we're getting into is the tension between DevRel and Sales, and the sacredness of developer experience for developer-centric companies. Now, Tim, leading up sales at Temporal, we're a customer, we've had a great experience onboarding and adopting the technology as well. How do you balance this intention that you see Matty and Laurent putting into the experience for the developer into how you actually deliver, say, a sales led experience in community alongside DevRel at scale?
Tim: It's always funny about how much tension seems to exist or people want to call it out. And the first thing I would say is it should be really transparent and people should be having conversations with those who lead these teams about what each team's incentivised around, and goaled on. 
And if you can do that from the get-go, then you're going to pretty quickly identify like: 'Hey, there's a lot of friction between our two teams, just by the nature of how we're incentivising each team or what we're measuring them on'. So the first thing I would point out is like: 'Hey, well, what is this team responsible for? How are they going and metricing it? And then, what's the point of that thing?'
So, at the end of the day, we all work for companies that eventually want to make money. And the DevRel responsibility is Developer Relations. If we're selling to developers, we want to grow their community. We want to make this an attractive place to be. But I don't think we need to lie to ourselves and pretend that the eventual outcome is to eventually have customers who spend money on the product. And what ideally I think every company wants to be built around and monetise their product on is people genuinely wanting to use the product. So they use the product because they get value out of it. We're lucky enough that we're pretty early in this whole journey, we're not multi hundreds or billions of dollars in revenue with all sorts of different fiefdoms, and it's hard to get people aligned. We're small so we can tackle this challenge pretty early right now.
My broader point would be if we can get alignment around incentives and understand what each team is rowing towards, then it's much easier to create programs and handoffs, and to think about what each team is driving for, and how the different kinds of motions in this funnel actually can work together. 
So like a small example would be meetups. I'm sure most folks have some type of meetup goal or they're regular running meetups. Well, meetups in isolation as a DevRel activity, I would say yields pretty poor results as opposed to if you have a full organisation function built up around it. So your marketing team are going to do quite a bit around the mechanics who are actually running these meetups and driving attendance to it.
You might want to tap into the local sales community or the local sales team for helping to get a prospect or a customer to actually speak at that event. So: 'Hey, we're working with a customer in x, y, z City. We have an event coming up'. Reach out to that person, invite them to join the meetup as a speaker. They have an incentive to speak, because oftentimes it's like free recruiting, so on and so forth. And so now all of a sudden, DevRel and Sales are really working towards the same thing.
'Hey, we want people at this meetup to grow the community and the project. Well, Sales wants to be there to actually work with the different folks who are there from all sorts of different aspects. It's an easy free touchpoint for my customer. It's a free win with my customer if they get to speak at the event. Also, I get to talk to people and prospect into it'. So you can play this out on and on and on.
And then even just think about the post-event process, right? So it's like: 'Okay, well what's the point of doing that meetup? Well, we all just talked about the reasons and the goals and incentives. Okay, so after Meetup, how are we all going to integrate our post meetup touch points to make sure that they make sense? Well, we had a bunch of prospects who threw that event, raised their hand and said they'd like to talk to Sales. Well, we probably shouldn't have those people be followed up by DevRel. We should just have them be followed up by Sales'. 
I think my broader thing here is that integrating the teams, making sure that people understand what their goals and responsibilities are, and then being basically transparent around how we're all codependent on each other is super helpful. And I think the thing that largely gets missed is the main culprit of the friction between the various teams, and so I think it puts a lot of emphasis on your leadership to identify that, and work towards mitigating that or just addressing that friction if it's out there.
Josh: When you think about scaling your sales team, you're bringing in sales members that maybe are more junior or haven't worked directly with a Dev Org, how do you prepare them?
Tim: You can say a ton of things mechanically and tactically how you onboard and train people, but the number one thing for me is to make sure that everybody's - and I think this also, for what it's worth, is somewhat embedded in what your go-to-market and business model is like, how you monetise price and package - aligned around this idea that adding value at any given touchpoint along somebody's journey is our core shared goal and actually solves quite a few of the problems. So when you're talking about this idea of a DevRel 'warm handoff', and things of that nature, I think there's a few different ways that we've seen that that DevRel 'warm handoff' actually can be initiated by Sales.
So a small example would be, we're observing our community. We can see somebody consistently asking questions around, I don't know, some type of e-commerce checkout process, you know, backend challenge they're having. Well, Sales maybe identifies it because they're paying attention to the community, looking for opportunities to sell into the community. But when we identify that person, we might say to ourselves: 'Hey, look, they're really pretty early in their journey. They're asking questions that our DevRel team would actually do a really good job around because they're going to go in and answer a tactical question, but really based off of like, say they've been in our community for two months. It's really pointing out that there's an opportunity here for DevRel to set in and probably expand the art of the possible, or do some like baseline education with that particular customer.
So now you have this weird kind of back and forth where maybe a BDR identifies that this person needs some help. We ask the DevRel team to step in, given where they're at in their journey. DevRel team runs that meeting. Post that meeting, DevRel says: 'Hey look, these folks are not ready for a commercial product in any near term thing. But they've set them down on this pathway to be in a really good spot, in say six months from now. And now the sales organisation can set up flags, or reminders, or whatever it is to circle back with that. Or use tools to set alerts looking for behavioural characteristics, or traits, or things that then say: 'Hey, this person's six month journey we expected is actually happening in three months'. And there's some type of signal they're saying that then says, raise their hand again.
So I think there's all sorts of different things you can do around the training and onboarding, but if you get everybody rallied around this idea that all of our jobs are to add value, and adding value eventually turns into money, then again these handoffs become pretty easy. 
And then, I think it was Matt's point around this idea of attribution and leads not following the linear path. It's a great example. It's not a linear path. It starts with Sales, back to DevRel, then it's going through this funnel of adoption. 'We're looking for signals where you can actually short circuit this adoption funnel and dive in'. And when you dive in at that point it might be: 'Hey, we asked DevRel to come back in again' because really what they're asking for now is like: 'Can you do a lunch and learn where you can talk about our technology to a bunch of other teams who are now observing the success of this core team that originally adopted?' And you're all over the place.
But again, add value, add value, add value, and eventually that value is going to turn into somebody raising their hand and looking for help that you can monetise. And they're going to be very happy to do that, if their experience has been one where 'when I engage with x, y, z company, I always walk away with something net positive. it's not a waste of my time, and it's not just a veiled pitch of their services'.
Laurent: I think stop pitching is a good way to enable Sales. Sales engineers need to be more friendly. That was a huge part of our sales enablement. Lead with problem, not pitch. 
Matty: I was just going to say too, with the onboarding, just kind of a thought - we're not doing it this way here at Aiven because we're in a different stage of this - but I've seen this work too. DevRel can sometimes be really helpful in the onboarding process because they understand the community and their problem. 
And so like again, at PagerDuty, we provided some of the general training. Content that was then training the Sales team about 'this is what the DevOps community is like, this is what DevOps people are like', et cetera, et cetera. But what that does is that that almost from the beginning sets up this like, you have these subject matter experts over here that can coach and can connect. And to be frank, I think most of the problem is on the DevRel side and not on the Sales side.
We need to get over ourselves a little bit. And I think honestly, most DevRels probably agree with what Tim said, and probably are in that place, but we have a lot of very loud people in social media who want to play the one true DevRel. 'We are not sullied by filthy capitalism. We fight for the user, we do all this stuff'. And the reality is, yeah, we all want to make some money. And, as I've said before, there's a sort of belief that when you're leading with Sales, you're, you're manipulating people. And I'm like: 'Hey, if the only way that someone would pay for your product is if you trick them, why are you working at that company?' Right? That seems like a different problem. 
Like I said, I think what I've started to observe is that most 'chop wood, carry water' DevRel practitioners probably get this just fine, but we do have a big perception that's led by this idea. And the reality is, yeah, we all want to get the money there. We're just a little more indirect by it, right?
I always said before, the best salesperson at Chef software when I was there was Nathan Harvey, the VP of community. Nobody saw Nathan coming, right? Because they're like, 'think about Sales Eng', right? By the way, I think that Sales Eng to DevRel pipeline is underrated and can be very powerful. But I used to say when I was a sales engineer, I'm like, customers will tell me stuff they would never tell an AE, because 'oh, well you're like the engineer guy'. I'm like: 'I'm still trying to sell this to you'. And then that goes a hundred fold for a DA, right? They're like: 'oh, you're the community person. You're a HugOps person. I'll tell you anything', right? And this is not tricking people by the way. I know this all sounds like it, but it's not. It's just a way of being able to have conversations in alternate ways. 
Tim, I really like that back and forth handoff you were talking about. I myself have fallen victim to thinking in this one directional way, in this particular implementation. So yeah. Awesome reminder.
Tim: Yeah. Totally. Yeah, I think the other thing too is like, especially for these 'bottoms up developer', kind of like 'PLG adoption type lead' motions... You mentioned JP Morgan. Selling into JP Morgan is a series of sales cycles that last a decade with tens of thousands of developers. And so you land inside one part of the organisation, well, that's like a huge opportunity and signal for DevRel to say: 'Actually, we probably should be allocating some type of resources to this mega firm who could potentially be a massive adopter of this technology. And now that we have a foothold, it's like: 'Okay, well DevRel actually can do quite a bit of work to help expand or evangelise the technology inside of that organisation'. It seems like a thing that everybody would be excited about.
And you know, when I think about it, oftentimes we're preparing content. It's like: 'Well, how can we contextualise this content to the people we're talking to?' Contextualise something industry specific, or use cases, or whatever it is, the things that get them excited. Well, there's nothing more powerful in my opinion than being able to go into a customer, taking existing use cases, and using that is one of the ways that you evangelise and talk about the technology and the problems it solved to this broader audience. But that broader audience always has this core characteristic, which is: 'Hey, we're all working at the same company'. 
So, again, that's like a non-linear path, right? It's like: 'Yeah, we touched them at the front end, then there was a deal, then we landed it, now they're running in production. Okay, now we're going to go back to that organisation because there's huge community that we haven't touched yet'.
Matthew, remember this sort of came up a little bit in some of the conversation after my talk at DevRelCon, which is one type of DevRel we're talking about. So there's a lot of people that believe DevRel is about advocating for the developer into product, and all of this is deaf ears on that, I think, because they're like: 'This isn't what DevRel should be doing'. When you're more of a product-oriented advocate, where do those connections come from? As opposed to an awareness and an enablement oriented developer advocate? Which is kind of a different kind. Some people are all of them, but we've been focusing more I think on that latter one.
Laurent: One thing for sure is that someone's paying for your salary and the goal of a company is to make money anyway. So whatever you do, you know that, in the end, you are for the sales motion, even if it's for the greater good, or however you want to call it. I'm tired of having people asking for a six figure salary and not wanting to understand that the goal of the company is to actually sell stuff to people, which I know sounds like a big shortcut, but that's what we do. Wherever you are, that's what company does.
Josh: I think there are specific programs within product that benefit from that sales orientation. Like when you're thinking about defining your persona or your ideal customer profile by being engaged directly with community or individuals at events, and identifying use cases and so forth, it actually can accelerate your go-to-market strategy because you're kind of the tip of the spare in terms of seeing what developers are naturally doing with your product, or articulating the problem statement better, or anything like that. Those are pretty natural.
Additionally, if you are more product oriented than one of the challenges, especially in larger companies. So if you're a developer advocate or DevRel with a large organisation, then building customer advisory boards is actually pretty challenging, because getting the right persona from the right type of company in a room with other like-minded individuals at the right time with your product teams is actually really hard to do.
Usually it's recruited based on like, how much does this company spend, and who do we know in the company? And so you end up with this 'hodgepodge' of people representing different viewpoints that may or may not actually help accelerate your iteration and innovation process. And so I think all of those can be really helpful. Additionally, one thing that go-to-market relies on is case studies. And so when you launch a new product, you always want a couple of logos and stories of adoption going out with it. But typically, the go-to-market side and product marketing isn't necessarily equipped, and they keep going back to the same well to find these individuals, whereas developer advocates talk to someone new nearly every day.
Dana: I've seen at the very, very early end of it, as far as DevRel and their interaction with the companies is concerned, even prior to knowing what your commercial product is going to be, if you are doing something that is category creation, the DevRel team has to do so much work in actually giving an identity to the persona in which you're trying to pursue. 
So like, think about having to build an entirely new set of practices like the Jamstack folks, right? I think the folks at Netlify started working on Jamstack probably many years before their true commercial product was released. And part of that is that by figuring out this group of practitioners, who have obviously been forgotten as far as tooling is concerned, you can figure out their identity, figure out their motivations, talk to them and figure out all their problem set, and actually build into the solution that you need to with a very sharp set of features.
I don't know how much patience people will currently have in this environment around that type of thing, but I think frankly, if you are a company that has created an entire category and an ecosystem which other players can jump into, that is the most amazing win of all. And I think even for community as well, for DevRel folks to look at it and be like: 'We have created a movement in which people are doing things in a more sane and better way'. What a dream to market that, what a dream to sell that, you know?
Matty: Is that a little bit like when my career ladder at one place said to get to the principal level, it was 'Create something industry defining like blameless postmortems'. And I was like, really? That's my promotion case.
Dana: You're like, yeah, like one person's going to just do that!
Matty: Right? Yeah. But if you can, as an organisation...
Matthew: There's a common problem that Marketing and DevRel teams face, which is that outsized achievements like that set the bar, and then everyone else has to kind of remind people that actually, you know, there's, there's a bit of luck involved, as well as foresight and talent, and all of that. But a lot of DevRel is a process that is just kind of ongoing, and after some time of hard grind, you see the results. And they might not be outsized. They might just be appropriately sized.
Dana: My firm is all ex operators from Dev tool and infrastructure companies, right? And so I can only really speak from my own experience with an early stage firm, and a firm that specifically invests in early stage companies, and say that the things that we look for are indications that developers are excited or there is some ability to build community, right? Like, it is very hard to graft community onto a sales led organisation after the fact. The culture is pretty different. 
There are these kind of very mercenary, very rigid, funnel focused activities, and there aren't a lot, there isn't a lot of room to do a little bit more discovery. And I think what usually ends up happening is we more often see companies that are still figuring out what the product is, and we'll bring in DevRel type people to help them discover that, help them understand their persona, help them understand the problem that they are trying to solve, or if the solution can be validated. In the late stage, it becomes a lot more revenue focused.
Matty: I was going to say, and I wonder also if we're seeing this a little bit in downturn, we've had a lot of pretty latent examples. Also some indirect ones of, there's these things where we look at this organisation that is driving the state of the art forward, right? You know, I think about PagerDuty, we did this with ops guides, like PagerDuty's instant response framework, that has nothing to do with the product, but it is the gold standard of how to do instant response and everybody knows that. And so we built a lot of stuff around that. You talked about Netlify with the Jamstack stuff, and I'm going to come back to that in a second. But we're trying to do this with Aiven. We've got some stuff coming that's like: 'Hey, it's content that's not direct to that, but it's authority building. It's, you know, how do we drive the state of the art forward?'
But then we look at stuff like DigitalOcean, which has happened to all their docs team, right? They had that. And so, it was like: 'Okay, we cut that'. Actually it was funny, the reason I bring up Netlify, and someone prove me wrong, but we were looking for some examples for some content we were doing, and I was like: 'Oh yeah, we're like, Netlify has all this great...'. You can't find it anymore. There was all this, strike me down for using this word, but all this thought leadership content around this stuff, and it disappears. And I think that's a late stage thing that happens too. You start to sit there, and like you said, you bring in CROs and stuff who sit down and say: 'Wait, why are we spending money on something that's not directly impacting funnel, that's not doing that?'
And it gets hard because I think that's a very indirect kind of marketing and leading, but it's incredibly powerful. And so when we're in a case like now, in a downturn, it's like right now to survive we have to do things that require less imagination to show value. And it's a bummer because that's what separates you apart, besides being just like turnkey and, you know, transactional, and yes, we have this great product, but it's all the ideas behind it, and it's a great way early stage to grab on and get a name. And then I feel like we've got companies that did that. And then, like I said, then they get to later stage and it's like: 'Oh, but that doesn't matter anymore'. It costs a lot of money for something that doesn't look like it brings any revenue, right?
Dana: Yeah. I mean, I guess it's less that it's late stage and more that it's like if your valuation is primarily on paper, and is not validated by the actual revenue behind the scenes right now, you are scared, right? And I think right now in particular, like this is a perfect storm, because tensions, like we talk about DevRel and Sales and Marketing getting along, like tensions are high. User and customer return is pretty high, due to company closures and budget cuts. 
Teams haven't met, they've been remote working for years now, and you have no idea if you even know, you've met your salespeople or marketing people or whatever in person. And then companies who have raised too much money, or need to extend their runway because they don't want to fundraise in the next year or so, or they don't want to, or they can't IPO in the next year or so, have to do riffs and layoffs.
And so departments are kind of blaming each other as far as missed targets are concerned. And this is where, I mean, Marketing teams and DevRel teams get gutted at times like this. And so I think it is very timely for us to talk about how to tie your metrics to something very solid. But also, the really big opportunities don't come from turning the crank and trying to double, double, triple, triple your revenue every single year. At a certain point there needs to be a more creative approach to all of this. And you can't continue to be like a market leader if you don't change.
Matthew: I mean that kind of brings us onto something I wanted to talk about, which was friction between Sales and Marketing. We've talked about harmonising them and good relations, handoffs and so on, but it's not always the case that these teams get along. And I think one reason is there is some friction between Marketing and DevRel because sometimes it feels like they're going after the same bits of budget and the same results and so on. I'd love to hear how you've dealt with that friction in your organisations.
Matty: Some of this is perceived and some of it isn't, right? Like perception is based in reality. There definitely are people who work in Sales that are not necessarily what come across as the most ethical maybe or whatever. There's also people like that in DevRel, just so we're clear, right? You know what I mean? But, I do have a story like that. It's a reframing exercise a lot, number one, right? And this is part of the reason why, and as Tim talked about this, about understanding the incentives, and there's a lot of people in DevRel that don't know what sales motion looks like, right? 
We're supposed to be, what do people call developer advocates? Empathy engineers. We have zero empathy for the salespeople in our company as a unit, generally speaking. But if we understand where they come from, and what it's like to work in that role, sometimes it just helps by just doing the job together. Then, the people become people, and then sometimes you may become people and you're like: 'I don't actually like you'. And that's, that's the thing that happens too in life, right? So it is a little bit of reframing, a little bit of that understanding. 
Here's one of the biggest ways to put it in context. I remember my team used to be invited to our Sales kickoff at one of the companies because it was a good way to talk to them. So we were sitting in all those, and of course they're having the big dinner, and it's like: 'Hey, this is everybody who won the trip to this exotic location' or whatever.
And I remember our CEO said: 'We have all these other people'. And the company that said: 'Well, this isn't fair. Why do the sales reps get to go to Greece and get to do all this?' And she said: 'Do you want your job to be continually reevaluated every three months about whether or not you were even reasonable at what you do, and live or die every day? Cool. Then you can go on an exotic trip.' You know? 
And that's the thing to understand. Like, there's a thing, we don't get it as much in non-sale roles, that you could have the biggest quarter the company's ever seen. You could sign the biggest deal that was ever done, and on the last day of the quarter, everyone applauds you. The next day your Sales VP goes: 'What do you got for me now?' 'Don't care. Don't care. What's that? What's in your pipeline? Where's it going?' 
And when we understand that, we understand the people's motivations and what they're trying to accomplish. And we also one of the things for us to learn is don't bother salespeople at the end of the quarter. Like that's not the time to ask for a favour from an SA, right? That's a beautiful thing for us. Even when you're connected to Sales as a DA, you're not closing any deals, right? We don't have the panicky end of quarter. We're earlier. 
So I think one of the things is that just working on stuff together eventually breeds empathy, right? Just by doing it. I said a lot of times we just haven't even met people in person and worked on stuff. So I do think this sort of 'ride along the customer' stuff helps a ton, because now we're people, right? We're not just slack messages, we're not just requests. We're also humans.
Laurent: I think it depends on what you're selling because if upsell for you is super important, as DevRel, doing lunch and learn, doing lots of activities, and an existing customer is bringing tremendous value, you are really helping them, making sure that they can upsell more. So it's not just before, it's also after. 
Now about sales, I guess it depends also on where you are because a sale on the zero to 10 million will be completely different than a sale from 10 to a hundred, or a hundred to 200, because AR becomes more important than just getting logos. So it completely changes the way Sales works as well. And I know because I was at Couchbase in 2014, where we were on the zero to 10 phase, or zero to a hundred, and now I'm in the higher phase, and it drastically changes the way they operate. And if AR becomes more important, and if churn becomes a much more important metric as well, then that has a very big impact on how we keep and how we grow our existing customer base.
Matthew: We've had a really interesting conversation. I think though, to start to wrap things up a little bit, do you have any closing bits of advice from all your experience, each of you, on what DevRel people perhaps at the start of their career should be looking out for when trying to make the most of those relationships across the organisation?
Laurent: Get to know them. Just talk to DevRel. That's what Mary said. Yeah. Like make them a human being, not just a function. Get to know what other people do in the company. Some tech will stay in their tech bubble for years and never understand what Marketing does, or what Sales does, or what the go-to-market motion is. And if you are DevRel, that's a problem. You should understand most of the other roles, especially go-to-market motion. DevRel is practice. It doesn't have to stop with people hired as DevRel. It could be anyone. Part of my role is to actually talk to Sales and make them more DevRel-ish, in a sense. And I think that's what you should do. You should talk to other people.
Matty: I think especially if you're starting out. So the advice is different for a DevRel leader, because I'm going to pin some of this on your DevRel leader, but if you're starting out, make sure that you have a crisp understanding with your leadership about where those boundaries are. On the other side of this, it is really, really hard for people in this role to say no to people because you fundamentally don't want to do this job unless you're someone that wants to help people. If you don't have a specific way that these engagements happen, you're going to end up just sort of doing whatever is asked of you.
And so it's easier to say yes, actually the more senior and authoritative you are in the organisation. So be enabled to say no, be enabled to escalate, but ask questions, right? And again, remember, no is temporary, yes is forever. It's true in open source maintenance. And it's true in this thing too because once you say you're going to do a thing, now you're doing the thing, and you're probably going to have to do it a lot. But 'no' can be 'let's find out a little bit more about it'. So, let your boss be the bad guy.
Matthew: And Dana, for the early stage developer tool companies that you are working with, is there a playbook that you have that you think would be kind of generally applicable to other firms? Or is that really specific to Heavybit? What advice do you give to those companies when they first start to look at how to engage with developers? Which I guess is at the very beginning for your portfolio.
Dana: I think generally early stage companies pursue DevRel programs because there's some developer led product in the broader commercial effort. That being said, if you really just hope to outsource that to some poor DevRel that you hire, versus actually caring about the community, it isn't going to work. 
It is so much work to listen that closely to your users, especially when you actually get to a point where you get into the thousands and hundreds of thousands. So I would say if you're going to do community, be all in, and if not, then figure out what your other go-to market is going to be. But I don't think it's for everyone. I think it is extremely efficient from a marketing and commercial effort perspective, but I don't think that it is meant to be for every team or product, frankly. There's a lot of deep tech products that are for enterprises or for large enterprises. Tracing for example isn't necessarily something that ICDevs will care about, right? So you sort of have to figure out your flavour of it.
Matthew: And Josh, what are you folks at Common Room seeing that you would point to as the best practice in terms of this integration between all the different touch points along the customer journey, I guess, the buyer journey?
Josh: Yeah, I think it's understanding that a lot of the things that would come naturally to DevRel, whether it's a workshop, a lunch and learn, an event, they can directly support Sales. And so don't think that just because you're doing something that isn't necessarily funded or asked for by Sales, doesn't mean it can't be associated with their outcomes. And so having an open mind in terms of what you naturally would do in terms of creating awareness, striving, adoption, et cetera, plays a role. And then creating an input metric around that. 
So if we want to do workshops or this or that, hold yourself accountable, do that and then see what happens. The lagging indicators that you might see in terms of adoption by people that attended those will show up. I think DevRel is this belief that if we do the right things for developers to become aware, adopt our products, engage, if they feel heard, if we can accelerate their journey so that they can deliver real outcomes for their companies, then it will be a net positive for us too.
And so, realising that most of what you're doing will connect to Sales in some way, let's just try and be thoughtful around what we prioritise, and then hold ourselves accountable to do it, and then you'll get a lot of support.
Matthew: Well, one thing I would say is that as a DevRel person, you probably need to be quite vocal about what you've done as well, especially if you've done a favour for another team, and look at ways of repurposing that so it goes more directly towards your own goals. So if you do a lunch and learn, how can you turn that into a Twitch stream or some other reproducible reusable bit of content?
Okay. Well thank you very much everyone for taking part in this discussion. I'd like to invite each of you to share where people can find you on the Internet. So Matt, let's go first with you. Where can people find you?
Matty: You can find me on Twitter @MattStratton, or on Mastodon at MattStratton@hachyderm.io And I'm also on LinkedIn @MattStratton. You can find me pretty much as Matt Stratton everywhere. MattStratton.com.
Matthew: Great, thanks. And Dana, where can people find out more about you and Heavybit?
Dana: So you could check out heavybit.com. You can honestly email me directly @danaheavybit.com, which is very easy. I am Dana Oshiro on LinkedIn, Twitter, basically everything.
Matthew: Great. Thanks. And Tim, how about you?
Tim: Yeah, best place to find me is just tim@temporal.io, or on LinkedIn. You can just find Timothy Hughes at Temporal.
Matthew: And Laurent?
Laurent: You can find me with L Doguin, which is spelt L D O G U I N on anything social. And if I'm not there, then that means I don't have an account there. Twitter is probably the best way to get to me.
Matthew: Great, thanks. Well, Josh, it's been great spending this time with you. I'll leave the final word to you then. Where can people find more about you?
Josh: I'm on Twitter @sudotechie, LinkedIn, of course, Josh Grose, and then jg@commonroom.io.
Matthew: Great, thank you very much. Well take a look at DeveloperRelations.com, and I'll say thank you very much, and goodbye.
If you enjoyed this DevRel Roundtable, check out the other episodes in our Roundtable series here