DevRel is a lie

Laurent Doguin: My name is Laurent Degan. I work for as a VP of developer relation at CleverCloud. So when I said the release a lie, this implies that, you know, I might be part of the lie, but but everything's fine again. I wanna go into a little disclaimer because what Matthew might not have told you that he tweeted about this two days ago saying that DevRel is a lie. Please discuss.

And there there was some not necessarily heated debate, but at least there was some questioning from other DevRel folks about why why would you say something like this? It's it's it's mean. What I wanna say first is that every DevOps affiliated jobs are very, really much needed. So that goes to every, of course, developer advocates, evangelists, technical writers, program manager, even marketing, technical events, teachers, UX designer. I mean, everyone that practices DevRel.

I'm talking about DevRel as a job. So first, very quickly, some affirmation that I took from the state of DevRel report, which as Matthew said, is free, and that's how I get my hands on it. Go to stateoftheworld.h0p.iu and and just subscribe and get that. There are three or four facts that I wanna that I wanna emphasize first before going into the actual lie part. And the first one is there is no dominance reporting structure when you when you are into DevRel.

I think if you're starting a career or if you're looking for your maybe next opportunity in DevRel, the question most people ask is, who do you report to? Like, who is gonna be the person or the department I'm gonna report to? And that's that's very important because most of the time, let's say you were a a a developer advocate, and part of your goal is to out of your work is to get feedback from the field to the product team. And you would think that this would be easier if you are part of the engineering team because it makes you closer to the product team. But on the other side of things, if you are event manager, if you manage technical events, then you might want to be closer to marketing because organizing events is not cheap, and having budget for said events is usually easier when you report to a marketing team than when you report to engineering team.

And I know because I've been reporting to engineering team trying to get budgets. So, yes, this is quite an important question. And the thing is, there is no specific answer. And I think that's very telling, and we'll see why in a couple of minutes. Another fact that I really liked, DevRel is 20 years old.

I mean, not DEVEL in itself, but DEVEL programs. When you answer the the study, they ask you this question. Is it how old how old is your DEVEL program? And I'm super interested by the fact that some DevRel programs are more than 20 old. And if you are familiar with the DevRel scene and all those DevRel conferences, and you can see that this it's been pretty much booming for the past five, six, seven years, but it existed before that.

So what what makes Devil now so different than it was twenty years ago? And to be fair, I don't think that there's anything really, really that different. Another fact that I really liked, it's about the business model of the companies that have dev rep program. Like, a third of them are developer first, which would make sense. You know, you need to as a dev rep, you need to talk to as a developer practitioners, you need to talk to developers.

And so it makes sense to to have a different program when your job is to sell an API, when your job is to sell developer tooling, when you're, well, already developer first. The important thing is that two thirds, and I don't remember if there's a trend indication, but two thirds of those companies that have a developer program, their business is not to be developer first. Developer is just sub plus is just something that comes along the way. Maybe you're a bank, and your first business is not to sell something to developers. Your first business is to be a bank.

But you need to embrace developer. You need to talk to developers to sell them or to teach them how to use your API and everything. And this and I I believe this is growing, and this can only grow. And now the last important fact that came from the report from that study is that successful trusting collaboration is crucial. I cannot emphasize this enough.

As DEVEL practitioners, we are all aware of the transverse nature of what we do. When you start a job in DEVEL, well, first, you could be reporting to marketing or engineering or maybe the CEO or whatever. That's that's that was the first fact that came out of it. No one knows, but you know you have to communicate. And and second, when you talk to developers, there's gonna be something about the product, there's gonna be something about marketing, there's gonna be something about Fijian, it's gonna be about marketing.

Everything is intricated. Everything has to be a transverse, and this is why collaboration is so important. And the word communication collaboration to me, the important part is all about communication. I think this is what we must do. So those were facts just to make sure that we all talk about the same thing.

Now I'd like to go through what I call the DevRel fiction, as in something that may or may not be real. The first one the first fiction I'd like to talk about is when you want to hire a dev rel, you will build up a story and you will address the story to someone. Let's say, a young digital nomad that wants to do that job because you'll be able to travel everywhere, which I know is not true right now, but was true six, seven months ago. And hopefully, it will still be true in the future. I hope.

We all hope. And it's not the proper way to to to sell the devil job to someone by saying, hey. You're gonna travel a lot. And that's that's that's not all that we do, and that's not you you have some devil that don't travel at all. So I think it's it's a fiction, but that's this this is a very commonly heard fiction.

Now another one could be from a CEO that's trained to build a devil focused company and says, hey. I'm gonna hire devil, and I would be de facto compatible with that. And the other weird fiction to me is you're starting a company. It's very young, and you need someone that basically there's just you, the founder, and couple of people. And if you find that person that can do everything, then Trent and and this is, again, a a DevRel fiction.

So let's go over what I call the four four lives of DevRel. This is not the only situation that exists. These are four situation that I've not necessarily found myself into, but was familiar with and and found myself talking about with other people that shall remain unknown, which is important. So the first one is, Deborah, is a job. I I'm this is the the the the the strongest one for me.

This is the one that really doesn't work for me. I see a lot of tweets or ads for job, and the job description is DevRel. And I'm kind of I kinda feel weird about this. It doesn't make any sense to me. You could be it completely makes sense for me to be to me completely makes sense to me to be a developer advocate, an evangelist, technical writer, event manager, you know, community manager.

All these jobs are super important, but the DevRel doesn't mean anything to me. It's a little bit of everything, so it's nothing really. And, Matthew, when he when he talked about this on Twitter the other day, there were some interesting answers. And one of them was if you're in Devil, then you're a available company resource. You can serve marketing, business development, strategy, blah blah blah.

You can do a little bit of everything. So, basically, you're jack of all trades, master of none, that would be me. If you're a proper jack of all trades, congratulation. I think you deserve if you can do everything, you deserve to have shares of that company, or you should leave because you'd be able to a little bit of everything. But that's not being devil.

That's about filling in vacancies because the team is too small. And that's most of the time how devil in small companies are seen, and I think that's a mistake. Just like, hey. You are responsible for even management. You're responsible for technical contents.

You're responsible for outreach, lead gen, all these things. And because we don't have a salesperson yet, well, you're gonna be our salesperson as well because well, you know how to talk to people. It's gonna work. So to me, that's a a lie. Devil is not a job.

Now the second situation, second lie that I'd like to outline is Devil as a decoy as well, decoy in itself is already a lie. It's basically saying that I wanna be a developer first company. Let's let's make sure that this company we're talking about is one of the 68 persons that is developer plus. They're not developer first, they're developer plus, and they want to address developers. And so how do you address developers?

You hire dev rep people or And, again, that's that's now the job. And if you do that and if you've been in that situation, and I know some of us have been, everybody will suffer because if you're just here to make a company look good to have some strict credibility, then you have no idea what you're doing here. You probably have no idea. Will you report to? You probably have no idea what are gonna be your objectives.

You have probably no idea to talk to everybody else because you're just here to, you know, make sure that outside of the company, someone see you as dev the company is seen as developer friendly, and I think that's a terrible idea. And if you're looking for a job and you think that situation is gonna happen, you should run away. Now third lie, Devel has a a dedicated team. There's there's different ways, different kind of companies. And in this specific situation, let's consider that it's a developer first company.

They already have marketing. They already have engineering. They already know somewhat how to talk to developers. But the thing is they they don't really have every specialized thing. And I when I say specialized thing, it could be technical writers, could be evangelists, could be the advocates, all the the roles I've talked about before.

And because they don't have it, they're gonna fill all those specialized vacancies, not necessarily inside all of this department, engineering and marketing, but they're gonna try to create a team and put everyone inside that team. And I think it's it's not the right way to do it. I think if you are specialized into even marketing, then you should be part of the marketing team. If you ask a developer to advocate, then you should be part of the engineering team. And that situation is very, very common in many companies.

And part of the reason why is because engineering and marketing are already so busy doing their own thing that instead of taking the time to integrate all those new jobs into either engineering or product or or marketing, then you're gonna start your own little bubble inside the company. And I think it's now the right way to do it. Line number four, DevRel is is a bigger dedicated team. It's kind of a different situation. You work in a massive, massive company, and you have many, many products.

You have many different ways to talk to developers. And because you have so many dev roles, so many people that talks to developers, someone had the brilliant idea because of those numbers to make sure that everybody was regrouped into a single team. And this this is usually for let's say, I don't wanna be rude to anyone. You have lots of managers that seem themselves more important because they manage more people. And one way of doing so is by being the manager of all those level people that should be split it everywhere, but instead are being saluted into one big team because this is, you know, this is the role.

We have product. We have this. We have this. And and that's not the right way to do it. So this is not an exhaustive situation.

This is not an exhaustive list. This is some examples of what I think DevRel is not, how and why I'm saying DevRel is a lie. Again, I'm not saying it doesn't exist. I'm just maybe concerned that we may be doing things not the right way all the time, especially in those situation that are unfortunately very, very common. So to recap, I think that there is absolutely not a job, shouldn't be used as a decoy ever.

Again, if that's you know, if that happens to you, I would suggest running to the opposite direction. It shouldn't be a dedicated team because, you know, in in management's theory, it's been years and years and years that people have thought fought to move away from silos. It shouldn't shouldn't be any different from DevRel, and I think we have an issue that we need to address as an industry. Now how did we get through the situation? Yeah.

I think there's a couple of reasons that made us go this certain way and the best way, which we'll see later. Again, because of one of Matthew's tweets, we had some material and and why would we need DevRel? Because, again, DevRel is a lie. It was only be stressful to someone. So if you have understand it as we don't need DevRel, that's not what I'm saying, and this is what has been understood.

You're also the right developers should just be reasonable people, then we wouldn't need DevRel. I think, well, this is a joke. It's partially true, but I think it's for a a cultural issue. I don't think developers are a particular type of people. I think there are technical people that work in a technical space that's still very new.

And the the the reason I'm saying this is I have a couple of friends. They are doctors. And while I was I had some conversation with them, and and there seems to be a lot of conferences in the medical space that are heavily sponsored by the big names, which, you know, sounds quite familiar. And the people that work in those companies then organize those events or that sponsor those events or that propose talks to those events. I don't think medwell is a thing.

I don't think there's some medical relation people. I think this doesn't exist because they've been technical in medical terms longer than we have been technical in in their terms. And I think they've embraced that, and I think that they like, the the culture that they have already knows how to talk to medical technical people. And I think it's the same for us. I think development is still very new compared to all these things, and I think we will might get in a point where someday we may not necessarily disappear, but be somewhat less independent and maybe be merged with the whole structure of the company.

I do think we have also an ego issue. Remember when I said that or when I said when the study the DEVA study said that some programs were more than twenty years old. I like the fact that as an industry, we are all trying to build build up something as DEVAL, but I think sometimes maybe going too far. Again, it's been a 20 years old thing. Why should we be our own real special snowflakes?

I think it's not putting us in the right mind to get out of the silos and to talk more to other people. I think we are trying maybe to our to be our own devil thing. And so, yeah, maybe that's part of the the issue part of the silo issue. Another thing to me that's important, most well, not most. Some, there were programs started by technical people.

And as technical people, we are teach teach to think about the solution first and not necessarily about the problem. And I think that's an issue. Because if you think about the problem, you will realize what it is. If you think about a solution to a specific problem, then you will say we need to do this thing. We need to use this tool.

We need to, you know, do a task force and and treat that thing. And I think this is an issue because if you're problem first, you realize that the main problem we have is about communication, and communication is really, really, really hard. And and I think this is why we it's easier to get things in silos when you don't have to communicate to everyone around you. And I think this is the bulk of how DevRel should be practiced. And and this is why DevRel being a single job or DevRel being a dedicated team or a decoy is a terrible idea because it doesn't put you in a position to communicate with everyone to be transverse and to make sure that you can bring the culture of the company to a point where it becomes normal.

So I guess what I'm trying to say when I'm saying that DevRel is a lie is that DevRel should be a practice and a culture very much like DevOps and not, again, a single job or a siloed team. I think we need to get out of that state of mind, out of that way of thinking, and try to be more not even transverse, but really more being more into collaboration. And that goes through several points. And the first one was another response to one of Matthew's tweets. He's saying, oh my god.

We are like the modern agile coaches, but, like, for fancy digital native companies. And while I hate to say that, I think this is absolutely true. I think Dave Vell was born out of necessity because of digital transformation, just like DevOps. Again, this is still a very new thing, development, compared to big data science. And we are in that growth where we need to change our culture.

We need to embrace different way of of doing things. Most other industries have had the time to do it. I think we're right in the middle of doing this, of bringing the whole company, especially the developer plus, not the developer first companies, but the developer plus companies, like all the banks, all the people that have to become developer friendly. We're right in the middle of that, and this is why DevRel is booming so much right now. And I think this is born out of that.

And I really hate that word, digital transformation, because French people say digital transformation. And in French, digital is fingers, basically, so it always rings extremely weird to any any any French person. Anyway, this is how we try to practice the right clever cloud. And as just some example, I'm the VP of the operation, whatever that means. I just make sure that everybody's aligned on the goal of being developed focused.

I do have a developer advocate, and we report directly to the CEO. Maybe that's gonna change at one point. Maybe she she will report directly to the engineering team once we think that we've managed to bring the whole team towards DevRel. And so part of this example were our metrics aligned with marketing. And what I'm saying by this is every event we do, every lead gen thing that we do have the exact same numbers, objectives than the marketing department has.

And if you're wondering why at every single level provision conference, there are talks about how do you measure this? How do you measure that? How do you decide to do that? Well, I think it's mostly because we shouldn't do it all the way. I think it's important for you to measure what you do as technical writers, what what you do as a as an eventually sort of advocates.

But for all the lead gen things, I think it doesn't make sense to have our own set of metrics. I think DevRel should be seen as an accelerators of marketing or engineering when it's talking to developers. And this is why I think everything should be shared. Actually, it shouldn't be aligned to the way it should be shared with marketing. Now the other thing we try to do as much as possible at Clever Cloud is to make sure that most technical talks, most technical content comes from engineers.

Now I know that not every engineers are willing to do this, and we consider that part of our role as DevRel practitioners in is to encourage them to write more, to give talks. I'm not forcing anyone to give talks, but, you know, I'm just maybe you could start by doing an internal talks, and maybe you'll like it, and maybe you'll give more talks. I don't know. But what I'm saying is we try to help them as much as possible to be themselves, the practitioners because you don't have to be necessarily a dev dev advocate, an evangelist, ethical marketer, an Internet marketing person, a technical writers, a UX designer. You don't have to be all these jobs.

You could be any any job with the company could could be, you know, talking to developers, and we've been helping them go through CFPs. And I remember one one year at DevOps France, that was about three years ago. I think we had, like every every employee of the company had, like, one talk at DevOps, which was amazing. And that worked because we we push them or at least teach them how to do it or, you know, train them how to do it. And the cloud markets or the the cloud industry is quite hard when you come from outside, I guess.

So part of my job as a developer relation practitioners at CyberClad was to write a whole lot of content that is explaining into more less technical terms what it is. So, anyway, I'm late. To be to finish, try to not do that. Try to help people and not be a silo and and and try to not get into that situation. Identify gaps that you have to bridge to other people in your companies, and, hopefully, things will be great and amazing.

And, yeah, that's it. Sorry. Thank you.

MC: Thank you, Laurent, for for your talk there. That was great. Thanks. What what is the, in your view, the the ideal team structure, would you say then, for a company who is developer plus? You know, they don't have they're not selling a product primarily to developers, but they need to to work with developer audiences.

If if you're not gonna have silos, then what what do you have?

Laurent Doguin: That's a very good question. I'm not sure I have the answer. I can tell you what is my favorites well, one of my favorite organization. I've talked to people at Microsoft. And at Microsoft, the robo advocates are reporting to engineering.

Event marketing is reporting to marketing, and it's and it feels like it's completely merged into where it should be. There's not one developer relation team. Developer relation people are practicing in every department and trying to push everyone towards being more developer friendly. And I think that's the the best way to do it. I'm not sure if you could do that in because Microsoft is a developer first company, so I'm not sure if you could do that in a developer plus company.

You probably could. Is it enough? I guess it's that's the whole question.

MC: So one of the things I come across every now and then are companies where they have a developer relations team, even in developer first companies. Then they have a marketing team, they have a product team, they have a technical writing team, and they're not working in unison. You know, the sometimes the developer relations team are the last to find out about breaking API changes, then Yeah. They get developers complaining to them. And I think that's one of the great you know, it's alright to have all these these fancy ideas about how these things work, but I think one of the biggest practical challenges for DevRel practitioners seems to be getting the company to function as a single unit.

Laurent Doguin: It's a communication issue. Yeah. It is a management and a communication issue. That's the that's the hardest part of the problem. This is why it's so easy to put the riders in place.

Now I guess you can make a difference between competitive several product and competitive one product. If you have only one product and then you have your independent teams, then your communication job is gonna be really hard. But then if you have, like Microsoft, several products, every product team has its own thinking writers, its own level of advocate, its own, you know, specialized people in that team. So I guess the bigger you are, the easier it becomes because you have if you do it right and if you don't have manager eco issues that requires you to get everything into your own team, then it should that's probably the best way of doing it. And then if you're a small company that has everything that has to communicate with everyone, well, you it's just a default management issue.

Communication is really hard.

MC: Yep. It is. Okay. Well, look, we're nearly at time. It looks like we didn't have any questions from from the Slack.

So, Laurent, I'll just say thank you very much for joining us today. Where can people find you on the Internet?

Laurent Doguin: You can find me on l doguin on Twitter. So that's l d o g u I n. That's the easiest way to get me. And then you can send me an email to laurent.doguin@gmail.com, which is probably not displayed on the screen, but was No. A couple of minutes ago.

Yeah.

MC: Okay. Well, thanks thanks very much, Laurent.

Laurent Doguin: Thank you so much.

MC: Have a good afternoon in in what looks like your converted barn there.

Laurent Doguin: It's it's just the last four. Yeah. That's pretty. Okay. Yeah.

Alright. Well, thanks very much.