Developer success roundtable

Matthew Revell: And let's make this a conversation as well. So if you have questions, then, you know, raise your hand. We don't have to wait till the end.

Speaker 2: Yes, indeed.

Matthew Revell: So perhaps if you could each introduce yourselves from stage left to stage right, just briefly, that'd be that'd be great. Thanks. So, Kat.

cat-mcgee: Hey, everyone. I'm Kat. I think you already know me. I literally spoke like half an hour ago. I lead the Developer Relations department at Hype.

We are an agency and we're working primarily with Web three clients. So we're kind of shifting a lot of what we're doing right now into developer success. It's been a pretty fun journey. But yeah, that's me.

kristof-van-tomme: Hi, I'm Kristof van Tomme. I'm CEO of Pronovix, which is a consultancy that specializes in developer portals. And for a very long time, I've been telling customers, like, you need to get DevRel people. You need developer relations. But it's a hard sell.

And the other thing I see often is oh, no, I'm already going into the pitch. So we do dev portals. Carla.

carla-teixeira: Hi, everyone. I'm Carla. I've been in DevRel for six, maybe seven years by now, so it's been a bit of different things. I'm currently program manager for DevRel at Miro, which, by the way, we're hiring. And really excited to be here.

I have some opinions, some thoughts, maybe different, maybe similar, we'll see. But, yeah, let's have a conversation and have some fun.

Matthew Revell: Jonan.

jonan-scheffler: I'm Jonan. I am a DevRel professional. Yeah? That's pretty good, right? I have been working in DevRel for ages.

I don't actually, I could probably figure it out. But yeah. And and by the way, I'm hireable. You did, by the way, we're hiring. Yeah.

If anyone needs to get some professional DevRel.

Matthew Revell: Well, you very much. I think for me the first question is the fundamental one, come on, what is developer success? Christophe, you look ready to go.

kristof-van-tomme: Yeah, yeah, I'm all ready. All fired up. So when we had that first conversation, you had a completely different conception of developer success than I started with. Because I was looking at it from, Okay, we need to get real. Because we see customers that are investing in API management, spend a lot of we mostly work with enterprise.

So they basically come and say, we've seen all this cool stuff and all these cool digital native companies doing making lots of money with APIs. We want a piece of that. And how do we do that? I guess we need APIs. Let's buy an API management solution.

Buy an API management solution is like, they're still not coming. Okay. I guess we need a dev portal. Okay. Let's build a dev portal.

And then sometimes, we've had some that are really successful, and some is still not coming. And then, like, now what? And I think that we need to shift this conversation from this being a tool conversation, where you buy a tool and it's going to magically solve all your problems. Or, yeah, you're going to spend a lot of money on DevRel and you're not really sure where you're going to end up with, to, okay, how can we get real about success and how do we turn this into a business success? But I had a conversation with you, and then I was like, oh, this is apparently already a thing.

And I started Googling, and said, oh, there's lots of people hiring for developer success. And that's yeah, I think this is what is coming, and especially with recession, I think this is really important that we get real about the value of what we're doing and that we get some outcomes.

Matthew Revell: So what does it mean in Web three point if it's anything different, Kat?

cat-mcgee: So I think for Web three, it's kind of what I talked about in the talk today. We need developers to come onto the platform to make products that are actually successful because that's going to bring users and the more users you bring, the more developers you bring. So for me, developer success, it's not just about helping them be successful with the protocol that you are building for them to get started on, it's helping them be successful in a much bigger way than that. Building a product. They have an ultimate goal in mind and we want to bring them to that goal.

We don't just want to be like, okay, here's how to use our protocol. Here's some really good docs, really good content of our protocol. We want to help them actually guide them into making their product a successful product. That's going to really just help with Web three point especially, just help the protocol, the underlying protocol because if new developers are coming on and building on a blockchain and they're not successful, then nothing changes on the blockchain because that developer isn't making money for the blockchain just having the project. It's the users that are making the money for both the chain and for the dev.

So what we need to do is just make this developer successful so the underlying protocol is successful. And I think that applies to just traditional dev rel as well because if more developers are successful using your product, then other developers are going to see this product and be like, yo, okay, that's obviously doing well. It can scale to the success. Let's give it a go.

Matthew Revell: Great. So, Carla, you worked in a company that had a developer success department at OutSystems, and there's a very enterprise focused, big money deals kind of company.

carla-teixeira: It wasn't named like that back then.

kristof-van-tomme: But

carla-teixeira: But yeah. Pretty much. I think, for me, I see developer success kind of with two facets. Right? In one way is we really want, like we keep saying, empower developers to be successful.

But now it's becoming more and more trendy, so the other side is looking at this as a more formal type of role. And I draw quite a few parallels between developer success and customer success. And I think it's also kind of exciting to see that now we're starting to learn from other industries and functions that have been here for longer. And it's for me, I see it as more, okay. There's maybe some strategic accounts that do need a more high touch kind of support where we want to make sure that those developers really are set for success, not just being able to use the tools that we have, but in achieving their own goals through using the tools.

So it goes a bit further than just support. It goes really into enable them to be successful at their own goals.

Matthew Revell: So then, Jonan, like, if you're building a team and you have a certain number of head head count, how do you factor developer success into that? Is it a cross functional responsibility that every person on the team has or do you just slap someone down and say you're the developer success person now?

jonan-scheffler: I generally don't. I try to hire generalists. I think that like all of the various spheres of DevRel are equally important and people will gravitate towards the things that they find most fulfilling. So I try and hire people such that they find purpose in their work because then they're happier and we have better teams. But I think that developer success, I've always thought of as fitting like either it is customer success and rebranded because an executive is like, well, we are a developed product company, so you are therefore developer success.

I read it on the Internet. It makes people famous. They do probably suggest or else it's part of, in my mind, was, until I spoke with Carl last night, part of developer experience. And this argument actually holds a lot of weight with me that it's actually a subset of that kind of customer success role, that this is not just about the fact that your customers are developers. It's also about this kind of white glove VIP focus of the developer success role and even using that to kind of prune the community.

I well, prune makes it sound like you're offing people, don't don't don't prune them that way, but kind of shape the growth. You know, like you you were trimming a bush that is growing in, you can control the growth of your community to grow it in the direction you want by activating potential advocates in your community through developer success. And that's the part that's really interesting to me. So in answer to your original question, aside from my tirade, sorry, I think would be open to the idea of hiring someone who is entirely focused on developer success and I would also expect it to be each team member's responsibility.

Matthew Revell: Like, I'm I'm I'm still not sure we've what is the day to day of someone doing developer success? What do you sit down and do? I I mentioned it jokingly earlier, with extra steps, but it's kind of the way that I see it is that you know that a developer, whether they're in a community or a customer, you know what they're trying to achieve. You understand the use case they're going for and you're just giving them that extra bit of a push to find the way to do it with the product you have.

kristof-van-tomme: I think so for seven years now, I've been explaining people that developer experience is the inverse of friction. And it's like it's a mind bomb. It's like, Okay, so what does that really mean? And like, Okay, let's go and make a friction lock. Let's figure out what are the problems and let's try to get rid of them.

But that implies that there's a single journey, really, or it really reduces the amount of journeys that you're imagining, and that it is really about getting people to use your technology, where I believe that what we're doing here is not so much about getting people to use technology, it's about giving them building blocks to build experience, to build digital experiences. And those building blocks are not just APIs. They're not just SDKs either. There might be really, really simple things like a widget or a QR code or something like QR codes, can just print them out and put them in your physical shop and start a digital journey. And too much, we are so much hooked, like hang up on our we are building this thing for developers that we're forgetting that what the real goal is to facilitate this automation and this journey creation and to create better experiences for customers in the end.

And so I think developer success refocuses on how are we going to get people the right experience for the right person. How can we resegment our markets from what we used to originally say is you have developers and you have business personas to, Okay, one customer that has a bicycle widget. I don't know if it works. I don't know how big a deal it is for them. But I find it fascinating that they have they've been thinking about mobility and people selling bicycles and how they can have a piece of that market.

And so in how can you have personas for, like, the kind of experiences that are being built rather than for the roles that they're playing in your system. I think that's, I think, the switch that's happening. And I think what developer success engineers or whatever developer success people, what they'll do is partially first just doing the job and helping people to get them to success. Maybe look at the enterprise people or the big accounts, make sure that they're successful. But also start looking for what are kind of a little bit of product development.

What really our markets for integrations that we're doing? And like outside of the digital space where your digital product is your product, but like the wider world where the enterprise world where the digital product is a complementary product to your main thing, how do you actually get them to success? And how do they get ROI on these investments that they've been making?

jonan-scheffler: I have a thought about this, actually, around that ROI thing. And I think this is a conversation we have a lot in DevRel communities. But I want to bring it up here again that it's right there in the title that developer success is not about you. It's not about you. Not about like, we're all gonna die someday.

Right? Who's

cat-mcgee: Why did we get here?

jonan-scheffler: Who's excited to have maximized shareholder value on their gravestone? Any I'm not me. Right? Like, we're not here for that. We're all here in this room bound together by the fact that we want to make more developers and we want to help those developers be successful in the world.

Right? And so my point, I guess, is that if you keep that as the primary focus and you define success by what that developer defines as success and you carefully target those members of your community who are most active, most likely to share the news, you can generate this self sustaining exponential network effect around your community. And thereby, you probably will continue to get a paycheck. But but if you make the paycheck the goal, I think you get it upside down a little bit. PJ.

PJ: Yeah.

Matthew Revell: Wait wait for the mic.

PJ: Hey. So I I really like what you had

Audience member 1: to say there. My my one question is how do you translate kind of upstream that developer success is essentially a moving target? Like, lot of times, you know, people say, oh, we were so so we're setting our goals for the entire year here in January, and we think developer success is x. And you learn through the year that it's also y and zed. Like, how do you translate that to say, hey, c level folks.

This is not a static thing. This is an organic thing. It's going to change as we learn more about our community, as we learn more about the developers using what we're giving to them. Yeah.

kristof-van-tomme: That's That's not just for Joe. That's for everybody.

jonan-scheffler: Yeah. I we were just talking about this outside a moment ago about, like, goal setting. Every company was like, so we're going to plan for 2035 right now and we're going to need that strategy deck tomorrow. And what you do in my experience is you pin to an outcome. We're going here.

Where are we going? What does it look like when we have achieved developer success? And ideally, developer success strategies, activities, those move. But you have a pretty easy case to make to an executive team that you chose a different path because you decided the path to the goal was more successful in this case. We know that talking to the Rust community counterintuitively, despite us being a DevOps company, which should be focused on the Go language, that our Rust content is killing it and that developers out there want to use Rust and we can make them successful using Rust this way.

And it turns out those people are like super big advocates of our APIs in the community. So we get that community super engaged. We hold big Rust parties. We throw Ferris around. Where's Ferris?

Do we have Ferris in the audience on here? Where's Lily? We need Ferris up here. But I think pinning it to the outcome has been my strategy, but I'm very curious to hear what you all think.

carla-teixeira: I think that I completely agree with focusing on the outcome, but I think also we're there's two ways of kind of measuring, right? You either fall into having more kind of financial targets and things that you want to achieve, or you can focus, and that's kind of where I would see developer success more, on the health and the satisfaction of the developers. Right? And that's something that will constantly change because the needs of the developers will evolve through time. They start using your product to do something, and then that has evolved.

So, it needs to evolve with it. So, I think that is good way to measure it and to pay attention to and to cater towards that. And it's also a strong argument because then you're looking at retention because if you're still fulfilling their needs, developers, customers, they will stay, which means more ARR, which then makes the execs happy.

kristof-van-tomme: Do you want to begin? Have something to begin on that because I think there's this concept of obliquity, and maybe that's one for the book club. But there are certain goals that you cannot achieve by trying to aim for them directly. Like, for example, trying to make a lot of money, like, is going to land you in jail. So so the the way you make a lot of money is by doing other things that happen to be valuable for other people and then make you a lot of money.

So I think one question to ask is, is developer success one of those things? Is that something we should be aiming for directly? Do we really need to aim for developer happiness? Or this is maybe controversial maybe that's some controversy that you asked for. But Okay.

And I'm not saying we should make people unhappy. Of course not. Unhappiness is probably an anti goal. But is happiness really a goal? Like, because this is what sometimes you see in offices like, oh, yeah, we're going to put in a kicker table and we're going to do all this other stuff.

And, you know, yeah, yeah, maybe, but really? Is that really valuable for them?

Matthew Revell: So you're asking if we need free range devs or

kristof-van-tomme: caged I think it's this if you are trying to target directly making people happy, it's kind of like trying to it's with a lot of things like that, also in relationships. If you try to get a relationship, it's not going to work because people feel manipulated. And I think it's something similar it could also be something similar here, is that if you're really trying to pamper developers so that they're going to choose your product necessarily, you're manipulating them, and you're treating them not with respect. So what is the path that you can create for them to have business success so they can go to their manager because they're also risking to be fired in this economy? How are you going to make them succeed in a business way?

And that might mean, like, not giving them the latest, fanciest technology, but giving them a tool that just gives them a shortcut so they can get to the value much faster. And it disconnects also with looking at developers. Lara said this interesting thing from the Dev Portal Awards. And that's one of the key things we are learning this year from the Dev Portal Awards is that this business and developer persona is merging and is becoming a technologist persona. And we've had a customer they talked about business developers, they called it.

But it's the same thing. It's like instead of looking at people like, oh, yeah, you're a developer, so we're going to give you some developer tools, or you're business person, so we're going to talk bullshit to you. Like, can we give them like, treat both of them with respect and not try to titillate them and not try to manipulate them by either blah blah marketing BS or shiny toys, but say, like, okay, you to do your job. You need to do it as fast as possible. How are we going to help you do that?

cat-mcgee: I think this is, to me, is the main difference between just developer enablement and developer success because what we do in DevRel is helping developers code. That is ultimately what it comes down to is that we want developers to code. That's kind of the end of it. Developer success to me is all the other stuff outside of the code. Devs want to code.

They can code. They know what they're coding and what they are lacking are things like marketing support or their business goals or just things that are a lot outside of coding. While I think developer relations can own developer success because we are the people who are talking to developers and understanding how to actually communicate goals and stuff with them, I don't actually see it as a complete dev rel responsibility at all. I think, I myself and most dev rels I know, don't really know how to make a successful product actually successful. I know how to make a product, I know how to make a good product, but I don't know how to make it be used by people.

So think I the whole point of developer success is to build on top of the code that they already have. That's already their job, and that's where I see it as new, which is something that you mentioned.

kristof-van-tomme: What you said just made me think that it really is obligatory because you said, is it our job to make it easier for people to code? So if you believe your job is to make it easier for people to code, you're going to do stuff to make people code. But there might be another way to get them to the endpoint that they need that takes less effort, less money, is better to is easier to maintain, and so on and so on, that does not involve writing custom code. But as long as you believe your job is to make it easier to code, you're going to be making it easier to code, which might actually be the wrong thing. And that's an example of obliquity.

Microphone person: There is a question

carla-teixeira: in the audience. Yes. Yes,

Microphone person: now it's my chance waiting for ten minutes. No. Okay. So when you opened that panel, you said that you want to talk about how we put this into practice, right? And you have talked a lot about, like, how to bring value to to developers, and and I really loved the question, you know, going there and say, what does it look like if you have achieved developer success?

So I would really love you to talk more about, like, the four of you sitting there, what does it look like if you have achieved developer success? And let's say in six months from now, how do you measure it? How do you say this was our impact in developer success? Our developers are now more successful. We have brought value to them.

So making it more practical for us to really take away some stuff and ideas would be really cool.

jonan-scheffler: We were just enjoying talking words at you, though. Were very entertaining to us. I think a lot of people like measurement is kind of beaten but a lot of people measure like first deploy or like first successful API request as like DevRel did a thing and you're talking about like awareness and acquisition in those steps and what I think if you're practically going to implement these things, you make it a part of your regimen to understand where the community is getting stuck, where they're dropping off, do scroll tracking on your documentation, know that people when they get to the fourth exercise stop proceeding with that page 80% of the time and change it and iterate AB test towards something where you get people to continue through that. And so you are going through Stack Overflow first thing in the morning altogether, hey this is an interesting one I found, you make it a team activity. Everyone go through Stack Overflow now and what did we learn today, class, about the questions we saw on Stack Overflow.

Where are people getting stuck in our flow? Did they stop using this tutorial at a specific point and what can we do to change that? So I see the developer success part of that as the things that come after. Right? We have the people, they're using the product.

Are happy here? Are they successful long term? And I don't think that unhappy is kind of part of the developer brand. I don't think that developer happiness is a thing you can measure in that way, but I do think that it matters that people maintain engagement. This is about retaining the engagement that you're already generating with your community and amplifying your most, I guess, persistent voices in the community.

This is my take, and I want to hear you say words about it. Me? Yes, you specifically, because you are very smart on this thing.

carla-teixeira: Well, I agree with all of that, and I think a way to kind of sum it up is I would look at churn. You'd want low churn because that means that you're still providing value, developers are getting value from the tool, and if you're doing then a good job, you are as like I was mentioning, as developers evolve, so does the tool, so does the value that you're giving. And that means people don't leave. They won't stop using it. So I think that, for me, would be the main one.

kristof-van-tomme: I will go more meta. What is the original intent why they came to your developer program? And did you fulfill that faster than they were expecting for it to be fulfilled? Because if they come to, like, Miro, what is it that the developer is trying to do? Are they building a business an app for their business?

Or are they building, like, a new product? Then if it's an app for their business, then probably there's, like, a common use case that is hidden somewhere under there. Can you identify what is that common use case? And can you make tools that make that much, much easier than writing custom code?

Matthew Revell: And that's all great. But the question was the opposite of going more meta.

kristof-van-tomme: It was like what are

Matthew Revell: the practical steps that we've taken? Kat, if you've got something to say on that, I'd love to hear it.

cat-mcgee: I mean, feel like what I'm learning from this panel is that developer success is the same as developer retainment. But as the resident web three person, in web three it is a very simple thing to measure because what you want from a protocol from developers who are building on your platform are users ultimately because users get you like directly making money. So the success for developers is how many users the developer has. And that's a super simple thing and I go into developer success from the blockchain standpoint because it's like, okay, have hundreds of developers building on this platform but none of them are actually building anything decent. Let's help them do that.

So for me, it's very clear from a blockchain web three idea what developer success is. I feel like from this panel, maybe it's the same as developer retainment. I feel like that's kind of what we're talking about. So I would love to hear just from traditional web three, what is the difference between success and just keeping them?

Matthew Revell: Do you mind if first we go to the audience? Because I would love to hear from people in the audience.

Microphone person: I have one here.

Matthew Revell: Who oh, okay. Well, so can we keep it focused on practical steps if possible?

Microphone person: Yeah. So my question is a little bit about because we're talking about developer success, and I hear a lot of, like, how easy it is to onboard or how easy it is to kind of continue the journey. But isn't developer success about how easy me as a developer can achieve a goal?

kristof-van-tomme: Yes.

Microphone person: That, let's say, the CEO comes to me like, I want to build this application, and then I can really shine to my boss later, it's like, I build this in two days. So my journey could have been terrible to get there, but what I have, isn't that the success? Or what would you say then?

Matthew Revell: But what does it take? Does it take?

kristof-van-tomme: Want to give

Matthew Revell: Brandon a chance to answer that if that's okay because I know he's itching to speak.

Audience member 2: I think I can provide a few practical examples of things. One, if your platform is growing, expanding, you have new offerings, you wanna make sure that developers that can get value out of those offerings understand that they're coming and how to use them and how to implement them into their current workflow. So keeping developers apprised, and that comes down to one of the things mentioned earlier, market segmentation. Understand who's using what and why. If you don't understand that, you won't be able to define success for them and provide them a journey that makes them successful moving forward.

Another example would be once you have those segments, say, okay, here's someone that's using this specific product or part of our service, and we can tell by the way they're interacting with it that there's a certain pattern or use case that maybe they haven't optimized. If you can identify that, then you can go to them and say, we noticed you're doing x, y, and z, but if you do this other thing, you'll be able to cut out these two steps and it'll save you money. And that's something also that I think comes to developer success. It's not all about churn and money, it's about ongoing value. Right?

So find ways to actually help people spend less money on your platform that's extremely beneficial to them and that's only something that you can really do when you have that product insight. So those are just a few things from my experience that are practical and help make developers successful in the long run. Now we can chat more later if you wanna get more specific into the types of products that you're representing, but hopefully that helps. And sorry to steal the thunder.

Matthew Revell: David. So David at the middle.

Audience member 3: So maybe I'm gonna simplify it too much, but developers don't come to your platform to work through your process and your, right? Developers have a job, and they've been told to solve a problem, and they're looking for the fastest way to solve that problem. That's what they're there for. And to me, that's developer success. Can they come and get the answers they want to solve the problem that they have because their problem is not working through your tutorial?

Their problem is they've got their engineering manager breathing down their neck saying I need the solution to this problem by tomorrow or you're, you know, in the case of if you work at Twitter, or you're out of here tomorrow, right? I mean, maybe that's simplifying it too much, but that's, to me, that's developer success. Am I allowing developers to come to my platform and solve their problem and move on rather than work through my documentation and do all my tutorials? That's All of that is if they have time, right? That's a board developer.

A developer that's on my platform to solve their problem is the one that I want to help because they're the ones that are going come back.

jonan-scheffler: I don't know that I want to solve that person's problem. I I I think What? I want to explain myself here. Okay? I think you're looking at, like, the quick serve restaurant management approach to doing developer success.

If I come to use your platform today because my engineer manager is yelling at me and I'm trying to solve an immediate problem, I will solve the immediate problem and maybe go away forever. I think that it's important if you have a developer product company to remember that many people still code for fun. They still code for fun and they have their own goals and their own dreams of what they are building and the platforms that I end up building with at work or the things that I build with code, they very often collide with the weird thing that I learned about at a meetup that I thought was fun and I experimented with and I came to play with that thing. And so for me, success is not like in and out. It's a transactional relationship.

I'm not trying to build a transactional relationship with the developers in our community. I'm trying to build long lasting friendships. I want to be there to support them throughout their careers. So I think that this focus on getting the engineer to stop or the manager to stop yelling at me is maybe blinding us to the fact that developers code for any number of reasons and finding the ways that they are failing with your products and platforms is a long term exercise. These are people that you're maintaining for a purpose.

Matthew Revell: Final thoughts,

kristof-van-tomme: I disagree. Shocking, but true. Contextually, I think this is contextual. So if you're building developer tools and you're trying to like what most of you are probably doing, because DevRel typically is about building developer tools. You're right.

But I think that if your API or your developer platform is a complement to something else, like you're selling services and you have an API, then that's a different story because people don't come to people don't code like messaging APIs for fun, I think. Not really. They're doing it because

jonan-scheffler: to be kidding me. How many people make silly Twilio apps? Of course we do. Go on. I'm sorry.

kristof-van-tomme: Don't want to interrupt. Think most of the time, they want to get something done. And if you can get out of the way and get it done faster, so I think it really depends. Like, if you're building a community and you're trying to build a developer brand, yes, then you're right, I think. But if you're part of an enterprise machine where they're just trying to make this thing make money because they've made this huge investment, I think it's a different story.

Matthew Revell: I'm going have to give the final word to Carla and Kat in closing.

kristof-van-tomme: Do you

Matthew Revell: have any thoughts?

carla-teixeira: I understand, like, the having or people either want it quickly or not, but for me, that goes that we all have different styles of learning and so do developers, and there's some people that want to take the time to go through documentation. There's people that want to see a quick video. There's people that just want to ask someone and get a quick answer. And I think then it's our job to provide different styles, different formats that is inclusive for all the different types of learning and getting to the solution they need. Kat?

cat-mcgee: Yeah, so I think what I'm learning is that developer success doesn't need to be on every platform. I think for the example that you gave, that's a developer relations job, It's something that we're already doing. We're trying to make it super easy for someone to come in, build on it, and go away. That is what we're doing. But I think for developer success, if you want your developers to be successful in the long run, if they have more to do than just integrating platform into what they're doing, then that's when developer success is really important.

But I don't think it's something that we necessarily need to use for every single protocol. Kind of like what you said.

Matthew Revell: Okay. Well, thank you. There's a rule in drama that you can't put a box of cookies on the table without mentioning before the end of the play. So what's the deal?

kristof-van-tomme: I've got chocolates. Who wants chocolates? Don't make me go home with them. So that's that's the deal. Okay.

Matthew Revell: So let's thank our panel and it feels like a conversation where we barely scratched the surface. So let's carry on. Thank you very much.