Visualizing DevRel scope and goals

Cherish Santoshi: DevRel gone deep dives. Yar.

Speaker 2: Thank you everyone for joining this, this talk. Whoever is watching, I'm I'm glad that you're here. I wanna talk about visualizing DevRel's scope and goals primarily for two reasons. I personally have found DevRel to be a space where there's a lot of overlaps. And when there are a lot of overlaps and you work with multiple teams and with different goals, it becomes harder to justify a vision or to dot talk directly and clearly about what you exactly do.

Right? And also depending upon the I've worked with bigger companies and smaller companies. Right? So I wanna talk about this to understand no matter which company you're working with, it still holds, you know, some relevance wherever you are. So I'll start with a little bit about myself.

So I've spent nine years in Devil now. I'm currently a developer relations engineer at AUKUS. AUKUS is, you know, a cloud based offering on Netflix Conductor. So the founding members are founding engineers of Netflix Conductor. They all came out of Netflix, and now we're building on top of it.

Recently, this year, I won the CMX developer relations professional of the year award. So thanks to everybody who voted for me, and I'm, you know, very honored to receive that award. And previous companies that I worked with are Google, Amazon, and Acrobat, right, and a few other startups. So I wanna start with just quickly telling you about the agenda. So we're gonna talk about the type of companies that we have that that can this might be useful for.

We'll also talk about visualizing the scope and developer relation functions, and we'll break down the goals based on the functions that we define. We'll also talk about very briefly about mess managing up, down, and sideways. I I think some some of that was already, you know, talked about in in great detail in the conference already. And then we'll open up for question and answers. So to begin with.

Right? So just so you know that and I'm sure, like, a lot of people, if you're here, you're already a developer relations leader. You already know that there's a developer first company, and there's a developer plus. So developer, first companies are companies whose primary focus are to create and sell products specifically for developers. So if you're creating Twilio or, you know, if you have confluence, right, Jira, things like that.

So these are primarily for developers. And if you're using, you know, let's say, an SDK or or back end service, which developers use to create something, that's developer plus. So developers act as one of the bridges that you have to cross to actually go and reach the audience that, to you know, you'll use the product. So think of it this way. Right?

Like, if you're a you're a developer first company would be a person who makes the knife. So, the chef becomes a developer. Right? So they will be using the knife. And for developer plus, the person who's eating the food made with that knife becomes developer plus.

Right? So, essentially, your food is also making impact at the latest stage, but the developer has to use it first to actually make that impact. So that's one of the things. You can see the distinct you know, the distribution developer for us are 32. One third of the company is in developer per plus or more.

So all the all the, strategies that we talk about today are going to be relevant for both of these, companies. And before we start, I also want to mention that all these opinions are just my own. And, we we always need to consider that every advice that we hear on the Internet comes with their own context. So I've tried to keep this as as broad as I can to ensure that it's not very specific on niche, and it doesn't resonate with most of you. But at the same time, it will depend a lot on the company size and what functions you perform with.

So in case you need more chitchatting around this or I wanna discuss more strategies, you know, you can reach out to me. I've I'll reach I'll send you my social details, and then, you know, we'll further take it from there. So to talk about scope, right, like, one of the things that I've noticed across working with different companies is that Devil kind of touches primarily three focus areas, this product, engineering, and marketing. So let's take an example. Right?

Let's take one, let's call our product, product ADC. Right? This is a product that a developer needs to use to actually build something, like, build probably ship out faster, reduce testing times, and so forth. So there will be a product team which will be essentially made of product managers, product marketing managers, assistant product managers, things like that. Engineering will have engineering leaders or developers, and they obviously will be marketing, which has marketing managers, social media, content, things.

Right? Now Devil will actually have will closely work with one of these three or maybe all of them. So you could be working in a company depending upon the scale and the size with all three of these verticals or just one or two of them. So considering that as a possibility, let's understand if you would work with a team that they're they you have all three of these. What is the scope?

Like, what what can Devil touch, and what can it influence? So consider this. Right? Like, let's assume all of them overlap. The the overlapping that comes out becomes three things.

Right? There's a developer experience, developer marketing, and community. Now if you notice closely, right, so there's product and engineering overlap comes out, makes developer experience. Now a developer experience as as a segment is primarily focused towards improving the customer delight of the developers. It elevates their experience directly from where they find the product all the way till they actually use it and send their NPS or feedback that I like the product or not.

So directly from the awareness, you know, all the way from awareness right at the very end where they done with the job and they can move on to the next one. How was their entire experience in their journey? Where all did they fall? Where all they found you know, their experience could have been better? Did they find the documentation on the right time or not?

And if you look at product and marketing's overlap, which is developer marketing, this is where, this is considered as like an orbit. Right? Think of it the outermost layer where, the developers need to find the product or we need to you need to be made aware of the product. A lot of developers actually speak at conferences much like myself and much like right now. Right?

We are here to actually talk about the product and the impact that it can create. Now when we talk about the product, in conferences and make people more aware to our content, to our written blogs and so forth, What we're trying to do is essentially reach out to developers who are potentially, looking for similar products or at least keep this product in their subconscious mind. So whenever they are out there looking for something similar, we are at least on their radar. Right? There's a beautiful, website here called TechReader, I think.

They have you know, they they tell you, which tool is in what radar and how many developers are considering buying that. So to reach there itself is in its own feed. Right? And this is what product and marketing overlaps into and creates developer marketing. One of the things which I'm really passionate about, and I think this is something that has caught up, like, a lot in last few years, is the community aspect of actually building things.

Especially Devil, I think the way community works in Devil and actually technical spaces is far more nuanced and far more sophisticated than, you know, a lot of other things that I've seen. The way that communities function within Devil is is astounding because not only it actually does a peer to peer learning, so there could be a developer looking for questions and there is another community person who answers it. But there are a lot of community members who will build the solutions that people like themselves or their peers are looking for. So once you reach that space, right, where it's not just peer to peer learning, but it's also bit like, peers are building for peers and they're consuming within, You reach a very holistic self sustained model. And I think from there on, you know, it's it's a very sorted and very great road ahead.

So we'll talk about all three of these a little more in detail as we go. So the first thing that I wanna talk about is developer experience. Right? And before I do that, I just wanted to tell you that considering you have all three of these verticals in your company or just one or two of them and depending where the difference sits, which role does it report to? Does it report to the CEO, CTO, marketing?

This diagram could be influenced. But assuming we wanna keep this generic and you want to work you know, there is a possibility of overtaking these goals and having the scope of actually working with all three of them, you know, we'll move forward and consider all of them individually. Now these are three functions. The one of the first function that we'll talk about is developer experience. Now we spoke about how, developer experience starts from all the way where they identify the product right at the very end, where they use the product and actually move on to the next, next step in the cycle.

So the North Star goal here is to actually, find developer delight. Right? And the reason I say North Star is that you could find x number of ways, to build goals. Right? Like, and to find ways to actually improve the customer delight.

I've mentioned few of the goals here that we focus on and you can do. But if there is anything that focuses you or directs you towards the goal where there is developer delight, I think you should consider that. One of the things that we the the, you know, most obvious thing that comes into the mind is documentation. Developers are people who like to figure out things on their own. They the first thing that they look for whenever they identify a new product to work with is documentation.

How frequent is the documentation updated? How well versed it is? Is it missing anything? Those are few things that we take care of. Now one of the things we're developer force companies or even developer plus plus companies, right, if you actually go out to them and tell them that this is this is what we have for you, what they'll do is they'll they'll talk about the infrastructure or the, you know, the stack that they're working in and then tell you that can something like this fit into whatever system that we've built.

We don't wanna change our systems or our ways just because we are using your tool. So that challenge involves building demo applications or use cases and plug ins for the developers. Now not only when you're selling. Right? Like, a lot of times, you want to ex kind of flex and showcase the reach of your product.

So building demo applications or use cases and plug ins, like no good plug ins. Right? There are a lot of ways where there is an open source version of the same product much like Auckus, and there's obviously, like, a cloud version. And there are no good plug ins for the same thing. Right?

You know, one of one of the companies that we worked with was an auth API. And auth API also had a no code plugin. Right? So depending on whichever developer you're working with, you have to make sure that you're building for them and for the ecosystem that they already operate in. Another thing that we do here very frequently is being developer zero.

Now developer zero means that before it reaches the market, before there is even the first developer that checks out your newest release or your latest, you know, latest development or update, developer relation team like, developer teams actually become developer zero and test the product in house. They share their experiences. They share their insights, and they tell what broke, where, what can be proven in terms of UI, UX functionalities, you know, performance, and so forth. And if that flies, you know, it it kind of moves on to the next phase. So the reason, like, developer z o is, like, a great segment here is that it not only acts as a QA for the product, but it also brings like, developer relations have that foresight and also the scope to understand that if it goes to the community that they've, know, usually worked very closely with, how will that be received?

And dev zeros, usually have the foresight and understanding of what were our community like, what was our community expecting with our latest release so they can also influence and check for that as well and keep the community informed. So that's one of the things that we do with developer experience. You can see the overlap is between product and engineering. Right? Similarly, the next thing was developer marketing.

So let's say you've built something. Right? Let's say you've built a tool or, like, a or you've built, like, a functionality that is ready to go ahead in the market. Now your, now the goal comes out that you want to make people aware, and we want to make sure that you're present in the conversations where people are discussing a potential use case or potential solution to what you've built. How do you do that?

One of the things very obviously would you think about social media presence and engagement. You would collaborate with a lot of people. You will release a lot of content. You'll do hackathons, meetups, and you'll create advocacy programs like, student programs, campus programs, or, meetup chapters, things like that. Anything that involves other people talking about the product or at least creating some buzz or some news around it.

Now this is something which is very easy to understand. It's an overlap between product and marketing. I'm sure this is people have been doing this for a year or, like, for for years. Right? And the reason Devil also can touch upon this is that the way that, like, Devil's will explain something kind of sits closer to what developers would want.

And I think they can sense the sense the terminology, sense the compassion, empathy that Devil's put in that in actually releasing beautiful content, something which is easier to understand, something which is easier to work with. So Devil's can also touch a lot of these goals. Right? And the not so goal, like I said, is the awareness and presence. If you can find more goals, I would love to know what those are.

You know, anything that can create the virality of what you're doing, it could be any sense. A lot of people kind of consider GitHub Stars as developer marketing metric. Now that's that could work for some of you. But yes. So these are a few goals that I I kind of be heed to whenever I'm thinking about developer marketing.

And the last one as we saw was community management. Right? So this is like an overlap between engineering and marketing. The reason, like, community management has, like, engineering aspect is because for you know, this there is something about engineers explaining to other engineers that is something irreplaceable. Right?

And North Star goal here is to not like we spoke about before, was not only to instill peer to peer learning, but also find ways that your community quest community has self sustaining models. Right? So somebody asks a question within the com within the community and gets answers immediately from other community members. So community generated content becomes, like, third of like, the hardest to achieve, but also the most is the gold standard. It's the, like, the last mile, so to say, right, of any of community actually caring about the product and caring about people who are using product.

And content could be anything. It's not necessarily videos and con videos and, you know, audio podcasts and things like that, but also simple answers like this is what you can do. Right? One of the things that we do is that in developer marketing, you saw that we have written audio video. Right?

So we do a lot of podcast. We also do YouTube videos. We do meetups. And community, you can also use your community management users, find these people who have been strongly advocating about your product and answering a lot of questions and use them for developer marketing to actually talk about their experiences, their ways of solving issues, and take them on your podcast, take them on your YouTube videos, and, use the and make a star out of your community. Because not only do it rewards their loyalty and the time that they spend on your product, but it also makes them a better leader, a better communicator, and potentially a devil.

Right? Like, who knows? Maybe they like doing this so much that they eventually change their path. And I think you can, you know, you can be a pivotal point in that in their journey if they pursue that path. You also, as a in community management, find ways to support onboarding issues and also working issues.

A lot of people use Discord, Slack, and Discourse or, you know, whatnot to actually find these questions and get these answered. And that's that's a great channel to actually build feedback channels as well. For me, personally, I think one of the gold standards of actually building a product with community is where not only community uses your product, but it also influences it. Right? So a community community led product would be such that community has an idea of where the product is headed.

They're not only involved in the decision making process or, like and also, like you know, they also find a way to actually plan their releases or plan their upcoming near future based on the product that you've built that they're working with, and that case could be yours. Right? Community led products. So comes with the philosophy that imagine if you're if you're a Chelsea fan. Right?

If you're into football, let's say you're a Chelsea fan, and there is Chelsea says that, you know, for this season, we want you to design our jersey. Right? And if you actually take out the time and design a jersey and that gets selected and they wear it throughout the season or for one match, whatever, the level of ownership or the level of you know, you're hooked into their success. You're invested now because your hard work and your your insights and your, you know, your whatever you've built with, right, it's not only was paid attention to, but it was actually implemented. And that creates a little bit of investment in their success.

They root for you. They become your fans, and, you know, they have they wish for a prolonged success because they feel connected to the cause. That's one of the ways that I think community can not only use the product, but also influence and build with it. That can only happen if there is a feedback channel open. And feedback channels need to be open to, you know, Discord, Slack, or whoever, and you need to take time to actually do community calls, roundtables to understand where this is headed.

Right? It takes time to build, but it's definitely worth it. And I think it's one of the hardest schools to achieve, but definitely, you know, one of the most rewarding and fulfilling ones for both the parties, the businesses as well as the community members. So that's something that we can do in community management. The last thing that I wanna talk about, right, is managing up, down, and sideways.

So a lot of these things will kind of boil down to two things. One is that you have to get buy ins from the stakeholders that you're working with. Now we saw that commune you know, Devon is working with engineering product and, you know, and marketing, which involves a lot of stakeholders, which involves a lot of binds, which involves fight finding budgets and then allocating them where and however there could be overlaps. Right? So one of the metric that one of the ways that a lot of people can actually segregate their their stakeholders is this.

Right? So you can see that on the y axis, there is influence of the stakeholders, and and the x, there is interest of the stakeholders. So you can block you can find under which department where they work and kind of assign them something. Right? So if they have high influence and high interest, you they they keep that.

They don't not only interested in what you're doing, they can also fund it or get things done for you and make sure that there are there are no road roadblocks. So have to manage them very closely. People with high interest but very little interest sorry. High influence and very little interest, They are obviously on the table because they have high influence, and they can, know, make things go your way if their goals are met. So one of the things that you can do when you're looking actually building something like this is reach out to the departments that you'll be working with, identify stakeholders.

Right? Identify their overlaps, and then understand what are these overlaps that you can be working with. So you you work with product team. Speak to the head of product or chief product officer or product managers, understand what their goals are, understand what can be built here, and then call them back to the diagram that we have. Right?

Three walls well band diagram. And then once we've that, we can allocate those allocate these stakeholders here. Now repeat this process with marketing as well as engineering. And once you have, like, goals from all three of them, it's very easy to create kind of create something like this. Because not only will you have the insight into leaders from product engineering marketing, but you'll also have insights into what goals matter to them.

What are their priority wise? What is something that they are looking maximum budget to? What are some things that they're always hiring for? What are few things that they need help on? Right?

And once you find these things, right, once you find the overlaps between all all of these things, you could say, here is what I've heard from all all of you. Here are the overlaps that I found. I'm gonna kind of work with all of these overlaps that I have. Here are here's the budget that I require for it. Here are the people that I need to hire.

And once that is done, it's becomes easier to kind of get their buy ins and get their budget approved. Because they understand the overlap, and I'm sure, like, your communication would actually ensure you know, they they they not only, you know, actually buying your opinions, but they actually invested in it. Right? And you can see where they stand based on the metric that we have here. Once that's taken care of, I think it becomes, like, an easier road to walk.

And from there on, you know, it's it's it's fairly easy to kind of get your goals met. That's all I think that I had to talk about. Right? Like, those those are a few things that I wanted to discuss. If you have further questions, right, you can reach out to me on Twitter or LinkedIn.

And I'm sure, like, there are further quest like, there are further conversations I can try from here. I would love to know how many people actually use this kind of model already or how many people just work with the only engineering or or only product or marketing and then understand how do you guys manage this. But I hope this there was something to take away from all for all of you. But and if case, you know, there is something that you would like to discuss or disagree upon, happy to get in touch on Twitter as well as LinkedIn. That's all that I had to say, Mantle, over to you, and I'm open for questions.

Cherish Santoshi: Hey. Thank you very much, Jerish. Great to hear from you there. I guess the first thing that comes to my mind is that developer relations seems to be having a moment of growth in India right now. What are you tending to see amongst companies who are practicing DevRel in India in terms of interacting with the rest of the organization?

Speaker 2: So one of the questions that I ask whenever I interview is that if you were a DevRel before, whom did you report to? If you were reporting to marketing, if you were reporting to CTOs, if you were reporting to CEOs. What that tells me is that their goals would have been, either very product oriented, either very engineering oriented, or either very marketing oriented. So and this is this is one of the reason why Devil is you know, get gets a bad rep in explaining, that we don't know what you're doing because there is such an overlap, and a person who's working Devil could be working with engineering leaders, product leaders, or marketing leaders that their goals could be very different. They could just be creating content or they could just be creating sample apps.

And both of these kind of seem like opposite end of the spectrum. But if you visualize it this way that all of there's an overlap for all of these things, and this is where kind of level fits in, it's great. In Indian ecosystem, I think and it's because founders are fairly new to this concept, so they haven't accustomed this. Right? And, Matt, we did, like, this conversation during last of our in one of our conversations where we did devil for startups.

Right? Where a lot of devils kind of have just a lot of startups have picked up devils, and how are they managing it based on their growth, like you mentioned. What is their seed stage? What is their funding stage? And how do they allocate this?

So so long story short, I think the way Indian ecosystem is functioning is dependent upon their funding stage. It depend it depends upon their how well was or how big their product engineering and marketing teams are. And if if they seem self sufficient, they don't hire Devils. Whatever seems to be lacking, Devils are usually allocated there.

Speaker 3: Thinking about you know, you were talking about product engineering and marketing and the overlaps, and you touched upon it a little bit just now as well. So you had your you had your diagram with the three circles and you showed where the overlaps are and then what happens in those overlaps. And in the middle, there was big overlap between all three.

Speaker 2: Yeah.

Speaker 3: Who do you who do you think sits in that in that intersection between all three and what do they do? There there isn't necessarily an answer to that, but I'm just curious because that one didn't have a label on the diagram, and I'm always a bit curious about something that isn't pointed out.

Speaker 2: Oh, I'm very glad you asked that question. One of the reason I didn't label it to actually see if now somebody notices that. So glad I didn't so glad that worked. That central system is where the leaders of dev will sit. So it could be head of community, head of developer relations, whoever the person whoever manage the devils, they have visibility into all three of them, and they own these things.

That's not a function state. That's a person state. Right? So they it belongs to an individual, not necessarily a function like marketing developer marketing or community management.

Speaker 3: Do you think that it is realistic for one person to hold that whole whole portfolio, or do you think it should be split out between different people?

Speaker 2: It should definitely be split across different people. But I do feel the visibility and the the ownership of explaining the difference comes to one person. And it will. Right? Like, those the organizations are structured that way that hierarchy right?

Like, it's just going to be a pyramid. So they could be one VP of Devil, you or they could be one head of Devil. So it becomes their onus to find these overlaps and allocate teams here. And it's a difficult it's far more nuanced than that. Like, it's an easy question to ask, but it's slightly different to answer sometimes because, you would want people and you would want teams for all three overlaps, but it kind of depends what is the stage of the company, how many people you've hired, or or are there people already hired for doing this who are not necessarily into level.

So it becomes harder that way, and this is why I think the education at founder stage or investor stage kind of comes into play. And just now, Matthew was talking about somebody, about how, you know, like, CEOs care about Devil or what do they think of it or investors think about Devil. I think, educating upstream is also, our onus, and we should do that too.

Speaker 3: Yeah. That brings me on to my next question, So you showed, you showed us how we could do a stakeholder analysis and that is something that I've done probably hundreds of times in my career because I used to work in marketing for quite a long time. So anyone who's worked in marketing or some sort of business strategy roles, and this is Matthew, you've probably done thousands of them as well. So you look at the two axes. It's generally something along the lines of in influence versus interest or support.

And you had in your high influence and low interest meet their needs. Now where I've I've worked previously in organizations, not necessarily in a Deborah function, more in a marketing and communications function, where I'm trying to win hearts and minds of tens of thousands of users. So I used to work for the police. We have 50,000 users. We've we've tried to roll out a new piece of technology, and we'd need senior buy in.

And as you can imagine in the police, the at the executive level, they have a lot of things to worry about. So there could be something that they don't know about today that could happen this afternoon that just throws everything out the window. And your project is very low on their list of priorities. Or they don't necessarily understand what you're doing and they don't see the value of it. So that's why their interest is low.

But they have a high influence. So they could very easily sabotage your project or accidentally, not bad mouth it, but accidentally play it down where you really need them to give you that support. So as opposed to leaving people in that quadrant, I would suggest you really need to move those high influence people to the right, the top right. How would you recommend we move people with high influence from low interest to high interest?

Speaker 2: Fair enough. That's good good question. So so to summarize the question, you're saying there are people with high influence but very little interest. We wanna move them towards not only high interest to high interest and high influence, right, and high interest rate. Yeah.

I I personally don't think that's well, like, that's gonna be possible 100% of the time, because there'll be people who will have less interest in your projects. And, I I don't know. I feel like that the entire organization getting both my goals and not only have that influence to support it, but also interest in whether I'm meeting my goals is a little too ambitious. Right? I mean, not necessarily will they care about what Cherish is doing and and how he's turning things.

Right? Not everybody would dare, but to to credit where it's you, it's it's a nice approach. Like, it's where what maybe we should be headed. Not all move people with high interest. Here is what I would do.

I would understand their best case scenario, realistic case scenario, and worst case scenario. So you said that if there is something that happens, immediately worst case scenario hits, they'll push the brakes, they'll probably bad mouth, or they'll probably say something which will stop everything. Right? Now here's the thing. The first thing that I will do for anybody with high interest or high influence is that I will make sure there is not there are x number of ways, plan a, b, c, d, to avoid the worst case from happening.

Right? So I will tell so I will talk about what are your worst fears. And I'll make sure I do not create any plans which can even remotely lead to that. Right? Because if there is a high influence person and their worst fears come to true, it's forget about funding the project while your job's on the line.

You know? And the next thing is what is the realistic case scenario? Then I'll have and and I'll be like, if I I plan towards the best case scenario towards a person with high influence, do I have the bandwidth? Do I have the capacity? Do I have the team budgets and, you know, people to do that?

If so, I will aim for pleasing them the most. But if I can't, I will probably land up to the realistic case scenario. But the so this is I mean, this is more of a risk mitigation scenario as opposed to a stakeholder issue, in my opinion, because there'd always be stakeholders who will not have a lot of interest in what you do, yet they will hold a lot of interest or influence. Sorry.

Speaker 3: Yeah. I think it's like any sort of influencing strategy that you're trying to do. You have to find out what the the person cares about and really key into that. And hand in hand with what they care about is not It's not always what they love is what they care about. People also care about what they're scared of, like you said.

Exactly. Yeah. Finding out what they love and what really strikes the fear of God into them is really important.

Speaker 2: Yeah. I I agree. That that's beautifully put. And and I think one of the things that I should all you should always try, like, always look closely for is what is their motivation, what is their feel, what is something that they're running towards, and what is something that they're running from. Right?

So if if wherever you can increase the gap or decrease the gap, if there you could decrease the gap towards where they're headed, and you can increase the gap from what they're running from. You can always do that. If not this, then that. And understanding that not only helps you hire better, but also manage your stakeholders a little better.

Speaker 3: Yeah. And it what's also really hard and challenging sometimes is if you don't have that high interest, so you could really understand that person really well, but their interest is so low, they may not even think that they need to give you an audience. They might not even think they need to to come to that meeting with you, so you can actually put these things to them. So even just getting that that time with them to get across what you wanna get across can be really hard if their interest is so low.

Speaker 2: I agree. I agree. So I I wanna share a quick story with this. Right? And I'll end up end with the quote here.

So this happened with me in early, my early twenties. I was trying to push, like, a product that I had built, and I had to go through 13 revisions of the same PRD that I built. I got really frustrated saying that I'm trying to improve something, but not only I'm, you know, only I'm given with a lot of roadblocks, but I'm deterred from this. Initially, it bothered me, but now I understand why they did it. Then somebody told me that there was a Gandhi's Mahabha Gandhi's quote.

He used to say, first, they mock you, then they fight you, then they join you, and then you win. So it's it's gonna be like that. They'll probably ignore you. First, they ignore you, then they mock you, then they fight you, then you win. So ignoring, mocking, fighting, and winning.

So if they're ignoring you, you're on the first stage.

Cherish Santoshi: Well, look. It it that's probably a good time to wrap up because, we are coming to the end of our our slot here. So, Therese, thank you very much. Where can people find you on the Internet? You did mention earlier, but give us a refresher.

Speaker 2: Sure. So you can find me on Twitter. My name is. My you can find me on LinkedIn, is also. Simple names, no hyphens, no aliases, just like that.

You can find wherever, and I would love to have discussions more around this.

Cherish Santoshi: DevRel gone deep dives. Yar.