“Developer Relations or DevRel” is oftentimes seen as managing a community, event management or as a part of marketing or sales. It could be organising online webinars, physical developer events, hackathons, doing a live coding session, writing a blogpost and more. I’m here to share that DevRel is NOT merely organising  events or surrounding OKRs on the number of developers reached. It has a lot more meaning to it, a lot more strategy behind it, companies with developer products will find success if it’s done correctly. Generally, DevRel is the conduit between developers and product teams. I’ve experienced first hand or read a few times how companies found their strategic sweet spot in business success and made stakeholders happy, by managing a successful DevRel strategy. So what’s with all this misunderstanding? Let’s discuss a few things.

Developer Relations (DevRel) was a new term when I joined Dialog Axiata back in 2013. As I recall, my managers’ title was “Unit Manager – Developer Community” and mine was “Developer Support Engineer”. My friends asked me “Support Engineer? Are you sure you want to take the job?”. It was a little demeaning in a south asian context and it had an uneasy awkwardness. I’m sure my manager also had to explain to people what’s up with his title too. DevRel had evolved over time in the US and Europe since the late 90s / early 2000s. Developer support engineers, developer program engineers, developer advocates, DPE Manager, Dev Community Managers, director/VP DevRel are very well laid out OKR driven, value generating multi level roles in global scale companies. All these roles are part of building, managing and supporting development of planet scaled developer communities for the success of a business and they are the people who can potentially bring back valuable feedback to product teams. I’m sure companies wouldn’t want to invest in these head counts unless they derive value. That’s some serious stuff there. After this revelation, I never had a regret in being a Developer Support Engineer.

OKRs, driven by objectives generally derived through the SMART method. DevRel teams can find it difficult in setting OKRs, mapping OKRs, cascading OKRs, and determining through methods like SMART. Why? Numbers of devs reached, online views / viewers, number of blog posts written, number of events organised are easily measurable which is only the first layer of the onion. How about when a developer advocate did a live coding session at an event, two of the attending devs were really impressed by the tech, started their own company and their product attracted millions of users after 6 months generating millions of dollars to the dev advocates employer? How do you capture that through an OKR? These types of events are rare and cannot be time bound. Does this mean companies should measure the number of impact stories on an annual basis? It can be tough. A story/ an endorsement is seems like something marketing would be interested in which can be used to generate demand, generate leads. Then, should DevRel have marketing OKRs? But the dev advocates wrote code, so should it have some technical OKRs? How to measure impact through influence? This can be pretty confusing. That’s just one example.

Deeper impact by DevRel activities might not be measurable, visible and immediately available. DevRel’s impact is more long tail, inspirational, influential and maximising opportunities at scale which cannot be derived through SMART. That’s inside the inner layers of the onion. More cause and effect. But to justify its existence to the core businesses, DevRel teams would highlight the outer layers. Companies with established DevRel orgs would potentially explore the inner layers to understand the real value it creates.

Depending on their function inside the DevRel team, different people will have their own area/s of excellence. Engineering, product knowledge, market knowledge, strategy, operations, marketing, sales, project/program management and people skills. People with an intersection are in the rare air and can be very influential among developers. Internal/ external developers and dev communities would mostly see the excellence of devrel teams through engineering, product knowledge, management, marketing or people skills. Excellence in one or more areas creates the influence and inspirational connection between devrel teams and the developers and communities. That’s one of the reasons why devrel teams are so popular as people who organize events for devs or as people who are front ending developer communities / initiatives or marketing a developer product. What mostly isn’t visible is strategising. Strategising is a key factor for the success of DevRel activities every step of the way. As an example, if “company A” has a cutting edge technology and they make money by selling it to developers, DevRel can potentially increase the opportunities by identifying the 7Ps of marketing, identifying the roadblocks and eliminate, identifying what type of codes/demos to be used, which tech will be appealing for specific markets and more. DevRel not only can generate demand but it also can induce adoption through advocacy and feedback loops to product teams. DevRel is a mixed bag, an org of its own as it will have multiple touchpoints in a dev product business and its necessary unit than auxiliary . There are different ways devrel teams formulate developer strategies and it will depend on the company, culture, organisational behaviour, product priorities, funding and many other factors.

That’s a lot you didn’t know about DevRel, right? Next time when you attend a developer event, just remember that it might have had a lot of thinking behind it, with a determination that you will use that product and build something really cool to make a change in the world.

What’s your Reaction?
+1
1
+1
1
+1
2
+1
0
+1
0
+1
0
+1
0