Lead Developer Advocate
OutSystems
DevRelCon New York 2024
Cecelia: Alright, well I hope everyone had a great lunch. Hopefully you also had some caffeine because we are going to dig into a fun topic here. Before I do dive in, I want to get a sense of how many people in the room here currently interact with your customer success team? So no judgments. Raise your hand if you have interacted with your customer success team in the last month. Okay.
Okay. How about in the last week? Alright, excellent. I see a lot of activity there in the middle with the tables there, they’re ready to learn. Yeah. 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 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 app flow product line. So if you’re not familiar with App Flow, it’s the mobile CI/CD platform built by 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 were adding support for React 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 I did was a really comprehensive audit of our documentation and our resources, and we 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 a random note on a random page and it said, if you have this type of configuration, 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 had detailed information about the different plans and features. It even had architectural diagrams for how app flow 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 provided to users via that channel.
So if they had a customer success manager or if they interacted with our support team, that team would send them a link and say, Hey, check out our knowledge base. 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 other side on success teams.
So I joined Cypress in 2020. I was the first hire on our success team as a customer success engineer. And the time that I left Cypress 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 creating.
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 support requests in Zendesk that turned into Zendesk 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 and 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 a lack of cohesion between customer success and developer relations, not just in regards to resources, but in other areas as well. It’s 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 Cypress for two years.
Previous to that I worked as a software developer primarily with angular.net and React Native applications. Before I got into tech, I actually had also worked in journalism and in financial services as a licenced investment advisor.
So the talk earlier by Mike Swift about the financial concepts was spot on. That was great. I super enjoyed that. I then went into developer relations. I’ve been at companies like Replay Ionic, and I’m now a lead developer advocate at OutSystems, which I joined when OutSystems acquired Ionic last 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. I also am the chapter head for out in tech, which supports the lgbtq plus community in tech. Please feel free to connect with me on any of these platforms I’m @cecelia 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 DevRel. So in the stories that I was telling the customer success teams didn’t create those independent resources. The developer relations team didn’t create their own independent resources because they wanted control or didn’t like communicating. It’s because at their heart they really care about developers. So they saw a need, they 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 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 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 talking with customers that says, Hey, 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 about the 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 percenter, 5% of people who went from customer success into developer relations.
It’s not a huge percentage, but it is the fourth most common role and it does highlight that there are some transferable skills between these two teams. Alright, so what is customer success? So customer success involves a lot of different 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 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 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. We are in the trenches talking to developers face-to-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 consistent across both teams. We are 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 DevRel, 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. It also depends on the amount of access that you have to the users and the access type is different across the teams.
The type of people that customer success is talking to may be different than the type of people that DevRel is talking to. And that’s something that you also need to take into consideration with how you’re able to form your arguments and advocate for your users across different teams.
We’d also have some shared challenges. One is that you have a lot of responsibilities. You saw that list of what customer success responsibilities look like. If you imagine a DevRel responsibilities, this is a longstanding thing that we know. DevRel includes a lot of different things and 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 DevRel, 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 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, I already have my sales guy, my sales person, my account executive, and I also have a support email. So what are you here for? What 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 conflict in how we communicate. Another shared challenge is because of that rule confusion, we also have to be really highly cross-functional.
So customer success typically follows what’s called a spoke and wheel model where the user is meant to interact with you as the spoke and then you are the hub that goes and connects to all the different other teams. And 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, but then you also have to take that and interact with a lot of 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.
Those are some of the ways that we’re similar. Let’s talk about how we are different. There’s a lot of different areas where we operate independently, and one of those is the 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 typically work at the bottom of the funnel. They’re working with established accounts with existing customers, typically in some cases also enterprise customers, customers that qualify to have a success manager.
So they’re really focused on working in that stage where they’re focused on retention and then also expansion, driving loyalty and advocacy across their users. For DevRel, this is going to vary. I have a really big asterisk 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, but as we know, you could be working anywhere across that funnel depending on if you’re more DX, if you’re more in driving advocacy, if you are, you’re more like a DX role, you may be more further down the funnel. But typically you’re not only working with 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 churn rate and net dollar retention. On the DevRel side, again, it varies widely, but we’re talking about awareness metrics such as 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 some way, whether it’s a defined point where you’ve created an account, you’ve downloaded the SDK, you’ve been a certain type of build.
If you are interested in learning more about these metrics, you can visit the URL that’s on the screen. There’s a blog post that I wrote called the DevRel Guide to Business Jargon that explains a lot of these different acronyms and metrics and what they mean. So because we have different metrics and because we are working with different customers along the funnel, we also have different approaches to how we work with our users.
So success teams are very pragmatic and solution oriented. DevRel 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 establish an ongoing relationship and solving their specific use cases.
Developer relations is casting a very wide net. We’re working with massive communities where we may 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 such a small lens.
Another thing about success teams is their approach tends to be a lot less risk tolerant. So 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, promote our webinar to your customer base if it’s not something that they think will provide value.
Or they may be reluctant to have them sign up for an experimental new feature if they think it may cause issues for their application in production. And so success teams are risk tolerant because they also have to deal with things like this. This is mean that I’ve seen a bunch of times, but it’s a person in the front me collecting my commission in the back. There’s a giant explosion and it’s the deal I just passed off to the success team.
So again, I have nothing against salespeople, I love them, but 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 up. And the other side of that though is they are really, really open to things that will solve their customer’s problems.
So if there is a solution that DevRel can provide or a resource that we can provide, or even 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.
So customer success and DevRel should be working together and it’s something that going back to the story at the beginning around the documentation knowledge base 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 representing DevRel for app flow would have a call every Monday where we’d go through the previous weeks 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 because we already had that meeting scheduled, I didn’t have to wait very long to bring up the, Hey, what’s this knowledge base question? And we were able to collaborate immediately and identify not only who was the owner for that, but discuss 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 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 cadence 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.
So your mileage may vary on some of these suggestions, right? I’m speaking from my experience working with teams where the success teams and the DevRel teams are both highly technical. That may vary depending on what company you’re at. These are also developer first companies where developers 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 you’re, what business units those teams report to. Sometimes success is its own function. Sometimes it’s success in sales group together. DevRel obviously can report anywhere from marketing to product to its own function. So that may also limit your ability to have some additional collaboration.
So the first thing that you’re going to want to do is talk about goal 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 powerful users from customer success they’re 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 specialised 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 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 makes sense to be accountable for that initiative. And 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 specifically skilled to handle this initiative.
And then you want to identify areas of collaboration obviously. So these are some ones that I’ve seen that worked really well. DevRel, account enablement, 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 whoever purchased the product.
So it could be a VP of engineering, it could be a CTO, it’s likely not necessarily the person who’s actually using your tool and they’re going to have very different goals. So they may do their quarterly business review and say, Hey, you’re delivering five times a week, you haven’t had an outage. And they’re really excited. But it turns out there’s a DX issue, the developers 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 DevRel can step in and work with the customer success team in order 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 method. And so that also can just kind of help with those situations.
There’s documentation management, so establishing what processes that you have for updating documentation. One of the things that we did do was give more of our customer success team who felt comfortable with it access to the GitHub repo to just push doc updates because there were some things that did make sense to live in the docs versus the knowledge base. And that way we weren’t de-duplicating efforts there or that we were able to de-duplicate efforts.
Another is content topics. 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 team individually is kind of pitching feedback over to their product team, whether it be from specific either 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 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 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 in customer success, one thing I ran into a lot is customers want to do really weird things with your tool and the customer’s always right?
Yeah. So Cypress is a JavaScript testing framework, but it’s also a browser automation tool. And that made customers want to do really weird browser automation things with it. And as a customer success manager, you get asked, 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, but maybe Cypress 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, 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 team and say, Hey, there’s this really weird use case. What do we say for that? And they would 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. On the developer relations side too, 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 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 current initiatives are and if there is overlap because you really do have a lot more in common than you think, and if anything, you can bond over the fact that at least you’re not sales. Alright, thank you so much.
MC: Thank you. Thank you. Cecelia. Questions? Yes, we have one. Okay, got you. Be right there.
Audience member 1: Sorry about that. Thanks. That was very entertaining and informative discussion on the role of CS and its alignment with DevRel I think that’s not talked about often in some sense. So we’re kind of marketing adjacent a lot of the times, so this is very helpful.
The question is around processes for interacting with cs. So you mentioned that in this example you had a Monday meeting and you clearly gave the caveat of the mileage varying. So what about situations where let’s say DevRel is one or two and your CS and customers are in the hundreds, so it’s not even a one to 10 or a one-to-one relationship. Have you dealt with things like that? Have you thought about that? What’s a good sort of thought process for that?
Cecelia: Yeah, absolutely. So actually I’m currently at a much larger company. We got acquired and that’s something that I’m navigating right now. So I’m very used to being able to just reach out to somebody and say, Hey, and so what we’re kind of getting in the processes now is having a point person, somebody that we are able to collaborate with, we also do have access to. The way that they do things is we have a team Slack channel and like a public Slack channel where the public Slack channel will post things like updates or 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 keep up to date, but then also ask questions as they arise.
But we have been trying to get better about establishing a representative, kind of going back to the Game of Thrones thing, your person who goes first and negotiates in order to, and having them schedule on a monthly, bimonthly, 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
MC: One in the back. Thank you.
Audience member 2: You. Hi, 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. In the talk, you sort of talked about discussions you’ve had with the CSMs about generally de-duping efforts.
If you’re sharing content between a knowledge base and documentation, and that’s sort of a specific area, I’ve found myself in a lot of talking about that de-duping effort. I’m curious if you have suggestions on specifically navigating the conversation of where content belongs, whether it’s in a knowledge system or docs, and how you sort of align with the other team on the best home for a specific piece of content or content that addresses a specific need.
Cecelia: Yeah, that’s a really great question and when I talk about this, I don’t want to make it sound like you shouldn’t have separate knowledge repositories. It does make sense for there to be a knowledge base that’s more focused on support and enterprise use cases than it does to have documentation that’s designed for everybody to be able to get on board. And that’s also very different than product marketing, which creates resources that are designed for purchasers and decision makers.
Another issue that 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 with, the example I gave was GitHub access, but we also may have, for example, CRM like DevRel, 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 when you identify the things that don’t make sense and starting from there. So I wouldn’t come at it and saying, Hey, we need to be on top of everything and be harmonious and use one platform for everything. Because I think especially at larger organisations, that’s just not going to make sense.
But doing a review and identifying things that we’re 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 live in the docs because it applies to everyone. So if you are seeing that where 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. Thank you.
MC: I love that answer. Thank you. Any other questions? Okay, let’s put our hands together for Cecelia. Thank you. Yes, thank you so much.