A Month Into a DevRel Role, What Did I Learn?

I've been on and off with DevRel activities for the last five years. From collaborating with Cisco DevNet in 2017 to working on an innovation team around code automation, and lately, in the JIT CTO office, my technical leadership role always included some aspects of customer-facing plays where developers were the customers.

A month ago, I decided to move all over and started my first pure DevRel job as the director of DevRel and Growth at Permit.io. This decision has been taken with mixed feelings about what I call FOMC - Fear of Missing Code, but I'm happy with that decision so far. First, I'm still coding; second, I haven't done anything that bored me last month.

The decision to work with Permit.io wasn't that complicated for me. I've been living in the AuthZ and policy engines space for most of the last decade, so working in a startup that provides multiple solutions all across the permissions stack, from authorizations in web applications to management of complex admission policies in the far back end, looks great for me to start my first DevRel role.

In this post, I'll share some of my learnings from my first month as a DevRel. Since this field is full of misunderstandings and confusion, it is always wise to take this first month to focus and ask the right questions. Shall we start?

Define the Role

There are three fundamental roles in the DevRel landscape, each comes with its skills and activities, but they overlap sometimes. Every organization that wants to hire a DevRel role or someone who intends to become a DevRel has to look into those activities and functions. They have to make sure they understand what they want.

Community and Operations

The first is the community and operations role. In this role, the product or organization requires someone to manage operational developer-facing activities such as community management, event planning, and swag coordination. IMHO, this role does not require a solid technical background but living in a space that knows how this market goes.

Advocacy

The second and most traditional role is the developer advocate. An engineer who has good storytelling and content creation skills (someone said influencer?) and they are responsible for making deep technical products into fairy tales. The content these people create is usually related directly to the product, and traditionally they are designed for people have already taken the first step in our funnel.

Growth

The third, and the one I just started, is the DevRel which tries to make the product business more successful. In this role, we will need a good product and business understanding and deep knowledge of the technical developer's needs and processes. The content these people create is mainly for the top of the funnel, understanding how we could technically attract people to the product or solution. These roles have a couple more responsibilities, such as paid advertising, metrics, SEO, social, and any other activities that will help the product grow from the developer-facing perspective.

Now that we understand the different roles and responsibilities, we need to ask ourselves what the real need we have for a DevRel and hire the right person for the particular role. As I said, I started as the third one, so let's see what my responsibilities are inside Permit.

Define the Responsibilities

Luckily, Permit.io has a solid business perspective and a championship league of PLG enthusiasts. In addition, we are still small, so I had the chance for deep discussions with any other person in the company to ensure I (and them) know well what I will do in my role. So far, these are my responsibilities.

Technical Top-of-funnel Content

In our PLG stage, we try to have the wider top-of-funnel audience we can reach. That means we offer as many small use cases as possible in our products for our users. From the content perspective, we need to create as much more content that will make developers feel they can solve their particular problems with our offer. This content could be blog posts, landing pages, videos (not my cup of tea), technical talks, etc.

SEO

No matter how much content we will create, no one will reach it if we will not have a clear SEO agenda around it. We are rarely investing in keywords SEO for such content but long-tail SEO, meaning we are looking for queries that have high volume and are somehow related to our offer and create content around it. My responsibility is to create a content calendar and strategy to hack as many growth optimization channels as possible.

Partnerships

One of the best ways to grow the content's exposure and the offer is to partner with other players around our market. Software never builds from one piece; it always includes many elements that combine winning applications. My responsibility is to find the relevant other and successful pieces that we can correlate with and ensure we are on their table. It could be standard content describing the partnerships, apps in marketplaces, social proofs in websites, and as many options as possible, that will mark our name around.

Advertising

Sometimes, the only way to publish our stories is to pay for them. We manage five advertising campaign types: Intent, retargeting, competitors, branding, and search optimization for our self-product. I'm mostly enjoying focusing on the intent part, which means reaching out to developers who experience some problems around permissions and authorization and catching them just in time for our offer. We advertise on many platforms and media, but it is all standard ad providers. As for now, we do not pay for sponsorship like many other startups because we feel it's too early in the funnel.

Social media

Luckily, we already have a social media manager in Permit.io, so I can primarily focus on creating technical and catchy developer content we can share on social media. Since my profile is professional, I should also invest more in making my activities (especially on LinkedIn) more accurate and analyzing how things are going.

Data, Intelligence, and Metrics

To understand better how to act with the previous activities, we need to build a better system of analysis that will open our eyes to the trends and see what is working and what is not. For now, the data is more around because we still don't have enough quantitative data for quality results, but I need to prepare the system for better results later.

There are many overlapping activities, such as managing user journeys with our community manager, advertising our advocate content, empowering engineering in creating content, ranking conferences' quality and submitting papers, and more.

Define the Goals

One of the biggest challenges in DevRel roles is correlating the practical activities to the results. On the one hand, My performance goals, of course, are very general and precise. Website traffic, monthly active users, etc. DevRel activities goals, on the other hand, do not directly result in attributes in the performance goals. For example, I traveled to a conference and gave an excellent talk. On the one hand, there are no new visitors to the website, but on the other, I created a couple of compelling connections with people from the industry that helped us by the week after.

The most important thing about goals is to have a transparent representation of what we are doing and the plan for making it an accurate result. This creates a bi-directional communication channel between the external environment that wants business goals and the internal ability to stand in DevRel goals.

From my experience, I can say this is one of the challenges for every DevRel role, so we all should be clear about how we are executing with no direct attribution but having failed fast iteration to understand what we miss along the way.
It also helps to define short-term goals that represent both needs. Advertising hacks around content, partnership wins, and more will create better trust and confidence for all sides.

Define the relationships

In my short month, I have already been in touch with all the functions in Permit.io. From the R&D that helped me onboard technically, developers who want to do DevRel activities, designers that helped me with ad materials, executives, operations that helped me with travels, marketing that onboard me to ad and SEO, and many external service provider functions. Good relationships are the most important for success in such a diverse role.

Make sure you listen to the people around you and ask them the questions to get the answer that will represent their needs and not what you want them to answer. Sometimes it takes time, and sometimes you discover a black hole of a mess that you'll have to deal with, but always it'll create a lot of value to your journey in the company.

As I see it, empowerment is one of the essential skills that a good DevRel has. You must take every function in their activities and ensure your unique role and responsibilities help them maximize their results and fun. Be a good DevRel person, and make sure you empower the functions around you and do not let them down by your acts.

Define the Priorities

As with any other role that includes a lot of responsibilities and touchpoints, you'll discover very fast there is work for ten people that you should do by yourself. It's true when you are the only person in the DevRel org, but from what I heard, it is also valid for organizations with dozens of people.

To define priorities better, you must ensure that you have a perfect understanding of the phase we are in the business. For example, I want to prioritize sponsorship events, but it doesn't provide the proper performance for top-of-funnels. Another example is user journey automation, such as journey emails; again, we are too early for such an effort. There are much more things that I need to postpone than I have to prioritize, but this is how things are going. I'm constantly reminding myself that if I do right, I'll get to all those activities big time later on.

Define the schedule

If you want to prioritize anything, it is essential to create an accurate schedule. I'm setting time in the calendar for any activity that takes more than 5 minutes. And it is not only for me but for everyone. Every time I need something from someone else, I ask first how long it will take for them and encourage them to dedicate the right time for it when it will be.

Routine activities and their cadence are also essential to schedule advice. As I started, I asked for answers to the recurrent tasks of DevRel people on Twitter. I collected the answers, and tried together with my role settings to set a structured recurring schedule.

My Recurring Schedule

Daily

Analytics run - over the website and product activities.
Personal social run - with a detailed list of what I'm doing (3 comments, one post, 5m reading, etc.)
Company social run - together with our other social media people.
A personal daily planner for tasks, etc.

Weekly

Event syndication - where I add events and rank them for submissions
1:1 - with the functions I work closely with (marketing, exec, colleagues)
CFP and talk ideation - with our operations team.
Advertising snapshot - to understand our budget and how to optimize campaigns.

Bi-Weekly

Influencer syndication - to understand the influencers' vibe around our domain
1:1 - with functions I'm working with occasionally (operations, external service providers)

Define the Tools

Doing this DevRel thing is no longer about only using VSCode or VIM (you can unfollow Jetbrains people ;) ). In my experience, if I don't have the right tool for a task, it could take me hours to search for the right tool over and over again.

So far for this month, I have a queue of notions in my Slack personal channel, and I find that writing decks in DeckSet is more potent than Google Slides, doing board and team management on Monday (not the best tool, but so far not that terrible), and personal tasks on Google tasks.
When I have trouble finding a tool for doing a task, I take pen and paper and consider what I want to accomplish. I then think about where and how I see a tool that can fit most of my needs.

Conclusion

It is only a month in this new role, but a year in my career. Taking this step toward the DevRel ecosystem has been a great experience.

I must say, not everything is a bed of roses. Being in touch with so many people for an introverted person is challenging, and time management and prioritization are still complex for me. Luckily, I have a supportive environment in Permit.io and professional friends outside the company, so, no doubt, I'll make it.

See you in 3 months!