Importance of Collaboration: Effective collaboration between Customer Success (CS) and Developer Relations (DevRel) teams is crucial. These teams share common goals, such as improving the developer experience and delivering value to users, but often work in silos. Regular meetings and shared resources help bridge this gap.
Resource Accessibility: A shared knowledge base, documentation, and resource accessibility across teams help in creating a unified experience for developers and customers. DevRel teams benefit from accessing CS documentation and feedback, which can inform community engagement strategies.
Functional Overlap: Both CS and DevRel teams share responsibilities like educating and advocating for customers but differ in their methods and scope. While CS focuses on retention and managing relationships with current users, DevRel emphasizes broader community engagement and advocacy.
Role and Metric Differences: DevRel teams are measured by community engagement and product advocacy, while CS teams focus on retention and expansion metrics. Aligning these metrics can foster mutual understanding of each team's impact on the business.
Challenges with Documentation and Communication: Role confusion and different access to tools (e.g., CRM) can create friction. Aligning on where content belongs (knowledge base vs. docs) and avoiding duplication are essential for a consistent user experience.
(00:00) all right well I hope everyone had a great lunch um hopefully you also had some caffeine because we are going to dig into some a fun topic here before I do uh dive in I want to get a sense of how many people in the room here uh currently interact with your customer success team so no judgments uh raise your hand if you have interacted with your customer success team in the last month okay okay how about in the last week all right excellent I see a lot of activity there in the Middle with the tables they're they're ready to learn so
(00:32) yeah and it's so I'm here today to talk to you about why it is important for you to be interacting with your customer success team and how you can do that more effectively not just to drive forward business goals but also to help the developers that are using your your tool so I'm going to start with a story I joined the ionic developer relations team in 2022 and I came on to support specifically the appflow product line so if you're not familiar with appflow it's the mobile cicd um platform built by
(01:03) ionic and up until the point that I joined it was only available as a paid service for Ionic applications I was brought in because they had added were adding support for react native um Native Android and Native iOS and we're also in the process of introducing a free tier to support adoption in these new markets so a lot needed to be done in order to determine how we could meet the needs of these new developers so one of the things that that I did was a really comprehensive audit of our documentation and our resources and we
(01:35) needed to make sure that a developer coming in who was not familiar with the existing ionic ecosystem would be able to get up and running without the help of a support team and I was going through our documentation and I saw like a random note on a random page and it said you know if you have this type of configuration you know click here for more details something like that and I clicked on it and it took me to this beautiful knowledge base that I had no idea existed it had troubleshooting guides it had onboarding resources it
(02:09) had you know detailed information about the different plans and features it even had architectural diagrams for how appflow worked and how the stages that your app went through throughout the build and deploy process and none of this was in our documentation or visible via our documentation aside from three random links scattered throughout our Docs and from my understanding it was not being leveraged by other teams so as you can probably guess this was created by our customer success team this knowledge base and it was really only
(02:39) provided to users via that channel so if they had a customer success uh manager or if they interacted with our support team you know they that that team would send them a link and say hey check out our knowledge base like this is a common issue now this actually reminded me of a similar scenarios that I ran into years earlier when I worked at Cypress on the the other side on success teams so I joined Cyprus in 2020 I was the first hire on our success team as a customer success engineer and by the time that I
(03:13) left Cyprus two years later I was a technical account manager and we went from a team of one to a team of about eight people and we had brought in a success director and implemented a lot more formal processes and over that time we had the same issue where we started to become much more siloed with the resources that we were Crea creting when I started I was contributing directly to our docs I was doing the PRS I was handling all of that then we introduced zendesk so we started creating saved replies to Common
(03:40) support requests in zenes that turned into zenes knowledge articles we also created a document that had a list of common blog posts and resources that we would refer to based on topics that could come up during success calls and again we had all this information in these resources that were being independently maintained by all these different teams without collaboration across each other so this isn't something that just happens at companies that I work for it's you know a lack of cohesion between customer success and
(04:12) developer relations not just when it regards to resources but in other areas as well is something that's not really a unique issue it's something that can happen at a lot of companies So today we're going to dive into a little bit more about how customer success teams and developer relations teams are similar how they're different and how you can better interact between those two teams so a little bit more about me first as I mentioned I worked in customer success at Cyprus uh for two years previous to that I worked as a
(04:43) software developer primarily with angular and rack native applications uh before I got into Tech I actually has Al also worked in journalism and in financial services as a licensed investment adviser so the talk earlier by Mike Swift about the financial Concepts was like spoton like that was great I super enjoyed that um I then went into developer relations I've been at companies like replay ionic and I'm now a lead developer Advocate at out systems which I joined um when out systems acquired ionic last
(05:15) year in addition to my work in those areas I love developer communities I run two meetup groups in Atlanta the first is Atlanta JavaScript we host monthly meetups with technical speakers and code jams and I also am the chapter ahead for out in Tech supports the lgbtq plus community in Tech please feel free to connect with me on any of these platforms I'm at Cecilia creates on everything and I will be sharing these slides after as well so let's talk a little bit about what really unites customer success and devil so in the
(05:48) stories that I was telling like the teams customer success teams didn't create those independent resources developer relations team didn't create their own independent resources because they like wanted control or didn't like communic ating it's because at their heart they really care about developers so they saw a need they saw they had received a question the answer didn't exist or that need wasn't being met and so they created that resource right and that's something that really unites both
(06:14) of these teams is that they really do care about the developer experience and ensuring that the developers are getting value from interacting with your product or platform the other thing that unites them is that they're not sales and so that's something where a lot of like developer relations really don't and also in the customer success side too don't necessarily like being associated with sales or revenue and they may both have Revenue impacting goals but it does allow them to create a buffer with
(06:43) talking with customers that says hey you know I'm not trying to sell you anything I can really focus on value and making sure that you're getting the most out of your product so that's something else where they're very similar and another thing area where they're similar is their skill sets that they have so this is from the state of developer relations survey highly recommend that you fill that out if you haven't this is from last year and so I'm one of the 4.8% or 5% of people who
(07:11) went from customer success into developer relations it's not a huge percentage but it is like the fourth most common uh role and it does highlight that there are some transferable skills between these two teams all right so what is customer success so customer success involves a lot of different um responsibilities right so on this slide here we see onboarding educating adoption value delivery customer advocacy proactive engagement customer support as well as some Revenue based metrics such as ensuring retention and
(07:45) making sure customers stay on and don't churn as well as expansion metrics around upselling or cross- selling to existing users now you probably see some words that kind of like pop out that look similar to developer relations as well so we see educating we see advocacy we see proactive engagement and that does create some functional overlap sorry there it goes okay so here's some areas where there's functional overlap between these two teams the first is direct engagement like we are in the trenches talking to
(08:17) developers face Toof face or via video calls or Zoom or in our different Community channels and getting a sense of how they're using your platform in the real world that's something that's really that that's consistent across both team we're having this direct engagement with them because we need to identify what their needs are their use cases any challenges that they are facing in order to take that feedback internally and solve those problems we then can do that via sharing resources whether it's on
(08:45) devil creating resources and customer success creates resources as well or taking that feedback into other teams like product if there needs to be a change to any product or processes the last one is advocacy and that's something that can be very cross functional across different types of teams and it looks different depending on what team that you're in um it also depends on the the amount of access that you have to the users and the access type is different across the teams you're the type of people that customer
(09:15) success is talking to may be different than the type of people that Deval is talking to and that's something that you also need to take into consideration when how you're able to form your arguments and advocate for your users across different teams we also have some shared challenges um one is that you have a lot of responsibilities you saw that list of what customer success responsibilities look like if you imagine a devell responsibilities this is like a long-standing thing that we know devil includes a lot of different things and
(09:45) it can look very different from company to company one that's the same thing with customer success a customer success manager at one company may do very different things than a customer success manager at a different company some of them may be more technical some of them may be more relationship driven and that is very similar as we know in Deo a developer Advocate at one company may look completely different than another company so that's something that we also have in common and that it's really hard
(10:12) to Define what we do and to explain it not only internally but to end users as a customer success manager a lot of times I would reach out to somebody and they'd be like wait like I already have like my sales guy like or you know my salesperson my account executive and I also have a support email so what are you like what are you here for like what are you doing and sometimes I think in developer relations there's also that confusion around why are we interacting with the user what is our role and that can create some some
(10:42) conflict in how we communicate another shared challenge is because of that role confusion um we also have to be really highly cross functional so customer success typically follows what's called a spoken wheel model where the user is is meant to interact with you as the spoke and then you are kind of the Hub that goes and connects to all the different other teams in developer relations it's a little bit different in that you don't have a single point of contact you're more casting a wide net
(11:11) but then you also have to take that and interact with a lot of different different parts of your company because we're both so highly cross functional I believe that's one of the reasons why we don't collaborate as well as we should because we're too busy collaborating with everybody else and serving those cross functional roles so those are some of the ways that we're um similar let's talk about how we are different so there's a lot of different areas that where we operate um independently and one of those is the
(11:44) depending on where we are in the funnel so we talked about the marketing funnel yesterday it came up in one of the talks people are familiar with it customer success teams typically work at the bottom of the funnel they're working with established accounts uh with existing C customers typically in some cases also Enterprise customers customers that qualify to have a success manager so they are really focused on working um at in that stage where they're focused on retention and then also expansion driving loyalty and
(12:14) advocacy across their users for Devo this is going to vary I have a really big Aster where I say generally because it will depend a lot on what part of the funnel you're working on I say generally top of funnel um but we know you could be working anywhere across that funnel depending on if you're more DX if you're more in um in driving advocacy if you are creating um like devel like um if you're more like a DX role you may be more further down the funnel but typically you're not only working with
(12:44) bottom of funnel users and so that means that you have different priorities and that means that we also have different metrics so with success teams their metrics as I mentioned are related to retention and expansion so these looks like things like turn rate and net dollar retention on the devil side again it varies widely but we're talking about awareness metrics such as you know reach or engagement growth metrics such as new users or active users as well as activation metrics meaning that you've interacted with the developer journey in
(13:17) some way whether it's a defined point where you've created an account um you've you know downloaded the SDK you've done a certain type of build uh if you are interested in learning more about these metrics uh you can visit the URL that's on the screen um there's a blog post that I wrote called the devil guide to business jargon that explains a lot of these different acronyms and me and metrics and what they mean so because we have different uh metrics and because we are working with different customers along the funnel we
(13:45) also have different approaches to how we work with our users so success teams are very pragmatic and solution oriented devil teams are more focused on Innovation and exploring possibilities I kind of think of this as depth versus breadth so success teams are diving really deep with a subset of their customers that they are personally responsible for and need establish a ongoing relationship and solving their specific use cases developer relations is casting a very wide net where working with massive communities where we may
(14:17) interact with some people more than others but we're also focused on what are the potential use cases what are the potential problems that we can solve and not necessarily focus on like such a a small lens and the reason another thing about success teams is their approach tends to be a lot less risk tolerant so uh success teams can be really risk averse because they have so much responsibility for the happiness of their users which means that they may be less likely to do things like hey like promote your our
(14:48) webinar to your existing to your customer base um if it's not something that they think will provide value or they may be reluctant to have them sign up for like an experimental new feature if they think it may cause issues for their their application and production and so success teams are are you know risk tolerant because they also have to deal with things like this um this is a meme that I've seen like a bunch of times but it's uh person in the front me collecting my commission in the back there's a giant explosion and it's the
(15:16) deal I just passed off to the success team so again I have nothing against salespeople I I love them but you know there has been times where you have success teams will inherit something where customers maybe don't have the right expectations around what the product can do or they may have bought a solution and their entire team is not on board or wants to use that solution and they have to be very real world solution oriented in order to get past that and make sure that client will stay on and renew once the renewal period is
(15:48) up and the other side of that though is they are really really open to things that will solve their customers problems so if there is a solution that devell can provide or a source that we can provide or even like a special office hours or webinar that we can use they will really jump on that opportunity for collaboration so let's talk about collaboration um so customer success and devell you know should be working together and it's something that going back to the story at the beginning around the documentation knowledge base
(16:22) that I found when I was going through the doc audit at ionic so luckily we had a really good process where every single Monday customer success product and myself uh representing devell for appf flow would have a call every Monday where we' go through the previous weeks you know uh issues that came up via support any upcoming product releases and then myself with any Community feedback or things that I had found in order for us to make sure that we are aligned especially given that we are having this brand new massive launch so
(16:53) because we already had that meeting scheduled I didn't have to wait very long to bring up the hey what's this knowledge based uh question and we were able to collaborate immediately and identify not only who was the owner for that but discuss you know are there blockers to customer success contributing directly to our documentation is there something that should live in our docs versus the knowledge base or this is a really great resource how can we improve visibility so everybody can benefit from it all of
(17:22) our users not just the people who are in your book of business now you don't necessarily have to have a weekly call with your C and that may not be realistic for a lot of the teams that are here but that's an example of how because we already had that Cadence we were able to work together to address that issue that came up a couple of disclaimers uh so your mileage may vary on some of these suggestions right I'm speaking from my experience working um with teams where the success teams and the devil teams
(17:52) are both highly technical that may vary depending on what company you're at these are also developer first companies where developers are are a priority and that's already inherent into the culture of our company and also it'll depend on their company size and what teams your your um what business units those teams report to sometimes success is its own function sometimes it's success in sales group together Deo obviously can report anywhere from marketing to product to its own function so that may also limit your ability to
(18:23) have some additional collaboration so the first thing that you're going to want to do is talk about go alignment right so identify the areas of overlap where you both can be successful this is going to look like developer enablement having cohesive resources how you route feedback to other teams and also cultivating Champions across not just your community but your customers so identifying who are your ambassadors who are your MVPs how can we get those really U powerful users from customer success they're
(18:54) talking to all the time and make that more visible in your developer relations efforts now you don't have to overlap on everything each team is specialized for a reason and you're going to want to be able to have those clear delineations on what makes sense for which teams to own what again go back to that breadth versus depth model so if you are examining an initiative maybe it's something like a specific webinar that you'd like to do or documentation updates any kind of problem that arises think is this something that impacts a
(19:27) specific subset of customers or is this something that would impact all of our users across the board and that was where you can get an indication of what team it makes sense to be accountable for that initiative and you know you want to have separation essentially by your core competencies as well so it's not just the impact but also which team is more um is more specifically skilled to handle this this initiative and then you want to identify areas of collaboration obviously so these are some ones that I've seen that
(20:00) work really well uh devil account enablement so what that looks like is customer success identifying an account where there is a developer need or potential challenge related to a renewal or an expansion the customer success person is not always talking to the developers in fact usually they're not usually an account manager their point of contact is like whoever purchased the product so it could be a VP of engineering it could be a CTA it's likely not necessarily the person who's actually using your tool and
(20:33) they're going to have very different goals so they may do their um their quarterly Business review and say Hey you know you're delivering five times a week you have um you haven't had an outage then they're really excited but it turns out there's a DX issue with the developers that they that hasn't been raised and that's causing a lot of friction that when renewal time comes you may not be aware of that's something where devell can step in and work with the customer success ESS team in order
(20:59) to enable that account from the developer perspective and sometimes it's also just nice because developers like to have that relationship where they feel like they're being catered to from a developer to developer um method and so that also can just kind of help with with those situations there's documentation management so establishing what processes that you have for up updating documentation one of the things that we did do was give C more of our customer success team who felt comfortable with it access to the get repo to just push
(21:30) doc updates um because there were some things that did make sense to live in the docs versus the knowledge base and that way we weren't um duplicating efforts there or that we were able to D duplicate efforts another is content topics you know we're always looking for things that are going to be helpful and enable our developers and chances are your success team has a big list of things that they get asked they don't have anything to point to and a unified process for feedback now a lot of times what happens is each
(21:57) team individually is kind of pitching feedback over to the product team whether it be from spec like either like uh support tickets there may be a tool that you use we may have GitHub issues on the community side and we don't always have visibility into what the other team is submitting now ultimately it's products you know kind of area to digest all of that and make decisions however it's helpful for us to be able to have that context so if I see something that's popping up a lot in a community forum and it turns out that
(22:28) it's already been solved but we just don't know that because Enterprise support always takes care of it we're kind of able to have better visibility to identify those issues and the last one is product use case and integration validation so when I worked on customer success one thing I ran into a lot is customers want to do really weird things with your tool like and the customer is always right like you like yeah so Cyprus is a JavaScript testing framework but it's also a browser automation tool and that means
(22:59) made customers want to do really weird browser automation things with it and as a customer success manager you get ask hey can I do this or can I use that for this or I have this other really random problem that has nothing to do with testing maybe cypers can do that and a lot of times with customer success because we want to need to balance being risk averse with keeping the customer happy uh you have to do a lot of kind of tiptoeing around it or technical validation on your own and that's something where we would turn to the DX
(23:26) team and say hey like there's this really weird use case like what is like what what do we say for that and they would you know validate it they'd find a solution and we'd be able to create a new resource around that and answer that question and say actually you don't want to do that because of this and here's something we can point to and if we need to we can bring in the engineer to explain why and that was something that was really valuable for us in maintaining those positive relationships
(23:51) on the developer relations side too you can again you create some really cool new content on the different use cases and different Integrations that are possible and you can use that when marketing to new users so ultimately the important thing is to ensure that you do start that conversation those of you who like didn't raise your hand in the beginning if it's been more than a month since talking to your customer success team I encourage you to reach out and just start a conversation understand what their goals are and what their
(24:16) current initiatives are and if there is overlap because you really do have a lot more in common than you think and you know if anything you can bondge over the fact that at least you're not sales so all right thank you so much thank you thank you Cecilia questions yes we have one okay renda's got you be right there um thanks that was a very entertaining and informative discussion on the role of Cs and its alignment with deel I think that's not talked about often in some sense so like you know we're kind of marketing adjacent a lot
(25:01) of the times so this is this is very helpful um the question is around processes for interacting with cs so you mentioned that in this example you had a Monday meeting and you clearly kind of gave the caveat of the mileage varying so what about situations where let's say devil is one or two and your Cs and customers are in the hundreds so it's not even a 1 to 10 or a onetoone you know relationship like have you dealt with things like that have you thought about that like what's what's a good uh
(25:30) sort of thought process for that yeah absolutely so actually I'm currently at a much larger company because we got Acquired and that's something that I'm navigating right now so I'm very used to being able to just like reach out to somebody and say hey and and so what we're kind of getting in the processes now is having a point person like somebody that we are able to collaborate with um we also do have access to kind of a the way that they do things is we have like a a team slack Channel like a
(25:57) public slack Channel um where the public select channel will post things like updates or a way places where we can ask questions that's independent of their internal discussions so we do also have that as a method in order to um keep up to date but then also ask questions as they arise but we have been trying to get better about establishing like a representative kind of going back to like the Game of Thrones thing like you know like you're your person who goes first and negotiates in order to and having them schedule like on a you know
(26:26) monthly by- monthly quarterly basis whatever makes sense depending on the scale and the speed of your initiatives in order to establish that contact because that's something that is also new to me at a bigger company one in the back thank you rendo hi um thank you so much for the talk it was super relevant to some conversations I'm having internally right now so I appreciate it a lot so thank you um in the talk you sort of talked about discussions you've had um with the the csms about generally like
(27:04) dding efforts um uh if you're sharing content between a knowledge base and documentation um and that's sort of a specific area I've found myself in a lot um of of talking about that D duping effort I'm curious if you have suggestions on specifically like navigating the conversation of where content belongs whether it's in like a knowledge system or docs and how you sort of align with the other team on on like the best home for a specific piece of content or content that addresses a specific need yeah that's really great
(27:41) question and when I talk about this I don't want to make it sound like you shouldn't have separate knowledge repositories like it does make sense for there to be a knowledge base that's more focused on support and um and you know Enterprise use cases than it does to have documentation that's designed for every to be able to get on board and that's also very different than product marketing right which creates resources that are designed for purchasers and decision makers um another issue that
(28:08) can come up with this is also that the fact that all these teams may use different tools and you may not have access to those tools like I with the example I gave was GitHub access but we also may have like you know for example CRM like Devil we don't have access to the CRM and that's something that can create friction not only with resources but just understanding who the users are and so initiating that conversation I think is if when you identify the things that don't make sense and starting from
(28:35) there so I I wouldn't come at it and saying hey like we need to like be on top of everything and be harmonious and use one platform for everything because I think especially at larger organizations that's just not going to make sense but doing a review and identifying things that were that don't make sense so when we review the knowledge base for example a lot of it did make sense but there were some things that were hey this should really in the docs because it applies to everyone so if you are seeing that where
(29:02) you see hey there's a duplication of resources here we're updating things separately and one is accurate and one is not and customers are finding the inaccurate one because they search for it and that's the one that pops up first on Google then those are the issues where you can start the conversation because it's a Concrete real issue for both teams and that's a good way to initiate hey okay what do we need to fix in order to solve this problem and then build out the process from there I love that answer thank you any other
(29:38) questions okay let's put our hands together for Cecilia thank you yes thank you so much
