The DevRel Lie

As Devrel grows more popular so grows its identity crisis and questioning. And COVID-19 didn’t help. We wonder about its meaning. What is it? The good old Marketing or Engineering dilema. How do you measure what you do? This post is not a post about measuring DevRel. And it’s not about other ‘traditional’ topics like planes & airport, burnout and more recently how to become a live streamer. It’s not about Karaoke either sadly.

It’s about DevRel perception. How people unfamiliar with it perceive it. I see companies wanting to join the trend and look for ‘a DevRel’, or to assemble a DevRel team. Like DevRel is a job and you need to hire ‘a DevRel’. Just search Devrel on Linkedin and you will see. Devrel seems to be a job, or a dedicated team.

Well no, it’s not. I disagree. This is a lie, a lie at the basis of many misunderstanding and bad situations.

Devrel as a job does not exist. It’s fiction told to young digital nomads willing to travel, to CEOs willing to turn their company into a developer focused company, or to any starting company looking for a jack-of-all-trades.

Don’t get me wrong, all ‘DevRel’ jobs are very real. They are very much needed. Community manager, evangelist, developer advocate, event and technical marketing, tech writer, program manager, teacher, DX/UX designer, everyone is needed to make a more developer focused company. Everyone has a purpose and a place. But should they be part of a ‘DevRel’ team?

Personally I don’t think so. At least not forever, and certainly not in a company that practices DevRel right. I believe DevRel exists to compensate for some situations. Let’s see a couple of interesting facts first, and then what those situations may be.

State of DevRel 2020

The annual DevRel study is out, you can get it here:

From this we learn that there is no dominant reporting structure for DevRel. It can be Marketing, Engineering, Product, Sales or reporting straight to the CEO. Every situation exists. The transverse nature of DevRel makes it hard to pin on a particular reporting structure.

DevRel is more than 20 years old. This may sound like a surprise to many but this is mostly because of the term DevRel in itself. Companies have cared for developers and have had programs dedicated to developers for years. Microsoft’s MVP program was already here in 1995.

Developer First companies with a DevRel program are 32% compared to 68% of developers plus companies. It’s an important distinction to me. It shows that DevRel goes beyond software vendors, or traditional dev first companies. It matters to every company that gets in the digital economy.

Successful cross team collaboration is crucial. I can’t agree more with this. In fact this is the whole point of this article. DevRel is transverse and has to make sure all teams collaborate with each other to care for developers.

I invite you to read the report in its entirety. Now we move on to a description of some familiar DevRel situations.

The DevRel Fiction

Of Course all these situations are purely fictional and do not represent the whole spectrum of DevRel organizations. I however feel like they are too common.

Lie 1 - Devrel is a job.

First Situation, the company is so small they need someone to do a little bit of everything that is not already done by someone else. Congratulations you are now in charge of event marketing, technical content, evangelism efforts and community management. Oh and we don’t have sales engineers yet so if you could do all the sales meetings with our Sales team that would be just great. This is when Devrel becomes a job more than a discipline. Once you move past the basic “Devrel is just public speaking”, these are all the things one could put behind Devrel, because it is still rather new and fuzzy so they can still put whatever they want behind that term. If you are mere mortal like I am, you may be just mediocre enough at each of these required tasks. Jack of all trades, master of none. If you are more than this, you are an amazing human being and I envy your set of skills. I hope you’ll get truckloads of shares.

Is this what Devrel is supposed to be? No it’s not, it’s not a job, in which you do a little bit of everything. I guess we can still check the transverse box. For the rest… Let’s wait to see if this company is going to turn into situation 2,3 or 4.

Lie 2 - The DevRel Lure

Second situation, the company wants to be developer-first, because it wasn’t before. Because now software is eating the world, yadi yadi yada, digital transformation, we need to make APIs and talk to developers(remember those 68% developer plus companies?). And we have no idea how to do this. So let’s hire a DevRel team. True we already have marketing that handles content, community management, events, and Engineering manages documentation, product, UX and DX, sometimes give talks… They are doing their best but it’s not following any particular plan, it’s maybe a bit erratic, few people actually know what they are doing.

So let’s hire a new dedicated team to reach out to developers. Sure they will know what they are doing(actually most of us still don’t 🤷, but that’s another post). A couple of risks here. You can have the dedicated team siloed issue from upcoming lies 3 and 4. And then there is this DevRel Lure issue. It happens often simply because it seems having ‘DevRels’ is the thing to do these days. “We have DevRels, yay automatic street cred increase!” Well no it does not work like this and it’s certainly counter productive. DevRel is all about authenticity. We are probably here because dev don’t like to be tricked by ‘traditional’ marketing in the first place.

People will suffer if they don’t know why they are here except making your company look good to developers. Please note that the decoy situation can appear in a developer-first company when executives simply follow the hype and do not think about this properly.

Lie 3 - Devrel is a dedicated team.

Third situation, the company is already a well established developer-first company because the only people they talk to are developers. Marketing and Engineering are already targeting them, so why would they hire Devrels? They usually do to bridge gaps between existing teams, or to fill in specialized vacancies, most of the time developer advocates or evangelists. What’s the difference you ask? If there is one thing as undefined as DevRel, it is developer advocacy. Let’s make it simple and sum it up as evangelists are outward facing and advocates take outside’s feedback inward. You are also very likely to have tech writers, UX or DX designers and Community Managers.

This is a pretty good situation, usually because C-levels understand the value of practicing DevRel. They understand the need for specialized roles and acknowledge the fact that they can be full time jobs. But they don’t always acknowledge the transversal character of DevRel. They don’t see it as a practice or discipline, something cultural for the whole company to jump in. They often see it as it’s own team with its own set of objectives and targets. It’s DevRel in a silo.

How does it fit in with the rest of the company? Everyone is talking to developers after all. So maybe it should not be a dedicated team. But if it’s not, where does it go? Is it Marketing? Engineering? Do they report directly to the CEO? Considering the state of DevRel study, no one really knows.

Lie 4 - Devrel is still a dedicated team, but bigger

Fourth situation, massive company, several thousand employees, and some of the biggest Deverel teams around. Here Devrel Teams are mostly used to shard, to split the work between other targets. Target being developers or non-developers in our case. I would assume that at that point there is no trouble in understanding the how and why of DevRel, as they are doing the same thing as other teams, but simply focused towards developers. The company has to be big enough to have a company inside the company.

It’s a bit like the previous situation but with a justification of independence based on size. Assuming the number of products is proportional to the size of the company, the DevRel team would have to work with every other team for each product. It is even harder to identify stakeholders, objectives or targets since they would be completely tied and specific to every other team. How can we measure(sorry) anything when it’s so tied to everything else? What is the impact of Marketing versus DevRel ? Is the DevRel team just a pool of specialists that can be used by every other product team? And should they be siloted again? To answer those questions maybe we should first understand how we got to that point…

How did we get here?

How did we get to a state where there is a sudden need for more DevRel everywhere, and to those different lies and fiction? Surely the answer to that should help us put things in perspective, and I would love to know your answers. This is still extremely exploratory to me.

One of the main reasons to me is that communication inside a company is hard. Like really really hard, and we were all used to not to talk to each other and do our own thing. It’s so much easier, to be in a silo, in a dedicated team, and not interact too much with others.

But while we are used to learning and understanding traditional businesses fairly quickly, Software as an industry is still quite new and requires a conscious, real effort to grasp it. So we all need to communicate, to talk to each other and see how everyone in the company can get in that culture.

And to me this is somewhat linked to digital transformation. It does not only require technical teams to change the way they create and deliver a product. Everyone else has to be part of the change and adapt their deliveries to developers. And one way to do this is to embrace Devrel just like techs are embracing DevOps: as a set of culture and practices that should be understood and integrated…

Now if DevRel is not a job, should not be a lure, and probably not a siloted team because it raises too many question, like who should it report to, what are the objectives and targets, who are the stakeholders, how do you measure the damn thing(sorry), what should DevRel be?

DevRel is a Transverse Practice

It’s no surprise to many DevRel practitioners that it is indeed a practice, a discipline. It’s a culture that every company that seriously considers being developer-first should implement. It presents the same characteristics as DevOps, the same lies and misunderstandings as well. It cannot be siloed into a job or a team because the nature of this practice is to be transverse, to help everyone in the company understand how to talk, to reach, to understand those bloody, needy, very special snowflakes that are developers(or maybe you think that because you are not into DevRel yet :D ).

If you are wondering why everyone is having so much trouble about that measurement thing, it’s because in the grand scheme of things it does not make any sense. You don’t single out the effect of a transverse practice. For instance, who are we to say that it’s our work that made more impact in people’s mind than marketing’s work? Devrel success should be measured globally as they are enabler for others. Ask anyone of us and we will tell you we love helping others, outside or inside the company, or even outside work. If you really, really need or want to measure something, look at how you helped, not who and for what you helped.

If anything Devrel success should be measured globally as we are enablers for others. Again we have to move out of the silo. This is where C-level buyin helps tremendously. When they understand it’s a transverse practice they stop comparing how many leads marketing and ‘DevRel’ brought.

Our role as DevRel practitioners is to help engineering and product by giving them feedback from the field, by putting ourselves in the users shoes and being patient zero, by helping aspiring speakers go through CFP and giving talks. We need to inspire not only outside but inside the company. Maybe it’s my impostor syndrome speaking but I believe a talk about something given by the person that did it will be more impactful. True not everyone knows how or wants to give public talk but if they want to, we have to help them.

But it does not stop at technical teams, our role is also to help marketing understand their new target, to understand this fast moving market that requires a crazy amount of technical watch to stay in the game. It’s also to teach them about developer culture, how they behave in conferences, what kind of content they are interested in, about the authenticity they are looking for.

So Transverse it should Disappear ?

Even more than any of these specific activities, our role is to identify situations where everybody(marketing, engineering, sales) has to work together towards a common goal which is to be developer-first, and do our best for it to succeed. Which, if you’re familiar with DevOps, is pretty close to it. Change the culture to make different teams work better together.

If we really had to limit DevRel to a “job”, I guess the best position to be in to practice it would be Product Manager. Because it touches most jobs people traditionally associate to DevRel, and you end up having to explain the product to others, and go even further and explain to them how to explain it to developers.

I strongly believe that the future of DevRel, like DevOps or any other practices really, is to disappear, to be integrated, merged in a general work culture. Again this does not mean DevRel affiliated job will disappear, it means they will be normal, integrated in the department they need to be with. My role as DevRel VP at Clever Cloud is to make sure we get to that point.

Thanks for reading everything, hopefully it made sense. I will now wait for your comments and try to keep my impostor syndrome in lockdown.