The developer role is changing. More and more often they are being rightfully viewed as key stakeholders who aid in setting company direction in this product-led world that we live in. For many technology vendors, earning the trust of developers is critical to their short-term and long-term success, but this presents a challenge. Developers have more than a full plate of work and traditional marketing tactics can fail to gain their attention. A new, more authentic approach was needed. This has led to the emergence of developer relations (DevRel), a term that can mean a lot of different things to different people.
I view the role of DevRel as being responsible for creating good mutual relationships between a technology company, its product and external developers. Mature DevRel programs typically sit at the intersection of the marketing, engineering and product teams, as it is common to have developers in each of those groups. As such, DevRel teams consist of a unique group of people who fall somewhere in between the developer world and the marketing world. However, DevRel isn’t a one-size-fits-all idea. For early-stage startups, the makeup of a DevRel team tends to be more organic.
When Should an Early-Stage Company Build a DevRel Team?
Creating a DevRel team too early can be a mistake for many early-stage companies. It can be exciting for an early-stage company to want to invest in DevRel from the get-go, but the truth is, putting together this team too early (and before knowing if the product is even a fit in the market) can be money wasted. Developers have long memories, and bringing a flawed or unfinished product to them could create long-term damage to your brand.
You need to first prove your worth in the market and experience growth before investing in DevRel. This way, you can ensure that your hypothesis was correct and your products have proven value. Once you’ve proven your hypothesis and have tested your products thoroughly, the next step is establishing short-term and long-term goals for the DevRel team you want to create. Know your market and have a plan of execution ready.
What Does an Early DevRel Team Look Like?
In the early stages of Algolia, for example, our DevRel team wasn’t even a formal DevRel team. It was a blend of DevRel and customer support. Our first priority was to create the best possible developer experience (DX). We, as developers, took the initiative to interact with the market. We were personally engaging with people that signed up with the service to offer our help.
When your customers are developers, they can find it frustrating to speak to those who don’t understand code; therefore, it can be helpful to embrace a developer-to-developer connection when handling one-on-one support. This is invaluable for helping understand customers’ pain points and iterate very quickly with regards to the product. Imagine hearing about a bug and being able to fix it near-real-time!
The advice I would give to anyone starting an early DevRel team is that your first evangelists should always be your core developers—they know your product inside and out. However, make sure that your core developers are using your product—”Eat your own dog food!” This is a very good way to make sure that your core developers have empathy with external developers. In fact, even today we ask core developers to do support a couple of days per month. As we approached the 150-employee mark, only then did we create a fully dedicated DevRel team. It was only then that we could expand into specialized skill sets to push activities at a larger scale.
How to Engage Your Own Developers to Be Evangelists
Once a strong developer experience is established, DevRel should focus on maximizing inbound activity, not specifically revenue. This can be in the form of free users, trials, student interest, etc. It’s a long-term growth investment. Trying to treat DevRel as a sales strategy and having the goal of impacting revenue is a recipe for failure. You want the developers on your DevRel team to be authentic. They aren’t salespeople; they shouldn’t be salespeople and if they try to be salespeople, it won’t be authentic.
Your developers don’t necessarily need to be overly social or extroverted to embrace DevRel, either—that’s a common myth. They can stay true to themselves and genuinely try to help in ways that play to their strengths. Providing content is a great example of this. Have developers complete documentation for the features they build. View documentation as a core part of the product. For too many people, documentation is an afterthought when, in fact, it is one of the most important aspects of a product. Documentation can then be used as a jumping-off point for other content—blogs, whitepapers, etc.
That said, if your developers are genuinely interested in the more social aspects of DevRel, offer public speaking and training tools for them. Developers with these skills can become the face of the company on webinars and panel discussions, attend events on the company’s behalf and more.
The best DevRel programs understand the developer community, what types of tech they are using and then go where developers are to make connections. DevRel should amplify what the developer community is doing by showcasing use cases and solutions to problems. It should give a voice to your community of users by being the glue between developers and product teams.
Why Do Companies Need DevRel?
The API economy is making the role of developers and DevRel even more important than it already was. The competition for the attention of developers is already fierce; it is only going to increase as more organizations recognize that developers need a seat at the table when strategic decisions are made.
Many companies are going to view DevRel programs through the traditional marketing lens with big-budget bets made on general awareness that isn’t personalized. This is going to fail. Instead, companies that have an authentic and measurable DevRel program in place, built around making meaningful connections, will be the most successful. Early-stage companies that embrace this thinking will gain an edge on larger competitors that are stuck in the old school way of thinking.
