Measuring your developer experience journey

Caroline Lewko: Good morning from Vancouver, Canada. And, yeah, interesting to try this new way of of presenting. Used to being involved with so many people. And as you can see, I've got a lovely green screen knot. I've been working at home for, gosh, oh, oh, well over twenty years, and my advice to you is make a space that makes you feel really creative and that you really like like coming to.

So hence my flamingo dream color. Should I have known that we were gonna do more of this, I might have thought about a green. But anyways, here we go. So I'm gonna share my screen now so you can see see my presentation. And feel free to ask questions throughout.

We've got quite a bit of of time. My intent is to share with you some of the thoughts that I've got around development, about developer relations, about about measuring that journey and about metrics, of course. And, myself and working with, James Parton, we're gonna be writing a book on, developer relations. We're up to about a 100 pages now, so we've, we've been really, really busy. And so some of the things are some templates that we put in place that we've used with our work over the last little while, but also we're hoping that are gonna work for for you and for the community at large.

So, feel free to, comment, ask questions. Yeah. And just just let us know how things are working for you. So here we go. Share screen.

Speaker 2: And

Caroline Lewko: there we go. So I'm talking about measuring your developer's journey, as I mentioned. And, you know, here's something from Lao Tzu that the journey of a thousand miles begins with with a a single step. So everybody's gotta start somewhere. And that's important to think about when you're developing the journey for your developer audience.

Where do you want them to start? So I found this other quote that said the first step in a journey is to lose your way. And I thought, okay. Well, maybe if I was gonna go and travel around the world and and see a number of different things, I'd wanna lose my way a little bit because then it's just much more exciting. But when we're talking about developer relations, we don't want our developer to lose their way when they're coming into your into into your developer relations program, if they're coming into your portal, because that's just gonna get them frustrated.

And we've heard a number of talks over the last little while talk about friction, and that's exactly what you don't want to happen. So you don't want them to lose their way. So what we've been saying is all great developer journeys start with the map. So one of my colleagues had that. So thank you to thank you to Dana for for that quote.

So here's the developer journey map that we came up with. And I'm gonna show this a few times, and we'll also make it available to you. And it's it's changed a bit for us over time. And it's always important to think about just developer relations as a whole too as something that's that's quite fluid because we know that it can fall under marketing, it can fall under product, it can also fall under support and success. And the whole developer experience piece too is sort of a more of a tighter piece than some of some of the rest of it can be.

So know that this can be fluid, but there certainly is a stage that developers follow in terms of discovering you, evaluating what you have, learning about it because as we know, developers like to to learn and try things out to unreally understand if it's something that they're gonna use, that they're gonna build something. And if it's something and the right timing for them, they'll scale it. And so understanding what you need to provide along this journey is really important. So if we take a look under discovery, you know, there's a number of things that are, you know, much more marketing focused around making sure your SEO is up to date, and you're doing some things that are social and some things that are event based, and you've got your blogs. And, of course, in this phase, we talk about from those key own touch points that you have and the key external or the earn touch points where you might earn them or you might purchase them.

So there's a number of different pieces around that. Then, of course, when they wanna are gonna, you know, come a little deeper and they've actually made their way to your to your portal, they're gonna evaluate it. And, you know, what do what do devs do first? They're gonna go to their doc your documentation and go, like, can I even understand this? Or perhaps it's behind, you know, a closed wall or it's in a PDF.

It's just gonna waste my time. You know, those are friction points, which, I'm sure that you've heard about before. As they go on to learn about what you're doing, the first thing they tend to do is like, you know, how quickly can I put a time to hello world together? How fast is that? Does it make sense to me?

If I'm doing any cutting and pasting of code samples, are there errors there? Onto the build, you know, they're gonna try and figure out how quickly they can actually put something together. They're gonna take a look too at, you know, is there value for money if if there's a charging model that you have? How do they get support? And then, of course, when they're ready to move it into production.

Now if you see in this map too, in this in the center, we put, you know, sort of circle around the developer experience. And I often find, and I've even been guilty of this, as well, that the developer experience piece often gets mixed up with the whole larger developer journey map. And so the whole journey map really looks at, you know, from when developers find out about you to actually when they built something with your with your tool or with your product and that they continue to do something. And the developer experience part is really more about the product and the portal that you have and the documentation that goes around with it. So we're gonna go through a few more of these steps.

I'm gonna show you some examples and and talk about a couple of other things. So it always comes back to, you know, this journey and this map. It's like, where do you actually want developers to start? Because if you're not thinking about where you want them to start, they're gonna come at it from a number of different places, and they might go off in a different direction that you want to. Or they might, you know, come into your your developer portal or find out about you at an event and actually go off in a different direction that you don't want them to, and then you're gonna lose them, and you don't want that to happen.

So first, I just wanted to back up a sec and talk about just developer relations as a whole. Because I do find too that we often get a little bit mixed up in where we wanna measure everything, or we don't know what we measure. We don't know what our budgets are. And we might be in different parts of of a developer relations community or a company, and it's quite different than maybe what one of your peers is doing. And sometimes it changes too.

We've definitely heard from people where, you know, developer relations and marketing, but, oh, now we're reporting to product. And so it's just important for you to understand that. And so when we come in and talk to folks about developer relations, you know, we we follow a little bit of a playbook. And first, there's gotta be this common understanding of, you know, what is developer relations and who developers are and what that business model is. You need to get alignment on the corporate goals, and that's something that's just so super important and that we often find as well that developers or folks within dev dev rel don't often know or even try and find out what those corporate goals are, and that's so important.

And, of course, I hope you're all going through your developer developer segmentation and your persona development and your messaging to get that correct. Then you can finally activate your strategy and, you know, put together that activity and content plan that you want, and then, of course, measuring and and reviewing metrics. So if we wanna start with what that common understanding is in terms of developer relations, and, again, this can get really confusing to some of us. You know, we I I I often see you know, even to this day, developer relations is over twenty years old, and there's still a lot of folks going, what is developer relations? And, you know, to that to extent it it can get a little bit confusing with some of the nomenclature.

So, you know, it's really two things. It's it's all of this. You know, it's it's this professional practice of how we engage with developers, and it includes the pieces of developer marketing, developer experience, developer access, and developer relations. It's even a is even a part of that, which is you know, tends to be the part where that that's the most direct interaction with with the community. So it's a professional practice.

It's also a set of activities. And when you understand those pieces, it makes it a little bit easier to understand, you know, how you're gonna put some of your metrics and how you're gonna put some of your strategy together. And you may be part of a developer marketing team, is more about the outreach, and, you know, that's where developers are discovering and evaluating who you are, what you have to offer. The whole developer experience as we talked about is on the product, the self serve portal, and the documentation that you provide. Then you've got developer success, which is nurturing those developers.

Some of it's support. Some of it is, you know, working with them for their contributions, and, you know, you might have a developer advisory board. But it's also account management because this is still part of a business, you know, that we're part of. And developer relations can play a piece in all of those parts. So when you're thinking about your measurement again, you know, you need to understand what that vision is within the company, but also how you can make a difference based on on where you are and how the you're working with the developers that are in in your community.

So we go back to the developer journey then in all of this. Again, you know, when developers are first discovering your view, is this abuse to me? Can it help solve my problems? Are you even credible if you're somebody who we really wanna work with? They also wanna look into and see if it's you know, somebody else used this because, you know, unless you're a beta tester and or even an alpha tester or know the folks, nobody really wants to be the first person to to try this out.

Evaluate it. Will it meet meet my needs? Learning about it. How does it even work? You know, are the docs good?

Do I have confidence in this company and this product to be able to build what I need to build? Finally, I'm ready to build it. Definitely gonna make a proof of concept and find out, you know, is there some support here? Is there some value for for the money? And then using it in production.

And then, like, can I do some more things with it? How can I get feedback? How can I contribute? And that's even where developer relations jumps in a lot more to be able to use those folks as champions. So, again, I just wanna iterate a a note about this journey is that there's there's not necessarily hard lines.

It shifts, you know, based on your company, what your product is, where you fit in the company, what the goals are, and what your metrics are. And for those of you, I hope that have had an opportunity to take a look at the state of developer relations, we found that there's no dominant functional reporting structure for DevRel. You know, you can see here that marketing tends to be a little stronger, but not necessarily. And it quite makes a difference too, you know, whether you've got a big company or a small company or whether you're a developer first company or a developer plus company. So, you know, if if you look at this and go, well, you know, I'm really putting our portal goes here and some of the experience stuff might fall into here, that's okay, because things will shift a little bit.

It's more important that you really understand what the big picture is and and have those pieces in place. So if we take a look too at, you know, what those pieces are, and this might help you think about it again when we overlay the developer relations components on top of the journey map, you know, you see on one hand, developer marketing more again around that discovery part, but, you know, sometimes those of us in developer marketing, we're writing documentation and and code samples as well. And developer relations, again, goes across all those pieces. So, again, it's just it's good to see sort of where those pieces are, where you might play, and who you might have to play with too. But at the end of the day, it's all about what we're here for.

Right? So developer relations and and that goal is about, you know, how are you gonna enable? How are you gonna help a developer to be successful with your product? And we found within our developer relations survey too, and that's why I had to put product there. Some folks are going, well, what what do you mean by by product?

But when we talk about developer relations, we talk about that developer product. So it's your API, it's your SDK, it's your HDK, maybe some developer tooling, the marketplace, the library. And all along, you want it to be you want them to be successful with your product, but you've got to align with your own corporate goals. If you're not aligning with your corporate goals, you know, it doesn't really matter how successful the developers are. Somebody's probably gonna cut your program anyways.

So it's really important that those be in balance. And when you think about what drives developers, it's really that pride of going, you know, I made that. So you wanna make sure you've got a great journey, that you're aligned, and that you you're measuring the right type of things too because, you know, otherwise, you can have a really sad developer. And, again, you can have a great program when they're developing some great things, and and from your level, things are really successful. But if you're part of a really big company, James Parton often tells this story where, you know, using Telefonica, where they're making billions of dollars.

And even though the program was really successful successful making billions of dollars and some really interesting products were being made, because it's just so small and there really wasn't a great alignment to what what corporation was thinking, the program got canned. So you might have done everything you, you know, you needed to do to make developers successful with the product, but, yeah, that overall perspective is so, so important. So there's factors that affect the time to completion of your developer journey, which is also the way, you know, developer adoption of your product. And we tend to see developer adoption quite different than what we see adoption in other consumer business products. And the adoption can take a much longer period of time.

And, also, you know, you can get a subscriber coming in or somebody who's a user of something, haven't yet paid yet, and it might be a really long time until they actually, you know, go and develop something that that can scale. Some things you can control with this, and others that you can't. So, you know, you can you can control how much awareness you're doing, friction in your product, the friction in in your docs, you know, the support, your pricing, and the engagement you've got with the community, But you can't control their own motivation. You know, maybe they're just giving something a try, and you can't really control their product readiness either. You can you can, you know, do your best to have something that's great for them.

But, you know, maybe the project manager or their company is going, we'll learn about this and, you know, maybe we're thinking about adding this in later. But what you can start to influence and and support them with is their ability to influence or their decision making ability. So that also comes into how that journey is set up for you helping them to on this adoption journey. So we get back to this developer journey map, and you might be going, oh my goodness. This is a lot of stuff, stuff to think about, or I'm hoping you're looking at it going, yeah.

I can, you know, I can use this. If not, again, I'm hoping you guys will be some beta testers for us. You know, take a look at it and try it. Let me know what's missing from it. How would you maybe do something a little bit different?

Because I think, you know, as a developer relations community, I think it's important that we, you know, have some tools that that we use and and work together just to support, you know, all of us, which is, you know, what a lot of what this conference is about. And so, you know, we'll get back to it, and I'm gonna show you show you some examples of how we've used this journey as developer journey begins when they first learn about you. So you've gotta get the awareness right before you even think about and I've always thought the docs were the most important, and they are really important. But if developers don't get into the journey at the right spot, it doesn't really matter. So, you know, when we look at the research, there's sort of, I say, four plus one, five ways that developers learn about you.

Google Search always comes up as number one. So you've gotta optimize for that. It's peers. You know, they're gonna find out through different places that they hang out online or conferences or somebody that they've known that they're gonna talk to, GitHub and, you know, and or Stack Overflow. And then your team, you know, what's your team doing in terms of the events they're going to, the social that they're doing, the, you know, the developer media, that they're engaged with.

And then there's a whole pile of other stuff in terms of the way they way they learn about you. But you really need to optimize for for that for those top four. And so when we go in and do friction logging, or look at the developer journey, we ask developers who do it for us to, you know, try and find it. How long does it actually take you to find what you're looking for? How many pages do you hit?

What do you think that's great? What's not? You know, what's irksome pain points, friction or friction. There's always a typo there. You know, too many steps, information is hidden, then maybe what are solutions to fix that.

So I'm gonna just take you through a quick journey, and then we'll look at some metrics. We too you know, you gotta look at it from your persona's perspective, and we also look at it based on, they have never heard about you before. They're already a customer, but maybe not part of your developer program, or they're a current customer, and there's maybe a new tool that you've got. And so and then where their starting point is if they don't know about you, maybe they, you know, they wanna do something based on, I don't know, telecom API. So they type in telecom API, Where are they gonna end up on a Google search?

And that's where, again, you need to try and control where they're gonna land. So let's take a look at, something that we, we did and looked at. So here's the developer journey. This was a persona of a new developer, put in some generic search term. And, what you'll see in the red box, down below is some actual developer, you know, what what they wrote about.

So they still couldn't figure out they actually, did some research,

Speaker 2: you

Caroline Lewko: know, actually landed on the landing page of the corporate page. So they didn't quite get to the developer relations, you know, the your developer program page yet. And they looked at it, and they go, I can't figure out what these guys are doing. And, oh, there's some case studies. I'm gonna look at those because those will probably give me a better sense of what this company is doing.

And the case studies would require that you register for them. It's like, oh, I'm not gonna do that unless I don't even know if I'm interested yet. And right away, it's like, you know what? I'm out of here. So you've already lost them.

So we tried again with the new persona. And, again, a new developer hasn't heard about you or maybe heard about you from somebody, they know your company name, but they do a search on, you know, your your company and your API or your company and your tool. You know, it's still they haven't reached the developer portal. Finally, they get into it, still really confused about what it is, you know, as you could see with some of the issues. There just wasn't enough to keep them there, give them a sense of what they needed to do, and why it was really important for them to to be there.

So, you know, they stopped looking. So, you know, they haven't even gone to the rest of rest of the journey yet. This is another persona. They're doing another search. Again, they heard about you, so they actually go to your, you know, sort of corporate website and, again, finding some similar things where registrations are required and just, you know, not gonna spend any more time with it.

And they haven't even gotten to your docs yet to find out if you've done something really interesting with them. Another persona who's we said is actually familiar with who you are. You know, maybe they're a customer in a in another area of the business or they're an ISP or some sort of a some sort of a partner with you and you know, or maybe their their company is, you know, and some project manager says, heard these guys about a new API out of a new SDK. Can you go check it out? So they know right away to go, where do they go, because they're familiar with it.

They understand what you do. But if the you know, here's exactly what a developer was saying. Well, I looked at the video, but it was all marketing fluff. Not getting a good feeling about this. K.

Kinda get what they're doing, but not really sure how to access it. Finally found a link that tells me a little bit more about your APIs, but I have to log in to find out even what you're offering. I'm gone. This one, familiar, know you have a product, go actually straight to your developer page, but, you know, finding a lot of the similar things. So, you know, these slides, you can sort of take a look at it another time, and I'm sure you're familiar with some of this, friction logging as we've seen from some of of the other speakers.

This one, you know, similar type of thing where they actually sign in, but then the API key doesn't work. So, you know, making sure that all of those things are really import are are are complete and are ready for your developer on their journey is is really important. So, again, you know, it all comes back to where do you actually want your developer to start? So for some of you who are are technical or going, you know, what do we need all this marketing for? If you don't market properly and have that set up, they're not even gonna find your great documentation and to be able to get started with your product.

So that starting point is really important. So when you think through all this the possible scenarios of how a developer might learn and find out about you, map them out, you know, make it easy for them, reduce that friction, and it's those touch points, that need to be accessible when it's the right time for them, not necessarily the right time for you. And we often find using this journey map is really, important when you're starting your program, you know, launching a new product, and just periodically to audit how effective you you your journey is. We certainly find that, you know, you've got a new you know, you put something on a change log, but you forgot to change your documentation. And, you know, the developers who are actually developing the product don't always think about all of those pieces that need to need to be done.

And, also, think about who is actually in the decision making unit of that whole journey map because it's not always just the developer. Sometimes it's the product manager. You know, if you're into something like machine learning, there's data scientists and data engineers and and, you know, product managers in that too. So it's important that you, you know, do those do those mapping and and your personas ahead of time. Okay.

Let's finally get to measurement because that's what this day is supposed to be about. So, you know, as Steph says, measurement is great, but you need to make sure that you're measuring what's important. And we always come back to you wanna measure what's relevant to your business Because if it's not, your program's not probably gonna be around for very long. So as Vera said, thought, Vera, I thought you did a great presentation on the OKRs. You know, exactly that.

So you're measuring your priorities and so you can communicate what they are and work with the team, but it's that last bit. You know, it's about forecasting. It's about making improvements, but it's also proving your existence. And, you know, for developer relations, if we think more about how we fit into the overall company and the overall team, that's a really important piece that we that that we can't can't forget about, and, you know, we wanna make sure that we're doing right by developers. So, you know, we've got our business goals and objectives and then the developer program and then activity and community metrics.

And then, again, alignment with corporate goals is imperative. If you're gonna be misaligned in your goals, do it for the right reasons. Right? Because you've exceeded your goals in doing something really great, and you're driving that ROI for the business. Otherwise, if you're misaligned, it's very easy that your program could get caught or you keep getting tossed tossed around and, you know, not getting the resources that you really need, whether it's budget, you know, or extra extra people, and support within the company as a whole because you do need to work.

And, you know, DevRel people have understood this, I think, just innately from the beginning, that we do need to work with a number of different types of of people within our companies and outside the companies too. So we need to make sure that we're really aligned with what with what's happening about that buy in corporately. So there's a number of different stages around metrics that that you can go through when when you look at the developer journey. And here's how we've mapped them out this way. So if you map your developer journey with your own, developer relations journey, kinda looks like this.

So you're creating that awareness. You're trying to activate them. You're getting them engaged, and then you wanna retain them. And the other piece that's important in metrics, again and again, it's about looking at that big corporate picture is the stages of the funnel. And so and here's here's why.

If you're just focusing on, you know, the DevRel lead or the marketing qualified lead or even, you know, just the subscribers or how many social media followers you have. You know, if we go back to the slide that talks about, you know, your alignment, you're gonna be out of line. Most companies have got some sort of a product. They're using HubSpot. They're using Marketo.

They're using Salesforce, and there's a funnel stage in there. And you need to be able to link into that, again, to be able to get that credibility that you need within the company and just to be able to monitor, you know, what's what's working and what you're what you're driving towards. So if you can also think about what you're doing in terms of these funnel stages, I think you'll be a lot a lot more successful in in what you're doing. And so here, we link the developer journey to some of those, you know, sort of do a deeper dive on the call to action and and the metrics. Again, your journey, DevRel journey.

You know, what's that thing that you're really looking for developers to to do that you can actually measure that contributes to the company as a goal? So with an awareness, you know, it's sign ups and follows. Great. But we need to, you know, keep moving along where we want them what you know, what's that call to action? We want them to register.

We want them to install or try the free tool. We're looking for feedback. When they're starting to engage and learn and build, you know, we we want them to register, not just register and start something, but we you know, maybe it's a premium version or, you know, maybe we certainly wanna keep pushing them up up the chain too to to do more, to to build more, and to also pay more because, you know, most of us are are in companies. You know? And then, you know, eventually, when they start to really be, you know, liking what you're doing and building and scaling, we want their feedback.

We want them to contribute. We want them to refer. I think sometimes in developer relations, we're still in the awareness stage, and we think people are kind of interested, and we're we're hoping that they could get into this community and contribute really quickly. Gotta make sure that you're you're building them through this journey and you're sort of watching these metrics along the way. So I've listed out a number of different different metrics.

Again, they can be a little bit fluid, and they might change a little bit depending on, what your organization looks like. But you really wanna sort of build them out over time. And the one piece that's important to think about, and and Vera talked about it too, and, you know, I sort of call it transactions or it's really about that activity rate. What is it? You know, it might be a monthly active user for some companies, and that's certainly metric we see a lot of, especially in, you know, for start ups and different companies.

But for your own tool or product, you know, it might be something totally different. But, you know, you will know that based on what your what your product is. Like, how are you gonna know if somebody's active and adopting? That's sort of a really key metric that that you need to talk about. You know, is it just an API call, or is it just an SDK download?

Or is it the number of calls? Is it is it how active they are? Or is it knowing how what kind of a product that that tool has gone into and how, you know, how do you measure that and how do you get that kind of feedback? Couple slides here, on conversion. So if we look just back at this slide, you know, it's also, like, how do you know if your if your developers are are moving along the spectrum that you'd like them to?

So you need to take a look at those conversion rates. And and here's something, you know, sort of quickly, that you can take a look at where, you know, when does that subscriber become a lead? When does it become a user, an opportunity, and when does it become a customer? And when you take a look at that through the journey, you go, okay. Well, maybe we touched this many people, and then this many people signed up for the newsletter, and this many people registered, and then this many people actually integrated, you know, integrated that product.

So you can kinda see. And if you, you know, you monitor that over time, and if you find out where things are are missing, you gotta go back to the journey and go, well, you know, what isn't right that we've lost, so many as as we've moved along? This kinda goes through that same stage. But when you see it, it's like so the overall conversion rate is, you know, 2%. Is that good?

Maybe. But you'll know when you track that over time. And, also, when you put a budget towards that and go, we spent,

Speaker 2: you know,

Caroline Lewko: $3,000,000 on this big event, and we only got, you know, 2%. Maybe 2% is good for you, but but maybe it's not. But understanding where that is and how that conversion is happening is very important to track. And, again, if you go back, go, okay. Well, why did that happen?

Why aren't there enough people coming in and subscribing? Well, you know, maybe your evangelist isn't getting out there enough or you're not really getting that message honed. The hook isn't strong enough. Maybe to do a few more surveys and focus groups and some beta testers to really find out what's what's going on. You know, if they're abandoning registrations, is it is it a clunky process, or, you know, is the documentation, again, just not really convincing them that this is what they what they wanna do?

And if they haven't actually become a customer, is it it could be pricing it, you know, that whole business model. So those are things to think about, in terms of metrics along the way. Don't forget the value. So, you know, you can measure again all those activities that you're doing, and those are important to think about. But if you don't actually think about where the value is in the business of actually, you know, leading somebody to to a sale and you know, it's it's it's often debated in developer relations where, you know, we're not salespeople.

But you're part of a business, and we still need to follow the value and be very aware of what that is and how it works within the company to make sure that the program really really stays around and and and is really successful. So does everybody have a developer journey map? I'm curious. And are you leading your developers down the pathway? Have you figured out what that value is?

And let me know what I've what I've missed. I know this is a a short time to to go through a presentation and and a lot of the things to to look at. So if anybody wants to take a look at the journey and a closer look up and maybe with your reading glasses on, let me know. And always curious to know that is anything I said, can you actually use in your job tomorrow or or today? Because those of us, are still starting our starting our day, today.

Let me let me know. I really, I'm really interested in, you know, uplifting developer relations to a point where, we don't have to ask what it is anymore, and we don't have to keep asking how we measure things. We're just really familiar with it, and everybody else is familiar with it and and respected, with it with it as well. I like to always end my presentations with with our cute little robot that says the future depends on our choices. So also be very thoughtful about, you know, how you go about your your own journey in building a tech community, working with people, and the type of tech that we wanna build because it's, you know, it's all up to us.

So I'm finished on that one, so I'm gonna stop sharing my screen and come back to Tadji and see if anybody has some some questions for me. And then also, Matthew and I think we're gonna look at our as our at our survey. So any, any questions for me on on that? Hi again, Matthew.

Speaker 2: Yeah. Thank you, Caroline. It's quite a presentation. And it seems that we have no no yet no questions from Slack and lot of comments. And But, you I have I'd like to, yeah, comment to you just some Sure.

Thing. Yeah. Yeah. Actually, very I felt I felt that that's very great, therefore, your session. The your session included a kind of the everything about developer advocacy and the developer relations, I think.

So your explanation is a very, how should I say, very systematic and easy to understand

Caroline Lewko: Thank you.

Speaker 2: About the developer relations. And I think it was very helpful to the all of the audience, yeah, who wants to learn what is Deborah, what is Deborah for advocacy. I think that's so. And the yeah. I actually actually, as you explained, I I also felt the need to organize my thoughts of the difference between developer experience and the developer relations.

And you you you showed your slides for the and you figure out covering the this area is a developer experience. This area is a developer marketing. Yeah. Right? It's so it's very interesting for me because in my current work, so it sometimes feels like developer marketing and the developer experience separated completely.

So I think we are required to work seamlessly that own this border, but company organization can cannot accept to merge the each work, the the data market and the data accuracy. If you have any idea to improve this work seamlessly to for the deeper variations, Could could you please advise for me and the other audiences?

Caroline Lewko: Sure. And, you know, actually, think some of the we had a question on the developer survey that asked about how you work with other teams.

Speaker 2: Mhmm.

Caroline Lewko: And, you know, what we've seen and what the survey was saying, you've gotta have some shared goals. Mhmm. But you also kinda have to make friends, you know. Yeah. You you have you have to really, yeah, make friends so you can work with with those other people and be able to not only have shared goals, but, you know, share a lot of that information and, you know, for them to have confidence in you for what for what you can for what you can do.

Speaker 2: I see. It's right. Yeah. Exactly. It's a great idea for a work also.

Yeah. So I I'll try to do that. So and I hope the some company the some company, the CEO or CTO, you know, or the executives, Please understand they brought more detail. It it seems that they brought markets of course, the developer advocate, developer evangelist, or the developer marketer, it understand very well about the developer, executive, they cannot understand. It's hard to understand what is developer.

Right? So the I have to to well, more what's the executives, you know, can understand, you know, what is DevRel. How should it if I just how should it advocate do or execute for Deepgram? I hope so.

Caroline Lewko: Yeah. You know, I think I if we keep educating ourselves and and talking about developer relations, I think that will happen. And also just, you know, making sure everybody knows that developer relations is more about evangelists running around to events. Yeah. Because that's often how it's seen, and it it's just I mean, it's it's so much more than that.

And I think that comes back to too. It's not just about measuring how many events I went to and how many Twitter followers I have.

Speaker 2: Yeah.

Caroline Lewko: You know, how are you contributing to the business? Yeah. Right?

Speaker 2: Those kinds

Caroline Lewko: of questions are are really important, and you need to be able to speak very clearly and confidently about how that's contributing to the business.

Speaker 2: Yeah. Exactly. You're right. That we need to explain. It's how effective to our business the from the the revaluations.

That was our work. Exactly. Definitely. That's yeah.

Caroline Lewko: And, you know, we're hoping our book is going to sort of bring a lot of those thoughts together too in explaining, you know, why developers are important. How just how many companies, you know, got some DevRel component that you probably don't even think about? But also, there's a number of different ways that that, you know, the business to develop her business model works.

Speaker 2: Yeah.

Caroline Lewko: And, you know, being able to understand where the where the value comes in, and it's it's it's different for whether a company has an API or an SDK that, you know, helps with the with the device. It's it's hard to lump all those together too and just being able to understand where you fit and and being able to describe that value so everybody is, you know, on the same page, so to so to speak, within a company is is important.

Speaker 2: I see. I see. Yeah. I understand. Thank you.

So the you know, No. Actually, I hope to coming more questions from the Slack and YouTube Twitch, but no questions now. So I'd like to move to the cross your session. Thank you very much again for your great session. Thank you.

Caroline Lewko: Thanks, Ted. Nice to nice to meet you.