Developer Relations (DevRel) is a hard topic to address if I follow the process I’ve used before. That is: 1) Find an interesting topic 2) Find facts about it in academic research 3) Write about it. DevRel is an interesting topic but the problem is that I can’t find academic research about the topic. The information available is blog posts and such. For now I have to satisfy with those.

I’ve been reading and watching presentations about the topic during the past months and I think I have an idea what people might include in it. First thought (wrong) was that DevRel is like the traditional customer support in B2C but now the customer segment is developers (B2D). No, DevRel is not the customer support as we’ve known it. DevRel can look like customer support occasionally, but it’s more versatile profession or area of interest. Some of the features or great DevRel person discussed below.

Developer relations is a nutshell

Good summary of developer relations team functions and requirements can be found from Google Developers blog:

“An effective Developer Relations team is made up of a diverse group of legit engineers with superlative communication skills, who aren’t selling anything, who feel the same pain as their audience — to which they listen and respond to continuously. And they have to do all of that in a way that can scale to an audience north of 20 million developers.”

Sounds easy and quite different to traditional marketing efforts or support function.

Passion for outbound oriented communication

They need to have the internal need to share and communicate. People with strong extrovert nature normally are good devrel team members as well. Communication skills and ability to step on the stage with a few minutes time to prepare is needed. You need to be pretty good in English which is lingua franca among developers. Of course if you operate for some reason only in French or German language dominated locations, then those languages should be in your skill set too. DevRel people need to have skills to write to the point articles and use social media channels fluently. People will like to follow you instead of the company Twitter account.

You should also have a life in Github and show some track record in code. If you just talk about code but never do anything with, you are not credible. You are a fraud. Code is communication. I’ve seen devrel people without any knowledge of code and they are shallow. I’m not a professional developer and my code is mostly butt ugly (though I write working code). I know my weaknesses and I’m not acting as DevRel fulltime. I do ocasionally do some gigs in the field among the developers and show in code level how our APIs work, but that is not my daily job. Instead I’m managing Developer eXperience development (among other things).

They need have real experience and knowledge of engineering

To be able to talk to developers you need know your topic, tools and practices. You just can’t put a marketing person to act there. In my opinion having a degree in computer science is not required. You have to have the experience and thinking like an engineer though. Some of the most talented hackers I know have learned programming skills elsewhere than in school. Also some of the best devrel people I know have background in software development with history in variety of positions.

Devrel team members are fellow developers between you and the platform

Business to developer (B2D) is not about selling

This is one of the fundamentals of Business to Developer marketing too. You don’t sell stuff! You help developers to utilize your solutions most efficiently. You listen to their needs and if needed offer the helping hand. You share the best practices which includes often tools created by someone else but at the same time you bring in your own solutions. In short, you don’t push your product if it does not fit in the needs of the developer.

If devrel team does not sell, how will they help us to build business? DevRel people are the best sensors in the field to know if your products market-fit is in shape or not. They mingle with the developers and if trusted get valuable feedback and information for the product development. Knowing the tool stacks and technology stacks used by your target group and how your product fits there is crucial. Here the DevRel people can help your development team. In a way, they are the people who help you to cross the famous Moore’s chasm.

Empathy is the key

In this sense they are the developer’s voice inside the company. They feel empathy towards the developers consuming the service, API or platform. The need for empathy in overall DX development has been discussed previously in the series. If you are not able to feel empathy towards your customers (developers) you should not be in the DevRel team. Devrel people need to be able to step in the other people’s shoes and see the pain and even anger towards your product. Keep in mind that we are humans and we make quick judgements based in feelings. Having ability to sense how other people might be feeling helps to adjust the next steps in dealing with the situation. Sensitivity in dealing with people is crucial. Great devrel are people persons - who enjoy or is particularly good at interacting with others.

Am I a people person or not? If people exhaust you, if people scare you or people annoy you, you are probably not a people person. Some claim that you can’t become a people person. I disagree. Based on what I’ve read about typical non-people person, I was one of those like 10 years ago. I have worked hard to change that and now I am a people person. Of course I get exhausted with intense social interaction like events, but who doesn’t? I was worried if I find anything to say to new people. Getting more experience in what I do helped me to find topics to discuss. I have studied a lot, I have experience, I know what I’m talking about but I’m ready to say that “I don’t know” too. I can laugh at my mistakes. In short I’m comfortable with my self and I have self-confidense…sometimes even too much.

Perhaps the hardest part for me was the learn fake small talk capabilities. I’m a typical Finn, I don’t have a need to talk all the time to feel comfortable. Silence even among people is not awkward to me (ask my wife). That is normal state. I had to understand that in some cultures silence is treated and felt differently. Americans for example avoid silence with all the means they can.

They need to work at scale

Your audience is at best millions of people and in broad sense the 20+ Million developers are your audience. You need to be able to think big and act at scale. Your activity can not be limited to physical presence, but you need to be able to use modern tools and opportunities.

Some more to read from 100 Days DX