In this session, Hunter Weinsheink, our DevSuccess lead, will discuss what makes DevSuccess different from traditional support functions, why it is a crucial role within the dev team, and how to build a successful DevSuccess to help your dev users thrive.
Hi, everyone. Hi, Codemotion. I am really excited to be here with you guys and be talking about developer success. I’m just going to go ahead and share my screen, and we will get started.
Awesome. So this talk is called “Developer Success Joins the Developer Dynasty,” which is a really, really broad title, and I’m sure that there are going to be a lot of people asking, what is developer success, and what is the developer dynasty? So I’ll just give it in a nutshell.
We’re going to be talking about how to work with developers as customers, and what is the kind of support that they need, and why DevSuccess is the best function to fulfill that role. What is it, and why do you need it? So a little bit about myself. My name’s Hunter Weinsheink. I’m from Scottsdale, Arizona, originally. I currently reside in Tel Aviv, Israel.
I’m a full-stack developer by trade, and I lead the DevSuccess organization over here at Frontegg. On the fun side of things, just like you mentioned, I am a theater director and the artistic director of The Stage, which is a nonprofit that gives performing arts opportunities for immigrants over here in Israel.
I’m a fellow with the Nevo Network, which is also for Israeli immigrants to help work on their high-tech careers and accelerator for new high-tech startups. And I’m also a pun enthusiast. Like I said, rock and roll. So let’s get started. Welcome to the developer dynasty.
There’s a lot of developers right now, and specifically by the year 2030, there’s expected to be 45 million developers in the world. That is a huge portion of the job market. And as we know today, there’s a ton and ton and ton of developer jobs that are open, and a lot of developers that are looking for those jobs and more and more people who are taking degrees in boot camps and learning development.
And there are more and more what we call, you know, B2D companies. It’s business to developer companies, things like I added some logos here, JFrog, Snyk, Elastic, Redis Labs, Imperva. These are all companies who their main customer are developers. And these are, you know, five logos, but there’s tons more.
You have companies that are looking for…that their main customer is developers. And even companies that aren’t focused on developers usually have some degree of developer consumption. If you take something like HubSpot, for example, HubSpot is a company that generally works with marketing or sales organizations, right?
Usually, we want to get leads or track conversions. And even for a small company, not small, excuse me, even for a marketing or sales-focused company like HubSpot, you end up with APIs and webhooks, and you have some degree of developer consumption involved in the product pipeline.
So even if you’re not a direct B2D company, you’re very likely to be as a SaaS company, a company that has developers consuming some part of your product. And so I’m going to make a broad statement here. I’m going to say that any SaaS product needs developer cooperation to succeed. This is either going to sound really broad or really basic, right?
The essential idea that we’re taking here is that a SaaS product, whether or not it’s directly meant for developers, has a level of developer cooperation that is required. If I’m working with HubSpot as an example, and my R&D team isn’t able to integrate their API, get data from their webhooks, I’m not going to be able to take my signups from my product onto HubSpot where I’m tracking my customers.
So that’s just one example. But whether you’re a B2D company that’s focusing directly on developers or a generic SaaS company that has a public API, SDK, or whatnot, you will need a level of developer cooperation. And developers are picky eaters, to put it lightly. So let’s talk about why developers are different.
Why are they different than just any other customer? And why is developer success something that is coming up right now? And first of all, there’s a lot of different tech stacks. There are hundreds of languages, web frameworks, libraries and tools, and thousands of different stack permutations. I actually think tens of thousands, if I’m not mistaken.
We actually just saw in the previous talk all those different machine learning tools that you can use and how they can be combined. Well, this is no different. Every developer consumer that you have is going to be unique in some sort of way. This graph right here is from the Stack Overflow 2020 Developer Survey. And what’s really interesting about this is you can see that 51% of developers are currently developing in Node.js, which is a crazy number, right?
That means that roughly half of the developers in the world are developing with Node.js. But that does not mean that 51% of developers are the same. I can tell you from experience, 51% of developers are absolutely not the same, right? Just because you’re using Node.js doesn’t mean that you don’t have a completely different frontend, right? You’re going to have all these developers, maybe on their frontend they’re using React, Angular, Vue, Next, Nuxt, all these different frontend frameworks.
And on the backend, you’ll have your different DBs, you’ll have your different route frameworks. You’ll have so many different pieces coming together that, at the end of the day, just because you’re using a single language, it doesn’t mean that you’re dealing with the same developer. The way that developers communicate is also a very unique art, right? Generic communication for a team is going to be an email, right?
When we talk about support, especially support functions in companies are email-based. So if I think of a support tool like Zendesk or anything else, you know, usually when I open up a ticket, my main and primary form of communication with a customer is to email them, is to respond, send an email, and go back and forth. I don’t mean this to throw any developers under the bus, but I don’t know how many developers on your team or you know that check their email on a regular basis.
In my experience, it’s a low number. And if I’m trying to get a quick and constant communication with the developer, email is not the way to go. So I’ll maybe go through Stack Overflow, Slack, Jira, WhatsApp, Discord, Teams, lots and lots of different communication tools. Or, you know, my favorite way to communicate with developers is to shout across the open space.
I find that sometimes that’s the best way to get things done quickly. And another reason that developers are different is because they have a different degree of complexity with the problems that they find, right, than a regular customer who’s just using your product and says, “This doesn’t work,” right?
When a developer is integrating your product or working with your product in their code, oftentimes to fix their problems, you’re going to have to have a degree of maybe live debugging. It’s going to be the only way that you can sit with those developers, look at a maybe dev-based feature, and really understand what’s going on. You’re going to need to have concrete product knowledge.
You can’t just give a vague explanation of what your product could do, right? When you have specific issues, you need to have a degree of technical expertise and a degree of technical product knowledge. And you need to have in-depth familiarity of your source code, right? So if you have an API or an SDK that you are exposing to your clients, they’re often going to be working within your source code, looking at different typings, and how you put your product together so that they can optimize the use of their own application.
At the end of the day, developers want to know how something works and why it doesn’t work, right? And in order to help a developer with that, you need developer knowledge. So that gets us to this idea of DevSuccess. I mentioned in the beginning that DevSuccess is the best function, right, to cover support and also the success for developer consumers.
But titles like DevSuccess, dev relations, DevOps, you know, there’s lots of different dev titles, and they all mean very different things. So I’m going to break down what DevSuccess is for you. There are three main pillars of DevSuccess as I see it. There is developer support, internal customer advocacy, and upselling.
Let’s go into each of them one by one. First of all, developer support, right? This is…it’s a different level of support than generic support because it requires knowing the ins and outs of the technical side of your product and also being able to look and understand a customer’s piece of code, right?
So you need to have knowledge of code. You need to be able to work with developers on integrating your product. DevSuccess is also going to understand bugs that fit the granularity of their needs, right? It’s not going to be, this doesn’t work. It’s going to be something very specific about a piece of your SDK potentially. DevSuccess is going to improve documentation and customer education. And I think the most important piece of this, DevSuccess is going to keep your support pipeline short, right?
A generic support pipeline for a SaaS company, especially on the technical side, is going to look something like this. You start with a customer. The customer has a problem, so they talk to their account manager, their point of contact. The account manager talks to tech support. Tech support looks at the problem, writes down the details, and can’t figure it out, so they go to the R&D manager. The R&D manager gets a developer. The developer then goes on a live session with the customer to understand what the problem is.
Maybe the developer fixes it. Maybe the developer needs to work on a bug or a feature request in order to fix it for that customer, in which case you then have an even further communication cycle. So depending on the level of the issue, you’ve now had a customer talking to at least three people, and you’ve had a task jump through all these points in your company, which is going to take time and money.
It’s going to take a lot of effort from your resources. With DevSuccess, you can keep that pipeline much, much shorter because they have the knowledge of code. They can get on with the customer, immediately enter a live debugging session if they need, understand what’s going on with their code, and hopefully help them. And if not, either they can fix it themselves in the source code or open up a ticket for the R&D team with all the details that they need.
The next point that DevSuccess…the next pillar is internal customer advocacy, right? DevSuccess is going to be working in depth with the technical side, right? So they’re going to be working with your developer customers. And in order to fully understand the pain points of these customers, they need to have a level of development experience, right?
I need to understand why this integration isn’t working for you. And it’s not just because it doesn’t work. It’s that level of granularity again. So if I’m responsible for understanding what my technical issues are for a customer and getting real into it, I can take that and create a customer-to-product pipeline. So with this knowledge, I can then, much more than a generic support team, write down all the things that I need to be aware of, all the things that I need to be taking forward in order to have this go through product, designed, put together, and then towards the R&D, right?
This is as opposed to generic success, which may fully understand the requirements but DevSuccess is using their technical understanding, right? So they’re not just able to understand it, but they’re also able to prioritize. As I’m sure any of us who work with customers know, everything is urgent, right?
Everything is the end of the world sometimes. And oftentimes when you’re trying to prioritize problems, when everything is urgent, nothing is urgent. And so you, it can be very difficult to understand, what do I need to prioritize? Which customer is more important than the other? All customers are important, but if you have a technical level of the understanding, you’ll be able to provide that customer with a workaround.
You’ll be able to say, “What is a real blocker and what is an emotional blocker? And how can I really give the customer what they need? And how can I prioritize what is needed fast?” And the third pillar of DevSuccess is upselling, right? This is more of the salesy aspect. So DevSuccess does have that word success in it as well. So DevSuccess is meant to be a success manager with individual knowledge of each customer and customer usage, right?
You want to make sure that the customer understands exactly what your product is and what they’re getting out of your product from a technical standpoint. If you have developer consumers, you want to make sure that your product is something those developers can’t live without, right, that is really important for them.
And with each customer and each different tech variety, each different tech stack, you need a DevSuccess to be able to say, “Okay, I understand that this customer has this stack. This is how they’re using our product. These are the features that are currently available to this tech stack. Here’s how I can go to them and help them use our product more, right? Here’s how I can improve usage of our product. Here are new features that I can give to them, that I can try to upsell with them, and I can really encourage the use of my project based on the granularity of my knowledge of how the customer is using the technical aspects of my product.”
So these are the three pillars of DevSuccess, which is a very kind of support-based focus so far. So we’ve talked about it in the sense of, right, support, product improvement, and upselling. So I like to say you have your support, your product, and your sales. You have these nice three pieces.
But this isn’t just about why you should hire DevSuccess’s support, and this isn’t why you should hire a sales engineer, right? It’s not why you should hire DevSuccess instead of tech support. Tech support has a really important role in companies, especially when you do have non-developer customers, customers who say, “This doesn’t work,” and you want to give them product-level support or technical support but for those non-dev customers.
So this talk is more about how DevSuccess can improve your organization as a whole, from R&D, to product, to sales, to marketing. So let’s get into that. Like I said, DevSuccess is really multifaceted because it covers…it goes into R&D, product, and sales. It can shorten the ticket timeline.
So it can shorten the timeline of support and feature requests. Oftentimes, this is because instead of hopping from all those people, like we said, my DevSuccess can take it and run with it. They understand the problem and they’re able to move forward with it. They can improve the product with direct and frequent customer communication, right? So they have an accurate understanding of what it is the customer actually needs on a technical level and can bring that forward to the product team and help prioritize it.
They can help increase customer usage, right? So these are the three pillars that we just talked about. By understanding what the customer needs, they can tailor sales, tailor usage towards that customer’s specific use case. And then here’s one thing we didn’t say. They can help marketing by increasing external advocacy opportunities. So there’s a really large community around developers, right?
Developers have forums, review sites, Stack Overflow, so on and so forth. Reaching developers and getting them interested in your product so they understand why your product is necessary, it’s a common crux of marketing teams. Marketing teams, specifically in SaaS companies have a difficult time with this always. And regular customer success also struggles with this.
How do I reach out to developers who are a clear stakeholder in a company for using my product? Essentially, when you have one-on-one dev communication, when I’m communicating with developers as DevSuccess, it’s a huge opportunity for me to get developers to help advocate for my product, right? A good experience from a developer with somebody who understands the technical aspect, who’s able to take a look at their code and help them out is oftentimes the nudge developers need to go from being a user to being an advocate for you so that they’ll write reviews for you.
They’ll get on Stack Overflow and recommend you. They’ll be those people who can really, really drive your product forward. So as I mentioned before, I’m the DevSuccess lead at a company called Frontegg. And I wanted to tell you how we did it over at Frontegg, how we implemented DevSuccess, and what that looks like.
So I’ll give two-second introduction on Frontegg. Essentially, Frontegg is an authentication and user management solution that works out of the box. It’s five lines of code to integrate. So if you want authentication in admin portal where you can access roles and permissions, SSO set up, audit logs, webhooks, all of that, it’s five lines of code to lay on top of your product.
And it covers all the basics of SaaS app building. So, like I said, user management, SSO, machine-to-machine tokens, etc. And the main idea is that we do this for SaaS companies so SaaS companies can focus on their unique product, the thing that really makes them unique.
Now, I said we do this in five lines of code, and you would think with only five lines of code, you don’t really need to outwardly focus on developers. How complicated can five lines of code be? Well, those five lines of code are used to integrate a fully customizable login box and admin portal. And the key in that sentence is fully customizable, right? In order for you to work with modern-day SaaS companies, or for us to work in modern-day SaaS companies, we need to be flexible towards their tech stack, towards their architecture, towards their design.
It’s exactly what I talked about before. All developers are different. As a dev-focused company, we need to be able to run with the different developers. There’s a plethora of technical needs. One of my favorite words, by the way. So, for example, like I said, Frontegg customers are building in all different frameworks. Taking frontend, frontend, Frontegg, taking frontend as an example, they’re in Vue.js, React, Angular, Next, Nuxt, Vanilla.
You know, we have different customers all coding their Frontegg in different ways. So what happens is it’s five lines of code for the customer, but that turns into five lines of code over multiple SDKs for us to maintain and to help integrate. Not to mention the extra code that’s needed for designing customization, excuse me, or we haven’t even started to talk about backend SDKs, right, or backend integration, or webhooks, or getting all of that setup.
So the technical need that is simple, forward-facing ends up being different for each customer and requiring quite a bit of technical expertise. Our customer success team couldn’t keep up. Basically, as a dev-focused company, when we were integrating with developers, it oftentimes required live debugging.
It required involvement in our client’s code because we’re going into an application that’s already built, an application that maybe is new or maybe is old but they have an app and we’re going in on top. So ultimately, each of these applications is different. And what would happen is when a customer had a problem and they would go to their account manager or to their success manager, it would, at the end of that pipeline, like I said before, end up taking developer time.
So a developer needs to come and they need to sit with this client, and they need to help them debug and figure out what’s going on. And developer time is expensive, and we didn’t want to continue moving in that fashion. So we wanted to hire. We wanted something to help the more technical side. Now, the base notion here is, okay, let’s hire tech support.
So we brought in tech support, and our tech support was able to help free up some time from customers, but it wasn’t a perfect solution. They weren’t able to handle all the different sort of live code issues that we had from the beginning, especially when we were working with all these different source codes. So dev knowledge was still required.
We would still have to hop on with customers. And at the end of the day, tech support is really great, but tech support is not there. Tech support are not developers, right? We needed real, concrete developer knowledge to work with developers. You know, especially when you’re communicating with developers it’s difficult sometimes to try to have to bring down your issue.
Sometimes you just want someone to sit with you who understands code and can work out the problem with you. So this is when we got the idea to look for a developer-minded success agent, someone with experience who was able to communicate with developers, fully understand their problems, and be able to offer solutions on the spot. And here’s how DevSuccess helped us.
DevSuccess basically understood our product and our code and was able to communicate with developers. So over the course of five months since we hired DevSuccess and started expanding the organization, we were able to decrease the time of completion to high-priority tickets by 55%, right? This is a direct result of shortening our pipeline.
You shorten the pipeline, it stops going through all these people, and then we were able to close more of those tickets faster. We were able to decrease the completion time of low-priority tickets by 37%. And this is one of my favorite facts, because low-priority tickets, I call the forgotten ones. Every company has these tickets. They’re open, but they’re not important, so they go to the backlog, the graveyard, to sit there for all time.
One of my favorite things about this is that DevSuccess, being developer-minded, was able to take a lot of these low-priority tickets and actually work towards them and gain easy wins, push small PRs, and move forward and get an extra 30% of them 37% faster completion time. And we were also able to increase traffic to our documentation by 46%, which was ultimately by creating more relevant documentation and then spreading it over to our customers once we understood what these common issues were, creating documentation, spreading it around to our customers, and making it easily accessible.
But the most important statistic, in my opinion, is that we were able to increase our product integration rate by 36%, right? So that means customers that were able to come in from ground zero, go to full integration, and that increased by 36%, which is a huge amount of increase directly related to DevSuccess, right?
This is because DevSuccess started leading the customer integration, could take them through so you have a very, very easy developer integration experience. We were able to reduce churn by giving technical support needed on the spot. We were able to increase our dev advocacy by driving more traffic to our product, and we took and improved the product based on all the customer feedback that we got, the technical customer feedback in the moment.
All of this came from adding DevSuccess function to our company, among other things. So let’s talk about what this all means, to wrap it up. If you’re going to remember anything, these are the main points, right? DevSuccess is not tech support.
It’s easy to say, “Okay, it’s just tech support,” in this case. But DevSuccess has a unique point of view. You’re managing support live in depth in the code with customers. You’re working with product to make sure that we have a clear review and feedback cycle, and you’re working with sales to really increase the usage of your product. Products that are consumed by developers need DevSuccess.
If you’re anywhere in your user journey, whether that is the entire product or just an API, developers have a say, and they have a crucial say in consuming your product, and you want them on your side. And DevSuccess needs to be part of the R&D team, right? No matter what, the ability to shorten this pipeline comes from the agility and speed of DevSuccess to be able to understand the issues, communicate with developers, and work inside our source code, which ultimately is owned by the R&D team, and that’s crucial for developer happiness.
And the last point to remember is that DevSuccess solves your developer customer problems, and it impacts business KPIs directly, right? We’re talking from onboarding to adoption, and all the way through renewal. You’re going to see improvements on your business KPIs. So we talked about the developer dynasty, and I’ll just say one second on what is the developer dynasty.
The developer market changes at a rapid pace. There are some roles that stick around, full-stack developer stick around, DevOps stick around. They’re important staples in R&D teams. So what I’m saying here is that with the added value that DevSuccess brings to a company, I believe that DevSuccess has really earned its rightful place in the developer dynasty. So thank you very much, and I am happy to answer any questions that you might have.
Awesome. Thank you. Thank you so much for your presentation, Hunter. It was very inspiring. So how long does it take to actually feel the impact of DevSuccess across an organization?
Sure. It’s really going to depend on the level of complexity of your SaaS product. Ultimately, it depends on how complex is your product and how many different areas are you communicating, incorporating developers into using your product. I would like to say that within two to three months, you’ll feel the full effect, right?
That first month will probably end up being more like your tech support ad hoc kind of effect. But in terms of improving business KPIs as a whole, within those first few months, you’ll really start to feel the effect.
All right. So it’s not customer success, it’s not tech support, but it’s also not evangelizing. So it’s kind of like you coined a new thing here.
Yeah, that’s exactly the point. That’s why we wanted to, you know, come on and speak about it because I do feel that it’s important for SaaS companies to really be thinking about their developer consumers as special, as specific. You know, we have, how do I get marketing on, and how do I get people to think this is important? But we don’t have so much saying, “How will this make a developer enjoy the experience of working with this SaaS product?”
But don’t you think it would be better to have these separated, so to have, like, tech support, customer success managers, account managers, or… Do you think that DevSuccess is too broad?
I think that all of these roles have very important functions, and I don’t think that DevSuccess replaces them by any means. I think that tech support is very important for non-developer functions who have technical roles for your SaaS product. I think that account managers are very important for being that main point of contact for your customers. But ultimately, at the end of the day, like I said, developers are stakeholders.
If the developer can’t integrate your SDK or your API, you’re going to run into a problem. And that’s where I think DevSuccess can come in to improve this pipeline, to improve how you work with developers and the product as a whole in conjunction, next to, you know, your tech support and your account managers.
Huh. So we have a question in Discord about the role. So you’re the DevSuccess lead, and as a DevSuccess person, it’s an interesting role. However, as developers stereotypically don’t like to interact with customers in general, who should apply to this role? Is it… Do you have to be out there a lot?
Yeah. So I actually think that’s a really, really good question. And, you know, we’re hiring for DevSuccess at the moment. So something that I’ve thought about quite a bit. And there are a lot of… Developing is becoming a more and more needed function, right? Knowing these technical skills, having full-stack ability, web development is becoming a quite modern skill.
You know, you’ve seen the emergence of boot camps and areas that teach development as a vocational skill very quickly over the amount of time. You know, you can go to Udemy right now and do a one-month course and learn how to develop. And as the job market kind of moves more into the high-tech world, I think that this is going to become more and more of a requirement.
So what I would say in this case is that not everyone who knows how to develop is necessarily developer-minded. And what I mean by that is there are a lot of people who can gain these skills, who can use it as a real opportunity to improve their career path and do so quite easily, you know, with a lot of brain work, and get into the point where they want them to have a job where they’re working with customers, where they’re a pivotal point in the company, but maybe they’re not the type of person who wants to just be, you know, in your code editor working on code 24/7.
So I think if you look at developing as a vocational skill but not necessarily as a one-direction path, you’ll end up and you’ll find that there are a lot of people that are currently entering the job market right now who really fit this role.
So basically it can be any sort of developer, whether it’s a junior, mid, or senior, anyone.
A hundred percent.
Wow. Okay. Thank you. So you mentioned that DevSuccess should sit in the R&D. So how does DevSuccess communicate with different dev teams then? Do they still take up the time of the developers?
Yeah. So I mentioned my favorite way to communicate with developers is shouting across the open space. But we do need to have a way to communicate with developers to have a communication function that works for them. And what that means is understanding the communication regimen in your company.
So for us, we usually communicate over Slack and Jira, right? So I understand these are the best ways to communicate with my developers to make sure that I give them tasks that are well documented with the right amount of information so that they can take it like anything else. If I have an issue coming from a customer, it doesn’t need to disrupt their entire day, right? It can be just like a ticket that you get from product, something that you take, work on, that is prioritized, and move forward.
So we need to have a good level of communication that works with the organization structure as it is.
So how big is your team, give or take?
The team right now is just two people. Right now it’s small, but we’re trying to build it, we’re trying to grow it. Essentially a DevSuccess team, as I see it, should be as big as a customer success function, depending on your company. If your company is a smaller developer consumption, meaning it’s, like, just API or maybe a small SDK, in that case, then I would particularly say you probably only need, you know, a few DevSuccess, one or two or three.
But if you are a B2D company, meaning a company that is going towards developers specifically, then I would really suggest having a large developer success team, right? Maybe even replacing customer success with developer success, because in that case, the developers are your main customers. And I would really call it the department at that point, and I would expect it to be the size of a department.
Wow. Developer success department.
Exactly. It’s where the future is going.
Nice. Awesome. Well, this is something new I learned, developer success. Yeah, it touches on everything, like all the old jobs I used to know, like yeah, the customer care, technical support. And you’re also a dev evangelist. I mean, do you also go to conferences like now?
I mean, yes, so this is one conference, but, I mean, to evangelize the product.
Yeah. I would expect that a dev evangelist would eventually come and sit under the DevSuccess department, right? Because ultimately that evangelism is part of success for the developers, right?
Really trying to be part of that outreach function. So currently, I’m filling that function, but ultimately as we grow, I would really expect to have someone explicitly tailored for that.
Yes. Okay. Well, thank you so much for your time, Hunter. This has been like a revelation. I didn’t know. I definitely learned something new today. And I think I heard, like, three puns during your talk.
The Complete Guide to SaaS Multi-Tenant Architecture
